CVE-2026-44829 in Gotenberg
Summary
by MITRE • 08/19/2026
Gotenberg is a Docker-powered stateless API for PDF files. In 8.32.0 and earlier, filename handling in pkg/modules/api/context.go uses filepath.Base on Linux, which does not treat backslashes as path separators, so a multipart filename containing Windows-style parent directory components survives sanitization. The original filename flows through ctx.diskToOriginal and the multi-output PDF routes into archives.FilesFromDisk and archives.Zip.Archive as the generated zip entry name. A remote attacker can submit a name such as ........\Windows\System32\evil.pdf through an upload or an upstream downloadFrom Content-Disposition header, and a Windows archive extractor can write the resulting file outside the intended extraction directory. The affected paths include /forms/pdfengines/split and other multi-output PDF, LibreOffice, and conversion routes, and exploitation can cause arbitrary file writes on a downstream Windows system when a user or process extracts the returned archive. This issue is fixed in version 8.33.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/19/2026
Gotenberg operates as a stateless API containerized via Docker to facilitate PDF generation and manipulation through various conversion endpoints. The vulnerability identified involves a critical flaw in how the application handles filenames within multipart form data, specifically located in the pkg/modules/api/context.go module of versions 8.32.0 and earlier. This issue stems from an inconsistency between operating system path handling conventions during sanitization processes. On Linux systems, which typically serve as the host environment for such Docker containers, the filepath.Base function does not recognize backslashes as valid path separators. Consequently, when a client submits a filename containing Windows-style directory traversal sequences using forward slashes or mixed delimiters that include parent directory indicators like ..\, these components are not stripped away during the initial sanitization phase because they do not trigger standard Linux-based path normalization logic designed to prevent directory traversal attacks.
The technical flaw allows an attacker to inject malicious filenames into the processing pipeline by exploiting this discrepancy in path parsing behavior. When a remote user uploads a file or triggers a downloadFrom operation via the Content-Disposition header, the application passes the original filename through internal functions such as ctx.diskToOriginal and subsequently routes it into archives.FilesFromDisk and archives.Zip.Archive for packaging. Because the sanitization step failed to remove the Windows-specific parent directory components due to their survival under Linux path rules, these malicious paths are preserved in the metadata of the generated ZIP archive entry names. This creates a scenario where the integrity of file output is compromised, as the application effectively trusts user-supplied input without adequate cross-platform validation for all potential delimiter styles.
The operational impact of this vulnerability manifests when the resulting PDF or ZIP archive is downloaded and extracted by an end-user on a Windows operating system. Standard Windows archive extractors interpret backslashes as path separators and process parent directory indicators like ..\ to navigate up the file hierarchy. As a result, if an attacker submits a filename such as ........\Windows\System32\evil.pdf, the extraction tool will write the extracted content directly into C:\Windows\System32 or other sensitive system directories outside of the intended download folder. This constitutes an arbitrary file write vulnerability that can lead to significant security breaches on client machines, potentially allowing for malware installation, configuration tampering, or privilege escalation depending on the permissions of the user performing the extraction.
This flaw affects multiple endpoints within Gotenberg, including /forms/pdfengines/split and other routes handling multi-output PDFs, LibreOffice conversions, and general file transformations where archives are generated as part of the response payload. The risk is primarily directed at downstream consumers who operate in Windows environments, although it represents a fundamental failure in input validation that violates secure coding principles. To mitigate this issue, organizations should immediately upgrade to Gotenberg version 8.33.0 or later, which implements corrected path handling logic that properly sanitizes filenames across different operating system conventions regardless of the delimiter style used by the client. Additionally, until an update is applied, administrators can implement reverse proxy rules or WAF policies to block requests containing suspicious filename patterns with backslashes and parent directory indicators before they reach the application layer.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the system failed to neutralize special elements within user input that could alter expected file operations. It also relates closely to CWE-75 Failure to Sanitize Path Special Elements, specifically regarding directory traversal sequences. In terms of offensive security frameworks, this technique is consistent with ATT&CK T1048 Exploitation for File Execution or Data Staging via Archive manipulation, where attackers leverage archive features to bypass sandboxing or isolation mechanisms by writing files to unexpected locations. The remediation strategy emphasizes the importance of enforcing strict allow-lists on filename characters and normalizing paths using OS-agnostic validation logic that accounts for both forward slashes and backslashes as potential path separators during input processing stages.