A critical-severity argument-injection vulnerability, tracked as CVE-2026-40281 and covered in the advisory GHSA-q7r4-hc83-hf2q, has been disclosed in Gotenberg, a widely used Docker-based PDF conversion API.
The flaw, rated near-perfect on the CVSS scale, allows unauthenticated remote attackers to inject arbitrary ExifTool pseudo-tag arguments by embedding newline characters within metadata values, completely bypassing the key-sanitization patch shipped in v8.30.1.
All users running Gotenberg v8.30.1 and earlier, please upgrade to the patched release, v8.31.0, immediately.Gotenberg is an open-source, Docker-based stateless API for converting, merging, splitting, and manipulating PDF documents.
It integrates with headless Chromium, LibreOffice, and ExifTool to handle document processing tasks ranging from HTML-to-PDF rendering to writing PDF metadata.
Its metadata write endpoint POST /forms/pdfengines/metadata/write accepts user-supplied JSON key-value pairs and passes them directly to ExifTool via go-exiftool’s WriteMetadata() function, making it a high-value attack surface.
CVE-2026-40281: ExifTool Injection Flaw
This is not the first time Gotenberg’s ExifTool integration has attracted security scrutiny. An earlier vulnerability patched in v8.29.0 used a case-sensitive blocklist to filter dangerous pseudo-tags, but ExifTool processes tag names case-insensitively, meaning alternate casings bypassed the filter entirely.
The blocklist also omitted HardLink and SymLink pseudo-tags, allowing end-to-end exploitation against v8.29.1 via the unauthenticated HTTP API. In response, v8.30.1 introduced a safeKeyPattern regex that validates metadata keys for control characters (commit 405f106).
However, the fix validated only the key side of each key=value pair, leaving metadata values entirely unsanitized before being passed to go-exiftool’s SetString() function. The patch, in effect, fixed the wrong side of the equals sign.
The root cause lies in how go-exiftool communicates with ExifTool. The library writes each key-value pair to ExifTool’s stdin as a single line using:
fmt.Fprintln(e.stdin, "-"+k+"="+str)
Because str (the user-supplied metadata value) is passed completely unsanitized, embedding a newline character (\n) in the value splits the single stdin line into two separate ExifTool arguments.
An attacker who sends {"Title":"test\n-FileName=/tmp/inject_proof"} causes ExifTool to receive two distinct lines: -Title=test and -FileName=/tmp/inject_proof the latter being an arbitrary pseudo-tag command that moves the processed PDF to a controlled path.
This technique allows injection of ExifTool’s most dangerous pseudo-tags, including -FileName, -Directory, -SymLink, and -HardLink the exact tags the original blocklist was designed to block.
Researcher morimori-dev provided Docker-verified reproduction steps confirming the vulnerability’s severity. By sending a crafted POST request to the metadata write endpoint with a newline-embedded value, an HTTP 404 response is returned, confirming the file was moved away from its temporary processing path.
Running docker exec inside the container confirms the injected file path was created successfully. The full attack chain demonstrates four classes of exploitation available to an unauthenticated network attacker with no user interaction required:
- File rename/move: Using
-FileName=, the attacker redirects the PDF being processed to any arbitrary container path, disrupting service availability. - Arbitrary file overwrite: Combining
-Directory=/etc/ -FileName=passwdinjected as two separate lines via two newlines moves the processed PDF to/etc/passwd, corrupting the system’s user database and achieving critical integrity impact. - Symlink creation: Injecting
-SymLink=/tmp/sym_injectplants a symbolic link at an attacker-controlled path, enabling follow-on read/write primitives against sensitive files. - Hard link persistence: Using
-HardLink=, the attacker can persist file data beyond temporary directory cleanup routines.
Because Gotenberg containers run as root by default, the blast radius of any successful file manipulation spans the entire container filesystem.
The vulnerability carries a CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H, yielding a Critical base score. The Changed Scope designation reflects the fact that successful exploitation affects resources beyond the vulnerable component itself.
The primary weakness is classified under CWE-88 (Improper Neutralization of Argument Delimiters in a Command Argument Injection), with a secondary classification of CWE-20 (Improper Input Validation).
Patch
The vulnerability is fully patched in Gotenberg v8.31.0, published on April 30, 2026. The remediation requires adding value sanitization in parallel to the existing key check inside WriteMetadata() Specifically, rejecting any string metadata value that contains \n, \r, or null byte (\x00) characters.
An alternative approach involves applying the same safeKeyPattern logic to string values or percent-encoding newlines before passing them to go-exiftool.
All organizations running Gotenberg in production environments, whether exposed internally or through public-facing document processing pipelines, should upgrade to v8.31.0 without delay.
Where an immediate upgrade is not feasible, restricting unauthenticated access to the /forms/pdfengines/metadata/write endpoint via network-level controls or API gateway policies is a viable interim mitigation.
FAQ
Q1: What versions of Gotenberg are affected by CVE-2026-40281?
All versions up to and including v8.30.1 are vulnerable; the issue is fully resolved in v8.31.0.
Q2: Does CVE-2026-40281 require authentication to exploit?
No, the vulnerability is exploitable by any unauthenticated attacker on the network with no user interaction required.
Q3: Why did the v8.30.1 fix fail to prevent this attack?
The fix only validated metadata keys via regex, leaving metadata values completely unsanitized before being passed to ExifTool’s stdin.
Q4: What is the real-world impact of a successful exploit?
An attacker can move, overwrite, or symlink arbitrary files within the container, potentially corrupting critical system files like /etc/passwd since Gotenberg runs as root by default.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.