<?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 04:49:26 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-223713</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-223713</link>
      <description>EUVD-2026-223713</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-223713</guid>
    </item>
    <item>
      <title>fkie_cve-2025-30144</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-30144</link>
      <description>&lt;p&gt;fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 5.0.6, the fast-jwt library does not properly validate the iss claim based on the RFC 7519. The iss (issuer) claim validation within the fast-jwt library permits an array of strings as a valid iss value. This design flaw enables a potential attack where a malicious actor crafts a JWT with an iss claim structured as [&amp;#39;https://attacker-domain/&amp;#39;, &amp;#39;https://valid-iss&amp;#39;]. Due to the permissive validation, the JWT will be deemed valid. Furthermore, if the application relies on external libraries like get-jwks that do not independently validate the iss claim, the attacker can leverage this vulnerability to forge a JWT that will be accepted by the victim application. Essentially, the attacker can insert their own domain into the iss array, alongside the legitimate issuer, and bypass the intended security checks. This issue is fixed in 5.0.6.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 5.0.6, the fast-jwt library does not properly validate the iss claim based on the RFC 7519. The iss (issuer) claim validation within the fast-jwt library permits an array of strings as a valid iss value. This design flaw enables a potential attack where a malicious actor crafts a JWT with an iss claim structured as [&amp;#39;https://attacker-domain/&amp;#39;, &amp;#39;https://valid-iss&amp;#39;]. Due to the permissive validation, the JWT will be deemed valid. Furthermore, if the application relies on external libraries like get-jwks that do not independently validate the iss claim, the attacker can leverage this vulnerability to forge a JWT that will be accepted by the victim application. Essentially, the attacker can insert their own domain into the iss array, alongside the legitimate issuer, and bypass the intended security checks. This issue is fixed in 5.0.6.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-30144</guid>
    </item>
    <item>
      <title>GHSA-gm45-q3v2-6cf8 — Fast-JWT Improperly Validates iss Claims</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gm45-q3v2-6cf8</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: fast-jwt&lt;/p&gt;
&lt;p&gt;### Summary
The `fast-jwt` library does not properly validate the `iss` claim based on the RFC https://datatracker.ietf.org/doc/html/rfc7519#page-9.&lt;/p&gt;
&lt;p&gt;#### Details
The `iss` (issuer) claim validation within the fast-jwt library permits an array of strings as a valid `iss` value. This design flaw enables a potential attack where a malicious actor crafts a JWT with an `iss` claim structured as `[&amp;#39;https://attacker-domain/&amp;#39;, &amp;#39;https://valid-iss&amp;#39;]`. Due to the permissive validation, the JWT will be deemed valid.&lt;/p&gt;
&lt;p&gt;Furthermore, if the application relies on external libraries like `get-jwks` that do not independently validate the `iss` claim, the attacker can leverage this vulnerability to forge a JWT that will be accepted by the victim application. Essentially, the attacker can insert their own domain into the `iss` array, alongside the legitimate issuer, and bypass the intended security checks.&lt;/p&gt;
&lt;p&gt;#### PoC
Take a server running the following code:&lt;/p&gt;
&lt;p&gt;```js
const express = require(&amp;#39;express&amp;#39;)
const buildJwks = require(&amp;#39;get-jwks&amp;#39;)
const { createVerifier } = require(&amp;#39;fast-jwt&amp;#39;)&lt;/p&gt;
&lt;p&gt;const jwks = buildJwks({ providerDiscovery: true });
const keyFetcher = async (jwt) =&amp;gt;
    jwks.getPublicKey({
        kid: jwt.header.kid,
        alg: jwt.header.alg,
        domain: jwt.payload.iss
    });&lt;/p&gt;
&lt;p&gt;const jwtVerifier = createVerifier({
    key: keyFetcher,
    allowedIss: &amp;#39;https://valid-iss&amp;#39;,
});&lt;/p&gt;
&lt;p&gt;const app = express();
const port = 3000;&lt;/p&gt;
&lt;p&gt;app.use(express.json());&lt;/p&gt;
&lt;p&gt;async function verifyToken(req, res, n…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: fast-jwt&lt;/p&gt;
&lt;p&gt;### Summary
The `fast-jwt` library does not properly validate the `iss` claim based on the RFC https://datatracker.ietf.org/doc/html/rfc7519#page-9.&lt;/p&gt;
&lt;p&gt;#### Details
The `iss` (issuer) claim validation within the fast-jwt library permits an array of strings as a valid `iss` value. This design flaw enables a potential attack where a malicious actor crafts a JWT with an `iss` claim structured as `[&amp;#39;https://attacker-domain/&amp;#39;, &amp;#39;https://valid-iss&amp;#39;]`. Due to the permissive validation, the JWT will be deemed valid.&lt;/p&gt;
&lt;p&gt;Furthermore, if the application relies on external libraries like `get-jwks` that do not independently validate the `iss` claim, the attacker can leverage this vulnerability to forge a JWT that will be accepted by the victim application. Essentially, the attacker can insert their own domain into the `iss` array, alongside the legitimate issuer, and bypass the intended security checks.&lt;/p&gt;
&lt;p&gt;#### PoC
Take a server running the following code:&lt;/p&gt;
&lt;p&gt;```js
const express = require(&amp;#39;express&amp;#39;)
const buildJwks = require(&amp;#39;get-jwks&amp;#39;)
const { createVerifier } = require(&amp;#39;fast-jwt&amp;#39;)&lt;/p&gt;
&lt;p&gt;const jwks = buildJwks({ providerDiscovery: true });
const keyFetcher = async (jwt) =&amp;gt;
    jwks.getPublicKey({
        kid: jwt.header.kid,
        alg: jwt.header.alg,
        domain: jwt.payload.iss
    });&lt;/p&gt;
&lt;p&gt;const jwtVerifier = createVerifier({
    key: keyFetcher,
    allowedIss: &amp;#39;https://valid-iss&amp;#39;,
});&lt;/p&gt;
&lt;p&gt;const app = express();
const port = 3000;&lt;/p&gt;
&lt;p&gt;app.use(express.json());&lt;/p&gt;
&lt;p&gt;async function verifyToken(req, res, n…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gm45-q3v2-6cf8</guid>
    </item>
  </channel>
</rss>
