CVE-2025-62796

PrivateBin is an online pastebin where the server has zero knowledge of pasted data. Versions 1.7.7 through 2.0.1 allow persistent HTML injection via the unsanitized attachment filename (attachment_name) when attachments are enabled. An attacker can modify attachment_name before encryption so that, after decryption, arbitrary HTML is inserted unescaped into the page near the file size hint, enabling redirect (e.g., meta refresh) and site defacement and related phishing attacks. Script execution is normally blocked by the recommended Content Security Policy, limiting confidentiality impact. The issue was introduced in 1.7.7 and fixed in 2.0.2. Update to 2.0.2 or later. Workarounds include enforcing the recommended CSP, deploying PrivateBin on a separate domain, or disabling attachments.

PrivateBin is an online pastebin where the server has zero knowledge of pasted data. Versions 1.7.7 through 2.0.1 allow persistent HTML injection via the unsanitized attachment filename (attachment_name) when attachments are enabled. An attacker can modify attachment_name before encryption so that, after decryption, arbitrary HTML is inserted unescaped into the page near the file size hint, enabling redirect (e.g., meta refresh) and site defacement and related phishing attacks. Script execution is normally blocked by the recommended Content Security Policy, limiting confidentiality impact. The issue was introduced in 1.7.7 and fixed in 2.0.2. Update to 2.0.2 or later. Workarounds include enforcing the recommended CSP, deploying PrivateBin on a separate domain, or disabling attachments.

We’ve identified an HTML injection/XSS vulnerability in PrivateBin service that allows the injection of arbitrary HTML markup via the attached filename. Below are the technical details, PoC, reproduction steps, impact, and mitigation recommendations.

Recommend action: As the vulnerability has been fixed in the latest version, users are strongly encouraged to upgrade PrivateBin to the latest version and check that a strong CSP header, just as the default suggested one, is delivered.

Summary of the vulnerability: The attachment_name field containing the attached file name is included in the object that the client encrypts and is eventually rendered in the DOM without proper escaping.

Impact

The vulnerability allows attackers to inject arbitrary HTML into the filename displayed near the file size hint, when attachments are enabled. This is by definition a XSS vulnerability (CWE-80), in this case even a persistent XSS. As any HTML can be injected, basically, this can e.g. be used to inject a script tag (as per CWE-79).

That said, also due to previous issues, we have strong mitigations for this in place. The content security policy (CSP) does, if configured as recommend by the PrivateBin project, prevent any inline script execution, so the confidentiality of the paste is not affected.

However, as the reporter demonstrated, even when script execution is blocked, an HTML injection can still be used for attacks such as:

• redirection using a meta redirect tag to redirect to a potentially malicious/attacker-controlled website
• defacement of the website
• phishing, in combination with the redirection to a clone of a PrivateBin phishing page or similar
• potential attacks on other services hosted on the same domain

This list is by no means meant to be exhaustive, other attacks should be considered possible, that is why we treat this issue as a serious issue, even if the CSP is supposed to block the most attacks.

[!IMPORTANT]
Depending on the deployment, if the server has a different than the recommend CSP configured or the client (browser) somehow lacks a protection, the vulnerability can have much more serious impacts and potentially also allow XSS, which could mean the confidentiality of the PrivateBin instance is affected.

Technical Description

The front-end uses PrivateBin (client-side encryption) to format and encrypt data before sending. During the paste creation process, the client assembles a cipherMessage object containing, among other fields:

• paste -> paste text
• attachment -> file content (data-URI)
• attachment_name -> array with file names

Before encryption, the ServerInteraction.setCipherMessage(cipherMessage) function is called. By intercepting/altering the cipherMessage on the client immediately before encryption, it is possible to replace attachment_name with an attacker-controlled string; this string becomes part of the encrypted content, and when the paste is opened, the local client decrypts and inserts the name into the DOM unescaped, allowing the interpretation of inserted HTML markup.

Note that it was not necessary to reimplement encryption: the monkeypatch modifies the object before the client applies AES-GCM/PBKDF2/compression, thus avoiding ciphertext formatting issues.

Proof of concept

Paste this into the console on the PrivateBin page before clicking Create.

