Gotenberg is a self-hosted API that converts HTML and office files into PDFs, often for invoices or reports. An ordinary WordPress or PHP site does not include it by default, so first ask your developer or hosting provider whether it is part of your stack. If not, this alert does not apply to you. Everything below was checked as of 30 October 2026.

What was disclosed

On 30 April 2026 the Gotenberg maintainer published GHSA-rqgh-gxv4-6657, tracked as CVE-2026-42589. The flaw in the PDF metadata-writing API lets anyone who can reach that route run commands without logging in, inside the service’s context, not automatically as root or outside the container. It confirms 8.29.1 affected and 8.31.0 patched, not an exhaustive version list.

Which version to run today

Release v8.31.0, published 17 April 2026, describes stripping control characters and line breaks from PDF metadata plus other hardening. The notes do not name the CVE, but they match the advisory, and a fix shipping before public disclosure is normal. One wrinkle: the separate GitHub advisory database entry, last updated 14 May 2026, still lists no patched version. We do not know why the two records differ, so we follow the maintainer’s advisory, which the release notes support.

That release is the documented fix for this specific CVE, but it is not the version to install today. v8.39.0, published 27 October 2026 as the latest stable release, carries later security fixes for metadata handling and network policy, building on releases such as v8.37.0. Ask for 8.39.0, or a newer supported release the maintainer lists when you read this, and have your provider review the breaking changes between your current version and the target.

Exploitation has been reported

Security firm VulnCheck reported on 26 October 2026 that its canary network observed exploitation of CVE-2026-42589, including attempts to deliver reverse shells, and it also points to 8.31.0 as the fix. That is telemetry from VulnCheck’s own sensors. It does not tell you whether your site was touched, nor that every Gotenberg installation is compromised. If your provider confirms you are running an affected, outdated service, prioritize the upgrade and the validation steps below.

What to ask your provider

  • Which Gotenberg version and image digest is running right now, on every replica, and who owns the patch. A mutable tag such as “8” does not prove the old container was recreated, and pulling a new image is not the same as running it.
  • Whether the service is reachable only from your application. The default configuration listens on all interfaces on port 3000 with authentication off, but real exposure depends on your firewall, reverse proxy and network layout, not the port alone.
  • Whether authentication is actually enforced, not merely available. Gotenberg’s built-in basic auth or OIDC, an authenticated reverse proxy in front of the service, or an equivalent platform control can each do this when configured properly. These are extra layers, never a substitute for fixed software.
  • If your Gotenberg is a customized or self-built package, which fix was applied and how it maps to upstream. Ask for evidence tied to the running build or image, not only a version label.

Test the upgrade without risking real invoices

Ask for a documented staging upgrade first, using synthetic invoices and reports that contain no customer data. Check the flows your deployment actually uses: metadata writing, URL-to-PDF conversion and the authenticated calls your application makes to the service. Confirm backup, rollback and recovery steps before production, following our guide on backup strategy, RPO, RTO and restore testing. If something breaks, fix the integration rather than disabling authentication or widening network access. Then confirm the fixed build is what production actually runs.

If something looks off

Unexplained PDF failures, unknown processes or other signs of compromise call for preserving logs and deployment records and requesting a qualified review of containment and recovery. A successful PDF or an HTTP 200 shows the service works today, not that nothing happened earlier. Patch status, reachability controls, conversion validation and incident assessment are separate facts to verify, as our article on monitoring beyond uptime explains.

Sources

This article summarizes the maintainer’s advisory, the official release notes and VulnCheck’s research as checked on 30 October 2026.