<?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 05:14:13 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-136371</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-136371</link>
      <description>EUVD-2026-136371</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-136371</guid>
    </item>
    <item>
      <title>fkie_cve-2024-41948</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-41948</link>
      <description>&lt;p&gt;biscuit-java is the java implementation of Biscuit, an authentication and authorization token for microservices architectures. Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a ThirdPartyBlock request can be sent, providing only the necessary info to generate a third-party block and to sign it, which includes the public key of the previous block (used in the signature) and the public keys part of the token symbol table (for public key interning in datalog expressions). A third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair. This vulnerability is fixed in 4.0.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;biscuit-java is the java implementation of Biscuit, an authentication and authorization token for microservices architectures. Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a ThirdPartyBlock request can be sent, providing only the necessary info to generate a third-party block and to sign it, which includes the public key of the previous block (used in the signature) and the public keys part of the token symbol table (for public key interning in datalog expressions). A third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair. This vulnerability is fixed in 4.0.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-41948</guid>
    </item>
    <item>
      <title>GHSA-5hcj-rwm6-xmw4 — biscuit-java vulnerable to public key confusion in third party block</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-5hcj-rwm6-xmw4</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.biscuitsec:biscuit&lt;/p&gt;
&lt;p&gt;### Impact
Tokens with third-party blocks containing trusted annotations generated through a third party block request. Due to implementation issues in biscuit-java,  third party block support in published versions is inoperating. Nevertheless, to synchronize with other implementations, we publish this advisory and the related fix.&lt;/p&gt;
&lt;p&gt;### Description
Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a `ThirdPartyBlock` request can be sent, providing only the necessary info to generate a third-party block and to sign it:&lt;/p&gt;
&lt;p&gt;the public key of the previous block (used in the signature)
the public keys part of the token symbol table (for public key interning in datalog expressions)
A third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.&lt;/p&gt;
&lt;p&gt;Consider the following example (nominal case)
* Authority A emits the following token: `check if thirdparty(&amp;#34;b&amp;#34;) trusting ${pubkeyB}`
* The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority B
* Third-party B generates the following third-party block `thirdparty(&amp;#34;b&amp;#34;); check if thirdparty(&amp;#34;c&amp;#34;) trusting ${pubkeyC}`
* The token holder now must obtain a third-party block from third party C to be able to use the token&lt;/p&gt;
&lt;p&gt;Now, with a malicious user:
* Authority A emits the following token: `check if thirdparty(&amp;#34;b&amp;#34;) trusting ${pubkeyB}`
* The h…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.biscuitsec:biscuit&lt;/p&gt;
&lt;p&gt;### Impact
Tokens with third-party blocks containing trusted annotations generated through a third party block request. Due to implementation issues in biscuit-java,  third party block support in published versions is inoperating. Nevertheless, to synchronize with other implementations, we publish this advisory and the related fix.&lt;/p&gt;
&lt;p&gt;### Description
Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a `ThirdPartyBlock` request can be sent, providing only the necessary info to generate a third-party block and to sign it:&lt;/p&gt;
&lt;p&gt;the public key of the previous block (used in the signature)
the public keys part of the token symbol table (for public key interning in datalog expressions)
A third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.&lt;/p&gt;
&lt;p&gt;Consider the following example (nominal case)
* Authority A emits the following token: `check if thirdparty(&amp;#34;b&amp;#34;) trusting ${pubkeyB}`
* The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority B
* Third-party B generates the following third-party block `thirdparty(&amp;#34;b&amp;#34;); check if thirdparty(&amp;#34;c&amp;#34;) trusting ${pubkeyC}`
* The token holder now must obtain a third-party block from third party C to be able to use the token&lt;/p&gt;
&lt;p&gt;Now, with a malicious user:
* Authority A emits the following token: `check if thirdparty(&amp;#34;b&amp;#34;) trusting ${pubkeyB}`
* The h…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-5hcj-rwm6-xmw4</guid>
    </item>
  </channel>
</rss>
