GHSA-7v3r-m9c8-r855
HIGHGHSA-7v3r-m9c8-r855 is a high-severity (CVSS 8.2) CWE-184 vulnerability in github.com/gotenberg/gotenberg/v8. O3 Security confirms whether GHSA-7v3r-m9c8-r855 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Gotenberg's ExifTool group-prefix syntax bypasses dangerous-tag blocklist
Real-World Exposure
github.com/gotenberg/gotenberg/v8Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The ExifTool metadata write blocklist in Gotenberg v8 can be bypassed using ExifTool's group-prefix syntax, enabling arbitrary file rename, move, hardlink, and symlink creation on the server. This is a bypass of the fix for GHSA-qmwh-9m9c-h36m.
Details
The blocklist in pkg/modules/exiftool/exiftool.go filters four dangerous pseudo-tags (FileName, Directory, HardLink, SymLink) using strings.EqualFold(key, tag). However, ExifTool supports group-prefix syntax where File:FileName is processed identically to FileName -- the prefix is stripped by SetNewValue in Writer.pl before tag matching.
The safeKeyPattern regex (^[a-zA-Z0-9\-_.:]+$) allows colons, so prefixed tag names pass validation. Any prefix works: File:FileName, System:Directory, a:HardLink, etc.
Additionally, FilePermissions, FileUserID, and FileGroupID pseudo-tags are not blocked at all and can modify file attributes without any prefix.
PoC
# Rename the converted PDF (bypasses FileName blocklist)
curl -F "[email protected]" \
-F 'metadata={"File:FileName":"pwned.pdf"}' \
http://localhost:3000/forms/pdfengines/metadata/write
# Move the file to /tmp (bypasses Directory blocklist)
curl -F "[email protected]" \
-F 'metadata={"File:Directory":"/tmp"}' \
http://localhost:3000/forms/pdfengines/metadata/write
# Create a symlink (bypasses SymLink blocklist)
curl -F "[email protected]" \
-F 'metadata={"File:SymLink":"/tmp/symlink-poc"}' \
http://localhost:3000/forms/pdfengines/metadata/write
# Change file permissions (not blocked at all)
curl -F "[email protected]" \
-F 'metadata={"FilePermissions":"rwxrwxrwx"}' \
http://localhost:3000/forms/pdfengines/metadata/write
Impact
Pre-auth (no authentication by default). Attacker can rename, move, or create links to files within the Gotenberg container. In deployments with mounted volumes or non-containerized setups, this enables arbitrary file read via symlink chaining and file overwrite via directory manipulation.
This is a direct bypass of the fix for GHSA-qmwh-9m9c-h36m.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/gotenberg/gotenberg/v8 | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gotenberg/gotenberg/v8. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of github.com/gotenberg/gotenberg/v8 has shipped for GHSA-7v3r-m9c8-r855 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-7v3r-m9c8-r855 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-7v3r-m9c8-r855. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-7v3r-m9c8-r855 in your dependencies?
O3 detects GHSA-7v3r-m9c8-r855 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.