Gotenberg CVE-2026-42589: one unauthenticated request runs commands, and attackers are using it

What happened

Gotenberg is a Docker-packaged API that converts documents to PDF. Before 8.31.0, its /forms/pdfengines/metadata/write endpoint takes a JSON metadata object and passes the keys straight to ExifTool. Nothing checks the characters in a key. A newline in a key starts a new ExifTool argument, so an attacker can add flags such as -if, which evaluates Perl. The result is unauthenticated OS command execution in a single HTTP request, rated CVSS 9.8 (CVE record).

The attack is quiet. The server answers with HTTP 200 and a valid PDF, so there is no error to notice (CVE record). The researcher S-Senhaji reported it. Gotenberg’s advisory, published on 30 April 2026, includes working proof-of-concept code (GitHub advisory). The fix shipped in 8.31.0, released on 17 April 2026 (Gotenberg release).

It is exploited, by many actors. VulnCheck added the CVE to its own KEV list on 26 June 2026. In a 26 October post, it counted 1,358 exploitation events from 128 source IPs over 30 days, in at least seven clusters: a scanner on Contabo, XMRig cryptominers, Python reverse shells, S3-hosted payloads and others. The earliest activity it saw came from Telecom Italia infrastructure from late June into early August (VulnCheck).

One cluster drops cache_base, a 5.2 MB stripped Go binary. It writes ./.cached_db.lock so only one copy runs, asks ipinfo.io for the victim’s location, registers with its command server and pipes the connection to /bin/sh. It has no persistence of its own (VulnCheck). The flaw was not in CISA’s KEV catalog as of 30 October (CISA KEV).

Am I affected?

You are affected if any Gotenberg container runs a version before 8.31.0 and something untrusted can reach its API. Gotenberg often hides inside other stacks as a helper container, so search for it:

# Docker hosts
docker ps --format '{{.Names}} {{.Image}}' | grep -i gotenberg

# Kubernetes, including sidecars
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' | grep -i gotenberg

# Compose files and manifests in your repos
grep -rn 'gotenberg/gotenberg' --include='*.yml' --include='*.yaml' .

A floating tag such as gotenberg/gotenberg:8 only moves when you pull it and recreate the container. Gotenberg’s advisory lists 8.29.1 as the version that tag served when the bug was reported (GitHub advisory).

Then check exposure: is port 3000 (or whatever you mapped) reachable from the internet, from other tenants, or from anything that passes user input through unchanged?

What to do now

1. Update to Gotenberg 8.31.0 or later and recreate every container that uses it. Pulling a new image does not change a running container.
2. Put the API behind an authenticating reverse proxy and never expose port 3000 to untrusted networks. This is the only workaround Gotenberg gives (GitHub advisory).
3. Hunt for attempts. Search proxy and access logs for POST /forms/pdfengines/metadata/write. That endpoint is legitimate, so look for requests from sources outside your own apps.
4. Check containers for the dropper VulnCheck described: a .cached_db.lock file in the process working directory, /tmp/nx_cmd.txt, a process with PYTHONUNBUFFERED=1 set, or outbound HTTP with the user agent Go-http-client/2.0 from the Gotenberg container.
5. Block and search for the network indicators VulnCheck published, including 39.105.65.32, 5.161.100.63, 132.145.123.143, 210.170.22.208 and the strangled[.]net subdomains ubuntu-repo, linux-x86-tcpudp and cheeva. Its post also lists MD5 hashes for cache_base and related builds (VulnCheck).
6. If you find a hit, treat the container and whatever it could reach as compromised. Gotenberg usually sits next to application servers and storage. Rebuild it, and review the credentials and network access its pod or host had.

Why this matters

The fix shipped in April, and the first attacks VulnCheck saw came in late June. By October, more than a hundred IPs were using the bug. Gotenberg rarely appears in an asset inventory as its own product. It is a dependency someone added to a Compose file to make PDFs, which is why old copies keep running.

Sources

• CVE record: CVE-2026-42589
• GitHub advisory GHSA-rqgh-gxv4-6657
• Gotenberg 8.31.0 release
• VulnCheck: Cache me if you can
• CISA Known Exploited Vulnerabilities catalog