<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 23:21:13 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-257100</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-257100</link>
      <description>EUVD-2026-257100</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-257100</guid>
    </item>
    <item>
      <title>fkie_cve-2025-62796</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-62796</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-62796</guid>
    </item>
    <item>
      <title>GHSA-867c-p784-5q6g — PrivateBin is missing HTML sanitization of attached filename in file size hint</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-867c-p784-5q6g</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: privatebin/privatebin&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;**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](https://privatebin.info/directory/check) that a strong CSP header, just as the default suggested one, is delivered.&lt;/p&gt;
&lt;p&gt;**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.&lt;/p&gt;
&lt;p&gt;## 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)](https://cwe.mitre.org/data/definitions/80.html), 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)](https://cwe.mitre.org/data/definitions/79.html).&lt;/p&gt;
&lt;p&gt;That said, also due to [previous issues](#more-informaton), we have strong mitigations for this in place. The [content security policy (CSP)](https://content-security-policy.com/) does, if configured as recommend by the PrivateBin project, prevent any inline script execution, so the confidentiality of…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: privatebin/privatebin&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;**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](https://privatebin.info/directory/check) that a strong CSP header, just as the default suggested one, is delivered.&lt;/p&gt;
&lt;p&gt;**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.&lt;/p&gt;
&lt;p&gt;## 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)](https://cwe.mitre.org/data/definitions/80.html), 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)](https://cwe.mitre.org/data/definitions/79.html).&lt;/p&gt;
&lt;p&gt;That said, also due to [previous issues](#more-informaton), we have strong mitigations for this in place. The [content security policy (CSP)](https://content-security-policy.com/) does, if configured as recommend by the PrivateBin project, prevent any inline script execution, so the confidentiality of…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-867c-p784-5q6g</guid>
    </item>
  </channel>
</rss>