// Monkeypatch to modify attachment_name immediately before encryption
(() => {
  const desiredName = '"><meta http-equiv="refresh" content="0;url=https://example.com/">.txt'; // <- adjust here

  // get the namespace used by PrivateBin
  if (!window.$ || !$.PrivateBin || !$.PrivateBin.ServerInteraction) {
    return console.error('PrivateBin namespace not found (make sure you are on…

PrivateBin is an online pastebin where the server has zero knowledge of pasted data. Versions 1.7.7 through 2.0.1 allow persistent HTML injection via the unsanitized attachment filename (attachment_name) when attachments are enabled. An attacker can modify attachment_name before encryption so that, after decryption, arbitrary HTML is inserted unescaped into the page near the file size hint, enabling redirect (e.g., meta refresh) and site defacement and related phishing attacks. Script execution is normally blocked by the recommended Content Security Policy, limiting confidentiality impact. The issue was introduced in 1.7.7 and fixed in 2.0.2. Update to 2.0.2 or later. Workarounds include enforcing the recommended CSP, deploying PrivateBin on a separate domain, or disabling attachments.

PrivateBin is an online pastebin where the server has zero knowledge of pasted data. Versions 1.7.7 through 2.0.1 allow persistent HTML injection via the unsanitized attachment filename (attachment_name) when attachments are enabled. An attacker can modify attachment_name before encryption so that, after decryption, arbitrary HTML is inserted unescaped into the page near the file size hint, enabling redirect (e.g., meta refresh) and site defacement and related phishing attacks. Script execution is normally blocked by the recommended Content Security Policy, limiting confidentiality impact. The issue was introduced in 1.7.7 and fixed in 2.0.2. Update to 2.0.2 or later. Workarounds include enforcing the recommended CSP, deploying PrivateBin on a separate domain, or disabling attachments.

We’ve identified an HTML injection/XSS vulnerability in PrivateBin service that allows the injection of arbitrary HTML markup via the attached filename. Below are the technical details, PoC, reproduction steps, impact, and mitigation recommendations.

Recommend action: As the vulnerability has been fixed in the latest version, users are strongly encouraged to upgrade PrivateBin to the latest version and check that a strong CSP header, just as the default suggested one, is delivered.

Summary of the vulnerability: The attachment_name field containing the attached file name is included in the object that the client encrypts and is eventually rendered in the DOM without proper escaping.

Impact

The vulnerability allows attackers to inject arbitrary HTML into the filename displayed near the file size hint, when attachments are enabled. This is by definition a XSS vulnerability (CWE-80), in this case even a persistent XSS. As any HTML can be injected, basically, this can e.g. be used to inject a script tag (as per CWE-79).

That said, also due to previous issues, we have strong mitigations for this in place. The content security policy (CSP) does, if configured as recommend by the PrivateBin project, prevent any inline script execution, so the confidentiality of the paste is not affected.

However, as the reporter demonstrated, even when script execution is blocked, an HTML injection can still be used for attacks such as:

• redirection using a meta redirect tag to redirect to a potentially malicious/attacker-controlled website
• defacement of the website
• phishing, in combination with the redirection to a clone of a PrivateBin phishing page or similar
• potential attacks on other services hosted on the same domain

This list is by no means meant to be exhaustive, other attacks should be considered possible, that is why we treat this issue as a serious issue, even if the CSP is supposed to block the most attacks.

[!IMPORTANT]
Depending on the deployment, if the server has a different than the recommend CSP configured or the client (browser) somehow lacks a protection, the vulnerability can have much more serious impacts and potentially also allow XSS, which could mean the confidentiality of the PrivateBin instance is affected.

Technical Description

The front-end uses PrivateBin (client-side encryption) to format and encrypt data before sending. During the paste creation process, the client assembles a cipherMessage object containing, among other fields:

• paste -> paste text
• attachment -> file content (data-URI)
• attachment_name -> array with file names

Before encryption, the ServerInteraction.setCipherMessage(cipherMessage) function is called. By intercepting/altering the cipherMessage on the client immediately before encryption, it is possible to replace attachment_name with an attacker-controlled string; this string becomes part of the encrypted content, and when the paste is opened, the local client decrypts and inserts the name into the DOM unescaped, allowing the interpretation of inserted HTML markup.

Note that it was not necessary to reimplement encryption: the monkeypatch modifies the object before the client applies AES-GCM/PBKDF2/compression, thus avoiding ciphertext formatting issues.

Proof of concept

Paste this into the console on the PrivateBin page before clicking Create.

// Monkeypatch to modify attachment_name immediately before encryption
(() => {
  const desiredName = '"><meta http-equiv="refresh" content="0;url=https://example.com/">.txt'; // <- adjust here

  // get the namespace used by PrivateBin
  if (!window.$ || !$.PrivateBin || !$.PrivateBin.ServerInteraction) {
    return console.error('PrivateBin namespace not found (make sure you are on…