CVE-2026-54732: Path Traversal
Impact options.fileName is used to build a filesystem path (path.join(tempDir.name, fileName)) and the caller-supplied document buffer is written there, but fileName is never reduced to a base name. A fileName containing "../" escapes the temporary directory, so a caller can write arbitrary content to an arbitrary path the process can write to (e.g. ~/.ssh/authorizedkeys, an /etc/cron.d entry, or a web root).
Patches Version 1.8.2 uses path.basename on filename to make sure the temp directory can not be escaped.
Workarounds Make sure you supply the filename yourself and don't have it user supplied or use path.basename on filename before using it in libreoffice-convert.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/libreoffice-convertto a version that resolves this vulnerability.Fixed in 1.8.2 - Upgrade
Upgrade
libreoffice-convertto a version that resolves this vulnerability.Fixed in 1.8.2 - Configuration
Ensure the value used for `fileName`/`options.fileName` is not user-supplied path content. Do not pass untrusted `filename` directly into `path.join(tempDir.name, fileName)`. Reduce it to a base name (as done in v1.8.2) before using it so the temporary directory cannot be escaped.
libreoffice-convert options.fileName / filename handling = Use a caller-controlled filename only; do not accept user-supplied path and ensure it is reduced to a base name (e.g., use path.basename) before building paths
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using npm/libreoffice-convert are exposed when they pass an attacker-controlled value as options.fileName. The impact is limited by the filesystem permissions of the process running the application.
What does an attacker need to exploit it?
An attacker needs a way to control the filename supplied to libreoffice-convert. No user interaction is required once a low-privileged attacker can provide a filename containing path traversal sequences such as ../.
Is there a fixed version?
Version 1.8.2 applies path.basename to the filename, preventing it from escaping the temporary directory.
What can be done before upgrading?
Ensure filenames are assigned by the application rather than accepted from users. If user input must be used, apply path.basename to the filename before passing it to libreoffice-convert.
How can we assess whether our integration is vulnerable?
Review calls to libreoffice-convert for use of options.fileName and trace whether its value can originate from request data, uploaded-file metadata, or other untrusted input. Affected code permits ../ in that value to target paths outside the temporary directory that the process can write.