### Summary Stored cross-site scripting (XSS) in PrivateBin's attachment download link. An anonymous attacker can create a paste with a **text/html** attachment that, with certain user interaction, bypasses protections similar to CVE-2022-24833. When a victim opens the "Download attachment" link in a new tab, the attacker's inline JavaScript executes in the PrivateBin instance's origin with full same-origin capability (cookie/localStorage access, same-origin fetch). This is an incomplete fix of [CVE-2022-24833](https://github.com/PrivateBin/PrivateBin/security/advisories/GHSA-cqcc-mm6x-vmvw). The original fix only applies to the inline preview blob (in case of SVG), never to the download link's blob. Thus a **text/html** (or **image/svg**) attachment completely bypasses sanitization, re-enabling the exact attack class on instances that don't enforce the recommended Content-Security-Policy, but with a slightly different attack process. Instances using the default recommended CSP are protected (the blob inherits **script-src 'self'**, blocking inline scripts). The vulnerability affects instances where CSP is weakened, stripped, or absent, which is exactly the defense-in-depth scenario the CVE-2022-24833 fix was meant to cover. Requires **fileupload = true** (non-default) and a non-recommended CSP configuration. ### Details In **js/privatebin.js**, the function **AttachmentViewer.setAttachment** (line 2982) processes decrypted attachment data. Since PrivateBin uses zero-knowledge encryption, the entire decrypted message (including attachment content and MIME type) is attacker-controlled and can't be inspected or sanitized by the server. **Root cause 1: MIME-gated sanitization (line 3017)** DOMPurify sanitization only triggers when the MIME type matches **/^image\/.\*svg/i**. Any other active content type (such as **text/html**, **application/xhtml+xml**, **text/xml**) completely bypasses sanitization. ```js // js/privatebin.js:3017-3023 if (mimeType.match(/^image\/.*svg/i)) { // only SVG is considered const sanitizedData = DOMPurify.sanitize( decodedData, purifySvgConfig ); blobUrl = getBlobUrl(sanitizedData, mimeType); // reassigns LOCAL variable only } ``` **Root cause 2: download link always points to unsanitized blob (line 3002)** The "Download attachment" link's **href** is set to the unsanitized blob URL at line 3002, before the SVG sanitization branch. The SVG branch (line 3022) only reassigns a local variable **blobUrl** that's consumed by the preview at line 3028. It never updates the download link. So even for SVG attachments, the download link carries unsanitized content. ```js // js/privatebin.js:3001-3002 let blobUrl = getBlobUrl(decodedData, mimeType); // unsanitized blob attachmentLink.attr('href', blobUrl); // download link set HERE (never updated) ``` **Root cause 3: MIME type is fully attacker-controlled** The MIME type is extracted from the decrypted data URI at line 3211-3217 via **getAttachmentMimeType**, which simply reads the substring between **data:** and **;** in the data URI. Since this value comes from the decrypted (attacker-created) payload, the attacker chooses whatever MIME type they want. The browser then creates a **Blob** with that exact **Content-Type** at line 2963-2967 via **getBlobUrl**. **Attack flow:** 1. Attacker creates a paste with an attached **.html** file. The client encodes it as **data:text/html;base64,...** and encrypts it. 2. Victim opens the paste URL. **decryptPaste** (line 5387-5397) decrypts the message and calls **setAttachment** with the attacker's data URI. 3. **setAttachment** creates a same-origin **blob:http://instance/...** with **Content-Type: text/html** containing the attacker's HTML+script. This blob is assigned to the "Download attachment" link's **href** without any sanitization. 4. Victim opens that link in a new tab (right-click, middle-click, or social-engineered left-click). The browser renders the blob as a full HTML document in the instance's origin, executing the attacker's inline JavaScript. **Relation to CVE-2022-24833:** The [2022 advisory](https://privatebin.info/reports/vulnerability-2022-04-09.html) claimed: *"whether you open the SVG in a new tab or not and whether CSP is present and enabled or not does not matter any more, as the displayed SVG is sanitized."* This doesn't hold because: - The download link's blob is never sanitized (only the preview blob is). - The advisory's safety argument for the download link ("opens from file:// protocol") assumes the file is downloaded to disk. Opening the link in a new tab navigates to a same-origin **blob:** URL instead. ### Proof of concept **Environment:** - PrivateBin commit **597a6f0d** (version 2.0.4+) - PHP 8.x with built-in server - Chromium-based browser (tested in Playwright/Chromium) **Step 1: Set up a vulnerable instance** ```bash git clone https://github.com/PrivateBin/PrivateBin.git cd PrivateBin git ch