<?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://db.gcve.eu</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>Sat, 10 Oct 2026 10:30:18 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-107722</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-107722</link>
      <description>&lt;p&gt;fast-jwt provides fast JSON Web Token (JWT) implementation. From 6.2.0 until 6.3.0, fast-jwt can misclassify RSA public-key text as an HMAC secret when the key has non-whitespace content before its PEM header. In src/crypto.js, performDetectPublicKeyAlgorithms trims whitespace but publicKeyPemMatcher remains start-anchored, so comments, control characters, zero-width characters, or wrapper text can prevent PEM detection and reach the HMAC fallback. An attacker who knows the public key bytes can sign arbitrary HS256 claims with that public material when HS256 is inferred or allowed, resulting in authentication or authorization bypass. An asymmetric-only algorithm allowlist prevents the attack. This issue is fixed in version 6.3.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;fast-jwt provides fast JSON Web Token (JWT) implementation. From 6.2.0 until 6.3.0, fast-jwt can misclassify RSA public-key text as an HMAC secret when the key has non-whitespace content before its PEM header. In src/crypto.js, performDetectPublicKeyAlgorithms trims whitespace but publicKeyPemMatcher remains start-anchored, so comments, control characters, zero-width characters, or wrapper text can prevent PEM detection and reach the HMAC fallback. An attacker who knows the public key bytes can sign arbitrary HS256 claims with that public material when HS256 is inferred or allowed, resulting in authentication or authorization bypass. An asymmetric-only algorithm allowlist prevents the attack. This issue is fixed in version 6.3.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-107722</guid>
    </item>
    <item>
      <title>GHSA-ww5h-9m49-7xx4 — fast-jwt: Incomplete patch of CVE-2026-34950: Non-whitespace key-prefix re-enables RSA→HS256 algorithm confusion</title>
      <link>https://db.gcve.eu/vuln/ghsa-ww5h-9m49-7xx4</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: fast-jwt&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The fix for CVE-2026-34950 (CVSS 9.1, released in v6.2.0) is **incomplete**. It adds `key.trim()` to the PEM-detection path in `src/crypto.js`, but `String.prototype.trim()` only strips characters classified as whitespace by the ECMAScript specification. The subsequent `^`-anchored regex (`/^-----BEGIN(?: (RSA))? PUBLIC KEY-----/`) still requires the PEM header at position 0 — so **any non-whitespace leading byte** (control chars, zero-width unicode, `#` comments, HTTP-style headers, PGP wrappers) bypasses detection and falls through to the HMAC verification path, using the RSA public key as the HMAC shared secret. Net result: the **exact same RSA→HS256 algorithm-confusion attack** the original CVE addressed is fully re-enabled with a slightly different leading byte.&lt;/p&gt;
&lt;p&gt;**Attack prerequisites are identical to CVE-2026-34950**: attacker knows the target&amp;#39;s public RSA key (which is public by definition), and the target loads that key from a source whose content may have a non-whitespace prefix (DB column with corrupted encoding, YAML config with inline comment, copy-paste from formatted document, etc.).&lt;/p&gt;
&lt;p&gt;**Verified on fast-jwt@6.2.2 (latest as of 2026-04-23) with a 10-line PoC.**&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;Post-patch code (`src/crypto.js`, lines ~74-171 in `performDetectPublicKeyAlgorithms`):&lt;/p&gt;
&lt;p&gt;```js
function performDetectPublicKeyAlgorithms(key) {
    const trimmedKey = key.trim()  // &amp;lt;-- CVE-2026-34950 patch added this
    if (publicKeyPemMatcher.test(trimmedKey)) {
        // t…&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&lt;/p&gt;
&lt;p&gt;The fix for CVE-2026-34950 (CVSS 9.1, released in v6.2.0) is **incomplete**. It adds `key.trim()` to the PEM-detection path in `src/crypto.js`, but `String.prototype.trim()` only strips characters classified as whitespace by the ECMAScript specification. The subsequent `^`-anchored regex (`/^-----BEGIN(?: (RSA))? PUBLIC KEY-----/`) still requires the PEM header at position 0 — so **any non-whitespace leading byte** (control chars, zero-width unicode, `#` comments, HTTP-style headers, PGP wrappers) bypasses detection and falls through to the HMAC verification path, using the RSA public key as the HMAC shared secret. Net result: the **exact same RSA→HS256 algorithm-confusion attack** the original CVE addressed is fully re-enabled with a slightly different leading byte.&lt;/p&gt;
&lt;p&gt;**Attack prerequisites are identical to CVE-2026-34950**: attacker knows the target&amp;#39;s public RSA key (which is public by definition), and the target loads that key from a source whose content may have a non-whitespace prefix (DB column with corrupted encoding, YAML config with inline comment, copy-paste from formatted document, etc.).&lt;/p&gt;
&lt;p&gt;**Verified on fast-jwt@6.2.2 (latest as of 2026-04-23) with a 10-line PoC.**&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;Post-patch code (`src/crypto.js`, lines ~74-171 in `performDetectPublicKeyAlgorithms`):&lt;/p&gt;
&lt;p&gt;```js
function performDetectPublicKeyAlgorithms(key) {
    const trimmedKey = key.trim()  // &amp;lt;-- CVE-2026-34950 patch added this
    if (publicKeyPemMatcher.test(trimmedKey)) {
        // t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-ww5h-9m49-7xx4</guid>
    </item>
  </channel>
</rss>
