GHSA-QMWH-9M9C-H36M: Arbitrary File Write and Blocklist Bypass in Gotenberg ExifTool Integration

Gotenberg provides an unauthenticated application programming interface (API) for PDF conversion and manipulation. The /forms/pdfengines/metadata/write endpoint allows clients to modify the metadata of uploaded PDF files. The backend processes these requests by passing the user-supplied metadata map directly to ExifTool via standard input (stdin).

ExifTool supports special operational directives known as "Extra Tags" or pseudo-tags. These tags, such as FileName, Directory, HardLink, and SymLink, dictate ExifTool's filesystem behavior rather than altering the document's metadata. Passing arbitrary values to these tags allows an attacker to execute file moves, renames, and link creation operations on the host filesystem.

Gotenberg version 8.29.0 attempted to mitigate this arbitrary file write risk by implementing a metadata blocklist. The application explicitly deleted the FileName and Directory keys from the user-controlled map. This mitigation was fundamentally flawed due to a case sensitivity mismatch between Go's map implementation and ExifTool's parsing engine.

The vulnerability stems from improper handling of case sensitivity (CWE-178) between the validation layer and the execution layer. The mitigation introduced in version 8.29.0 relied on Go's delete() function, which executes a strict, case-sensitive lookup against the map keys. The blocklist specifically targeted the exact strings "FileName" and "Directory".

ExifTool normalizes tag inputs and processes them case-insensitively. An attacker submitting a JSON payload with the key "filename" bypasses the case-sensitive Go blocklist, as "filename" does not equal "FileName". The validation logic leaves the malicious key intact, passing it directly to ExifTool.

Upon receiving the "filename" tag, ExifTool internally maps it to the FileName operational directive. This triggers the specified filesystem operation, effectively executing the arbitrary file write. Furthermore, the original blocklist implementation omitted the HardLink and SymLink pseudo-tags entirely, leaving those operations fully exposed regardless of case manipulation.

The vulnerable code in commit 043b158 defined a slice of dangerous tags and iterated over it to sanitize the incoming map. The implementation utilized delete(metadata, tag), which failed to account for variations in casing.

// Vulnerable Implementation (v8.29.0)
dangerousTags := []string{
    "FileName",
    "Directory",
}
for _, tag := range dangerousTags {
    delete(metadata, tag) // Case-sensitive deletion bypass
}

The patch implemented in version 8.30.0 (commit 15050a311b73d76d8b9223bafe7fa7ba71240011) fundamentally altered the validation loop. The fixed logic iterates over every key provided in the user metadata payload and executes a case-insensitive comparison against the blocklist using strings.EqualFold().

// Patched Implementation (v8.30.0)
dangerousTags := []string{
    "FileName",
    "Directory",
    "HardLink",
    "SymLink",
}
for key := range metadata {
    for _, tag := range dangerousTags {
        if strings.EqualFold(key, tag) {
            delete(metadata, key)
        }
    }
}

Exploitation requires direct network communication with the Gotenberg API. The attacker constructs an HTTP POST request to the /forms/pdfengines/metadata/write endpoint. The request must contain a valid PDF file and a JSON string defining the malicious metadata manipulation.

To trigger an arbitrary file write via renaming or moving, the attacker submits a payload utilizing the lowercased pseudo-tag. The following curl command demonstrates writing a file to /tmp/evil_bypass.pdf. The Gotenberg validation layer ignores the filename key, while ExifTool honors the directive.

curl -X POST http://localhost:3000/forms/pdfengines/metadata/write \
  -F files=@sample.pdf \
  -F 'metadata={"filename": "/tmp/evil_bypass.pdf"}'

To execute hard link or symbolic link creation, the attacker utilizes the previously unblocked tags. A payload containing {"HardLink": "/tmp/hardlink_bypass.pdf"} successfully forces the underlying ExifTool process to generate a hard link to the provided PDF file at the specified system location.

The vulnerability facilitates severe impacts on system integrity and availability. An unauthenticated attacker possesses the capability to move or overwrite critical system files accessible by the Gotenberg process. This directly leads to localized denial-of-service conditions or corruption of persistent storage volumes.

While the exploit does not immediately yield direct read access to arbitrary files, the SymLink primitive introduces secondary attack vectors. Attackers can generate symbolic links pointing to sensitive host files. If subsequent application logic or secondary API endpoints serve or process these linked files, the flaw cascades into an information disclosure vulnerability.

Researchers emphasize that the version 8.30.0 patch addresses the immediate vectors but leaves theoretical avenues open. ExifTool supports group prefixes, permitting tag definitions such as File:FileName. The current strings.EqualFold() implementation compares the entire key verbatim. A prefixed key bypasses the strict string equality check, potentially allowing the payload to reach ExifTool if the backend does not subsequently restrict namespace prefixes.

System administrators must update Gotenberg installations to version 8.30.0 immediately. The patched release effectively sanitizes case variations of known dangerous pseudo-tags and incorporates the HardLink and SymLink directives into the restricted operations list.

Gotenberg lacks built-in authentication mechanisms and is engineered strictly for isolated, internal deployment. Organizations must enforce robust network segmentation, ensuring the API is never exposed to untrusted external networks. Access should be mediated through reverse proxies enforcing strict authentication and authorization policies.

Security operations teams should deploy strict input validation on upstream web application firewalls (WAF). Monitoring mechanisms must inspect HTTP POST payloads targeting the metadata endpoint for structural anomalies. Any payload containing case variations of ExifTool pseudo-tags must generate high-priority security alerts and trigger automated blocking responses.