<?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>Thu, 15 Oct 2026 03:04:47 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-31502</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-31502</link>
      <description>EUVD-2026-31502</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-31502</guid>
    </item>
    <item>
      <title>fkie_cve-2021-41106</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-41106</link>
      <description>&lt;p&gt;JWT is a library to work with JSON Web Token and JSON Web Signature. Prior to versions 3.4.6, 4.0.4, and 4.1.5, users of HMAC-based algorithms (HS256, HS384, and HS512) combined with `Lcobucci\JWT\Signer\Key\LocalFileReference` as key are having their tokens issued/validated using the file path as hashing key - instead of the contents. The HMAC hashing functions take any string as input and, since users can issue and validate tokens, users are lead to believe that everything works properly. Versions 3.4.6, 4.0.4, and 4.1.5 have been patched to always load the file contents, deprecated the `Lcobucci\JWT\Signer\Key\LocalFileReference`, and suggest `Lcobucci\JWT\Signer\Key\InMemory` as the alternative. As a workaround, use `Lcobucci\JWT\Signer\Key\InMemory` instead of `Lcobucci\JWT\Signer\Key\LocalFileReference` to create the instances of one&amp;#39;s keys.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;JWT is a library to work with JSON Web Token and JSON Web Signature. Prior to versions 3.4.6, 4.0.4, and 4.1.5, users of HMAC-based algorithms (HS256, HS384, and HS512) combined with `Lcobucci\JWT\Signer\Key\LocalFileReference` as key are having their tokens issued/validated using the file path as hashing key - instead of the contents. The HMAC hashing functions take any string as input and, since users can issue and validate tokens, users are lead to believe that everything works properly. Versions 3.4.6, 4.0.4, and 4.1.5 have been patched to always load the file contents, deprecated the `Lcobucci\JWT\Signer\Key\LocalFileReference`, and suggest `Lcobucci\JWT\Signer\Key\InMemory` as the alternative. As a workaround, use `Lcobucci\JWT\Signer\Key\InMemory` instead of `Lcobucci\JWT\Signer\Key\LocalFileReference` to create the instances of one&amp;#39;s keys.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-41106</guid>
    </item>
    <item>
      <title>GHSA-7322-jrq4-x5hf — File reference keys leads to incorrect hashes on HMAC algorithms</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7322-jrq4-x5hf</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: lcobucci/jwt&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Users of HMAC-based algorithms (HS256, HS384, and HS512) combined with `Lcobucci\JWT\Signer\Key\LocalFileReference` as key are having their tokens issued/validated using the file path as hashing key - instead of the contents.&lt;/p&gt;
&lt;p&gt;The HMAC hashing functions take any string as input and, since users can issue and validate tokens, people are lead to believe that everything works properly.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;All versions have been patched to always load the file contents, deprecated the `Lcobucci\JWT\Signer\Key\LocalFileReference`, and suggest `Lcobucci\JWT\Signer\Key\InMemory` as the alternative.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Use `Lcobucci\JWT\Signer\Key\InMemory` instead of `Lcobucci\JWT\Signer\Key\LocalFileReference` to create the instances of your keys:&lt;/p&gt;
&lt;p&gt;```diff
-use Lcobucci\JWT\Signer\Key\LocalFileReference;
+use Lcobucci\JWT\Signer\Key\InMemory;&lt;/p&gt;
&lt;p&gt;-$key = LocalFileReference::file(__DIR__ . &amp;#39;/public-key.pem&amp;#39;);
+$key = InMemory::file(__DIR__ . &amp;#39;/public-key.pem&amp;#39;);
```&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: lcobucci/jwt&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Users of HMAC-based algorithms (HS256, HS384, and HS512) combined with `Lcobucci\JWT\Signer\Key\LocalFileReference` as key are having their tokens issued/validated using the file path as hashing key - instead of the contents.&lt;/p&gt;
&lt;p&gt;The HMAC hashing functions take any string as input and, since users can issue and validate tokens, people are lead to believe that everything works properly.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;All versions have been patched to always load the file contents, deprecated the `Lcobucci\JWT\Signer\Key\LocalFileReference`, and suggest `Lcobucci\JWT\Signer\Key\InMemory` as the alternative.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Use `Lcobucci\JWT\Signer\Key\InMemory` instead of `Lcobucci\JWT\Signer\Key\LocalFileReference` to create the instances of your keys:&lt;/p&gt;
&lt;p&gt;```diff
-use Lcobucci\JWT\Signer\Key\LocalFileReference;
+use Lcobucci\JWT\Signer\Key\InMemory;&lt;/p&gt;
&lt;p&gt;-$key = LocalFileReference::file(__DIR__ . &amp;#39;/public-key.pem&amp;#39;);
+$key = InMemory::file(__DIR__ . &amp;#39;/public-key.pem&amp;#39;);
```&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7322-jrq4-x5hf</guid>
    </item>
    <item>
      <title>gsd-2021-41106</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2021-41106</link>
      <description>gsd-2021-41106</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2021-41106</guid>
    </item>
  </channel>
</rss>
