CVE-2026-45742

The vulnerability in Gotenberg versions 8.10.0 through 8.32.0 is a data race on a Go map accessed during concurrent multipart request handling. When downloadFrom is enabled (the default), an unauthenticated remote attacker can send malformed requests that trigger a fatal runtime panic, crashing the conversion service deterministically. The CVSS 7.5 rating captures severity but flattens important nuance: this is trivially exploitable, requires no authentication, and targets a service that typically runs in automated pipelines where downtime cascades silently into failed CI runs, unprocessed documents, and workflow stalls that may go unnoticed until they overwhelm downstream systems. The more important analytical question is not the bug itself — Go's race detector would have caught this on the first commit — but why it survived across 23 releases. This suggests the project lacks automated race detection in its build pipeline, a basic practice for any team shipping concurrent Go code. The -race flag is not a luxury; it is the tool the language provides specifically for this class of defect. That it was not deployed represents a systemic gap in the project's security engineering posture, not merely a one-off coding error. For defenders, three actions matter. First, verify whether version 8.33.0 implements proper mutex protection or refactors away from concurrent map writes — the fix's architecture determines whether you should audit the codebase for similar patterns. Second, examine your deployment footprint: Gotenberg running in default configuration behind any exposed port is an immediately exploitable DoS vector. Third, assess whether downstream document conversion pipelines depend on this service, because a crash does not just stop conversion — it stalls every workflow chained to it. The EPSS score of 0.00496 likely underestimates real-world risk. Gotenberg's typical deployment as a containerized API utility means automated scanners target it aggressively, and its frequent placement in CI/CD pipelines means the blast radius of exploitation extends beyond the service itself into build processes and artifact generation. The patch existing is not the same as the vulnerability being retired — remediation lag in containerized utilities often significantly exceeds the patch-to-disclosure window.

Reviewed through automated stages and approved by a human before publication.