GHSA-r9x7-7ggj-fx9f
LOWPrivateBin vulnerable to malicious filename use for self-XSS / HTML injection locally for users
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
privatebin/privatebinReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Dragging a file whose filename contains HTML is reflected verbatim into the page via the drag-and-drop helper, so any user who drops a crafted file on PrivateBin will execute arbitrary JavaScript within their own session (self-XSS). This allows an attacker who can entice a victim to drag or otherwise attach such a file to exfiltrate plaintext, encryption keys, or stored pastes before they are encrypted or sent.
Note 1: as the malicious filename must contain the > character, the victim must not be using Windows for this to work, since this OS simply forbids this character in filenames.
Note 2: most PrivateBin instances use the Content-Security-Policy header to prevent most use-cases of this vulnerability. This report will describe the impact as if this header had been disabled by the PrivateBin instance owner.
Affected versions
PrivateBin versions since 1.7.7 and before 2.0.3.
Conditions
- Only macIOS or Linux users are affected, due to the way the
>character is treated in a file name on Windows. - The PrivateBIn instance needs to have file upload enabled.
- An attacker needs to have access to the local file system or somehow convince the user to create (or download) a malicious file (name).
- An attacker needs to convince the user to attach that malicious file to PrivateBin.
Impact
Any Mac / Linux user who can be tricked into dragging a maliciously named file into the editor is impacted; code runs in the origin of the PrivateBin instance they are using. Attackers can steal plaintext, passphrases, or manipulate the UI before data is encrypted, defeating the zero-knowledge guarantees for that victim session, assuming counter-measures like Content-Security-Policy (CSP) have been disabled.
If CSP is not disabled, similar HTML injection attacks as described in CVE-2025-62796 may be possible - like redirecting to a foreign website, phishing etc.
Real-life impact
As the whole exploit needs to be included in the file name of the attached file and only affects the local session of the user (aka it is neither persistent nor remotely executable) and that user needs to interact and actively attach that file to the paste, the impact is considered to be practically low.
Technical Description
When a file is dropped, readFileData collects all filenames and calls printDragAndDropFileNames:
const fileNames = loadedFiles.map((loadedFile => loadedFile.name));
printDragAndDropFileNames(fileNames);
printDragAndDropFileNames then renders those names:
function printDragAndDropFileNames(fileNames) {
$dragAndDropFileNames.html(fileNames.join('<br>'));
}
This will insecurely render the user-submitted filenames as HTML.
This vulnerability has been introduced in this commit (introduced in 1.7.7).
The previous render method was using .text():
$dragAndDropFileName.text(loadedFile.name);
Reproduction Steps
- On a Unix-like system, create a file with an HTML/JS payload in its name, e.g. by running
touch '"><img src=x onerror=alert(document.domain)>.txt'. - Deploy or use any PrivateBin instance with attachments enabled (including https://privatebin.net/).
- Open the UI in a browser and start a new paste.
- Drag the crafted file anywhere on the page
- As soon as it is dropped, the filename is inserted into
#dragAndDropFileNameas HTML and the onerror handler fires (assuming CSP is disabled), showing the alert.
Mitigation
PrivateBin strongly recommends users to upgrade to the latest release. However, here are some workarounds that may help users to mitigate this vulnerability without upgrade:
- Update the CSP in your configuration file to the latest recommended settings and check that it isn't getting reverted or overwritten by the web server, reverse proxy or CDN, i.e. using PrivateBin's offered check service. Note: Users should check the CSP independently, even if they've upgrade to a fixed version.
- Deploying PrivateBin on a separate domain may limit the scope of the vulnerability to PrivateBin itself and thus, as described in the “Impact” section, effectively prevent any damage by the vulnerability to other resources users are hosting.
- As explained in the impact assessment, disabling attachments also prevents this issue.
Patches
The issue has been patched in version 2.0.3.
Credits
PrivateBin would like to thank Benoit Esnard, who reported this vulnerability.
In general, PrivateBin would like to thank everyone reporting issues and potential vulnerabilities.
If a user thinks they have found a vulnerability or potential security risk, PrivateBin would kindly ask you to follow our security policy and report it. PrivateBin will then assess the report and will take the necessary actions to address it.
Timeline
- 2025-11-09 Received report via GitHub Security Advisory
- 2025-11-10 Discussed and reproduced issue, created a patch
- 2025-11-11 Further work on patch
- 2025-11-12 Released patch with PrivateBin 2.0.3
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | privatebin/privatebin | ≥ 1.7.7&&< 2.0.3 | 2.0.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for privatebin/privatebin. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update privatebin/privatebin to 2.0.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r9x7-7ggj-fx9f is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-r9x7-7ggj-fx9f is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-r9x7-7ggj-fx9f. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-r9x7-7ggj-fx9f in your dependencies?
O3 detects GHSA-r9x7-7ggj-fx9f across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.