Gotenberg has a Server-Side Request Forgery (SSRF) Issue
Date: 2026-05
Affected: go/github.com/gotenberg/gotenberg/v8
Attack vector: ssrf
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2026-42591
CWE: CWE-918
CVSS: 8.2 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N)

### Summary The SSRF hardening shipped in v8.31.0 only covers outbound URLs that Gotenberg's Go code handles — Chromium asset fetches, webhook delivery, and download-from. The LibreOffice conversion endpoint (`/forms/libreoffice/convert`) passes uploaded documents directly to LibreOffice without inspecting their content. LibreOffice then fetches any embedded external URLs on its own, completely bypassing the SSRF filters. This was verified on v8.31.0 (latest at time of writing) with a crafted DOCX and got 3 outbound HTTP requests from LibreOffice to the canary server used for testing. ### Details When a file is uploaded to `/forms/libreoffice/convert`, the route in `pkg/modules/libreoffice/routes.go` reads form parameters and passes the input file directly to `libreOffice.Pdf()`: ```go err = libreOffice.Pdf(ctx, ctx.Log(), inputPath, outputPaths[i], options) ``` There's no content inspection happening before the file reaches LibreOffice. The SSRF protection in v8.31.0 (`pkg/gotenberg/outbound.go`) wraps Go's `http.Client` with a custom dialer that resolves URLs and rejects non-public IPs — but LibreOffice is a separate process that makes its own HTTP connections via libcurl. The Go-level dial hooks can't intercept that. OOXML formats like DOCX can embed external image references using `TargetMode="External"` in relationship files. LibreOffice fetches those URLs during PDF conversion. **Suggested fix:** Run LibreOffice with `unshare --net` to drop all network access fr


Mitigations:

Architectural layers (MAESTRO):