A high-severity, unauthenticated denial-of-service vulnerability in Gotenberg, one of the most widely deployed Docker-based PDF conversion APIs, allows any internet-accessible attacker to crash the entire service in roughly two seconds using nothing more than standard HTTP requests.
Tracked as CVE-2026-42594 (GHSA-r33j-c622-r6qp) with a CVSS score of 7.5, researchers at aisafe.io discovered the flaw, which affects all Gotenberg versions up to and including 8.31.0. Organizations running containerized document workflows, automated PDF pipelines, or developer-facing conversion APIs are directly exposed.
Gotenberg is a Docker-powered, stateless REST API that converts HTML, Office documents, and URLs into PDF files using headless Chromium and LibreOffice as backends. It is extensively used in enterprise and SaaS environments for automated document generation, report rendering, and content archival.
Its webhook feature allows clients to submit conversion jobs asynchronously. The service processes them in a background goroutine and delivers the output to a caller-specified URL, making it a go-to solution for high-throughput document pipelines.
CVE-2026-42594: Gotenberg DoS Vulnerability
The root cause is a race condition between Go’s object pool recycling and Gotenberg’s asynchronous webhook goroutine. When a webhook request arrives, Gotenberg’s middleware spawns a background goroutine that continues holding a live reference to the request’s echo.Context object.
Simultaneously, the synchronous handler returns api.ErrAsyncProcess, triggering Echo to issue a 204 No Content response and recycle that same echo.Context back to its sync.Pool.
Here is where the race turns lethal. When the next concurrent request claims the recycled context object, Echo’s c.Reset() call wipes the context’s internal store clean, including the “logger” entry populated during the original request’s middleware chain.
If the still-running webhook goroutine reaches hardTimeoutMiddleware at this exact moment, the code at pkg/modules/api/middlewares.go:398 performs an unchecked type assertion on that now-nil store entry: c.Get(“logger”).(*slog.Logger).
In Go, asserting a nil interface to a concrete type without the two-value form causes an immediate, unrecoverable panic. Since no recover() is in scope at line 398, the Go runtime terminates the entire Gotenberg process with exit code 2.
What makes CVE-2026-42594 especially dangerous is that zero authentication is required. Gotenberg’s webhook deny list blocks attacker-controlled webhook destinations within private networks to prevent SSRF. Still, it does not validate or restrict who can submit a webhook request.
Any unauthenticated caller with network access to port 3000 can trigger the vulnerable code path. Researchers confirmed the crash requires only a modest single-source load: approximately 24 concurrent webhook POST requests to /forms/chromium/convert/html combined with 60 concurrent GET /version requests, reliably crashing the process in under 2.5 seconds.
The attack works even against container deployments with auto-restart policies. While --restart=always in Docker or Kubernetes, liveness probes will bring Gotenberg back up.
The restart loop is continuous under sustained attack traffic, dropping every in-flight conversion, abandoning all pending webhook deliveries, and resetting internal state on each crash cycle. This means a single attacker can maintain near-total service unavailability indefinitely.
Affected Versions and Patch
All Gotenberg releases from v8.0 through v8.31.0 are vulnerable. The vulnerability was patched and publicly disclosed on May 6, 2026, in Gotenberg 8.32.0.
Additionally, the Snyk advisory flags a separate Race Condition issue also patched in 8.32.0, alongside an SSRF variant affecting versions 8.29.1 through 8.32.0, making the 8.32.0 upgrade a critical security baseline for all deployments.
The Gotenberg maintainer (gulien) recommends a layered fix. First, the unchecked type assertion must be replaced with the safe two-value Go idiom:
logger, _ := c.Get("logger").(*slog.Logger)
if logger == nil {
return errors.New("context reused from pool before middleware chain populated it")
}Second, a defer recover() block must be added at the top of the webhook goroutine body so that any downstream panic is caught and converted to a handled error rather than a process-terminating event.
The deepest architectural fix involves detaching echo.Context from api.Context entirely before the goroutine launches, extracting all required values (output filename, logger, correlation IDs) into plain variables or struct fields, then nullifying the echo context pointer, so the goroutine can never reach a pooled and recycled context regardless of timing.
Mitigation
For teams unable to upgrade immediately, the following interim controls reduce exposure:
- Deploy a reverse proxy or WAF in front of Gotenberg that enforces rate limiting on webhook-path POST requests, capping concurrent submissions per source IP
- Restrict network access to port 3000 using firewall rules, Kubernetes NetworkPolicy, or Docker network isolation, and limit access to only trusted internal services.
- Enable authentication middleware (API key headers) at the reverse proxy layer; Gotenberg itself has no built-in auth, making external enforcement critical.
- Monitor for rapid restart loops via container health checks and alerting a crash-restart cadence under load is an active indicator of exploitation.
- Upgrade to Gotenberg 8.32.0 as the only complete remediation
FAQ
Q1: Does CVE-2026-42594 require any credentials or special privileges to exploit?
No, any unauthenticated attacker who can reach Gotenberg on port 3000 can trigger the crash with only standard HTTP requests.
Q2: Will Docker’s --restart=always policy protect my service from this DoS?
No, while auto-restart brings Gotenberg back up, sustained attack traffic keeps it in a continuous crash loop, dropping all in-flight conversions and maintaining effective unavailability.
Q3: Which Gotenberg versions are affected, and what is the patched version?
All versions through 8.31.0 are vulnerable; upgrading to Gotenberg 8.32.0 is the only complete fix.
Q4: Is there a CVE identifier assigned to this Gotenberg vulnerability?
Yes, the vulnerability is formally tracked as CVE-2026-42594 with a CVSS v3.1 score of 7.5 (High), vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
