Common Weakness Enumeration

CWE-1289

Allowed

Improper Validation of Unsafe Equivalence in Input

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product receives an input value that is used as a resource identifier or other type of reference, but it does not validate or incorrectly validates that the input is equivalent to a potentially-unsafe value.

52 vulnerabilities reference this CWE, most recent first.

GHSA-H97M-WW89-6JMQ

Vulnerability from github – Published: 2024-12-09 20:41 – Updated: 2025-05-30 15:01
VLAI
Summary
`idna` accepts Punycode labels that do not produce any non-ASCII when decoded
Details

idna 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with idna 0.5.0 or earlier.

Concretely, example.org and xn--example-.org become equal after processing by idna 0.5.0 or earlier. Also, example.org.xn-- and example.org. become equal after processing by idna 0.5.0 or earlier.

In applications using idna (but not in idna itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an xn---masked name that turns into the name of the target when processed by idna 0.5.0 or earlier.

Remedy

Upgrade to idna 1.0.3 or later, if depending on idna directly, or to url 2.5.4 or later, if depending on idna via url. (This issue was fixed in idna 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)

When upgrading, please take a moment to read about alternative Unicode back ends for idna.

If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an issue about combining them with url 2.5.4 and idna 1.0.3.

Additional information

This issue resulted from idna 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in revision 33 of UTS 46.

Acknowledgements

Thanks to kageshiron for recognizing the security implications of this behavior.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "idna"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-12224"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289",
      "CWE-697"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-09T20:41:10Z",
    "nvd_published_at": "2025-05-30T02:15:19Z",
    "severity": "MODERATE"
  },
  "details": "`idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier.\n\nConcretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier.\n\nIn applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier.\n\n## Remedy\n\nUpgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)\n\nWhen upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest).\n\nIf you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an [issue](https://github.com/servo/rust-url/issues/992) about combining them with `url` 2.5.4 and `idna` 1.0.3.\n\n## Additional information\n\nThis issue resulted from `idna` 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in [revision 33 of UTS 46](https://www.unicode.org/reports/tr46/tr46-33.html#Modifications).\n\n## Acknowledgements\n\nThanks to kageshiron for recognizing the security implications of this behavior.",
  "id": "GHSA-h97m-ww89-6jmq",
  "modified": "2025-05-30T15:01:30Z",
  "published": "2024-12-09T20:41:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12224"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1887898"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/servo/rust-url"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0421.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "`idna` accepts Punycode labels that do not produce any non-ASCII when decoded"
}

GHSA-HPV8-77XM-27WX

Vulnerability from github – Published: 2026-06-04 18:30 – Updated: 2026-06-04 18:30
VLAI
Details

Net::CIDR::Set versions through 0.20 for Perl accept non-ASCII IP addresses and netmasks.

Unicode digits such as the Arabic-Indic One (U+0661) were accepted but not properly parsed as numbers. This could allow network masks to accept larger networks.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-49940"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-04T17:16:33Z",
    "severity": "MODERATE"
  },
  "details": "Net::CIDR::Set versions through 0.20 for Perl accept non-ASCII IP addresses and netmasks.\n\nUnicode digits such as the Arabic-Indic One (U+0661) were accepted but not properly parsed as numbers.  This could allow network masks to accept larger networks.",
  "id": "GHSA-hpv8-77xm-27wx",
  "modified": "2026-06-04T18:30:32Z",
  "published": "2026-06-04T18:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40911"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49940"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/RRWO/Net-CIDR-Set-0.21/changes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HWR4-MQ23-WCV5

Vulnerability from github – Published: 2026-04-08 19:53 – Updated: 2026-04-09 19:05
VLAI
Summary
mercure has Topic Selector Cache Key Collision
Details

Impact

A cache key collision vulnerability in TopicSelectorStore allows an attacker to poison the match result cache, potentially causing private updates to be delivered to unauthorized subscribers or blocking delivery to authorized ones.

The cache key was constructed by concatenating the topic selector and topic with an underscore separator:

k = "m_" + topicSelector + "_" + topic

Because both topic selectors and topics can contain underscores, two distinct pairs can produce the same key:

selector="foo_bar"  topic="baz"     → key: "m_foo_bar_baz"
selector="foo"      topic="bar_baz" → key: "m_foo_bar_baz"

An attacker who can subscribe to the hub or publish updates with crafted topic names can exploit this to bypass authorization checks on private updates.

Patches

The vulnerability is fixed by replacing string-encoded cache keys with typed Go struct keys that are inherently collision-free:

type matchCacheKey struct {
    topicSelector string
    topic         string
}

The internal TopicSelectorStoreCache interface and sharded cache abstraction have also been removed in favor of a single typed otter cache.

Users should upgrade to version 0.22.0 or later.

Workarounds

Disable the topic selector cache by setting topic_selector_cache to -1 in the Caddyfile, or by passing a cache size of 0 when using the library directly. This eliminates the vulnerability at the cost of reduced performance.

Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/dunglas/mercure"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39972"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T19:53:20Z",
    "nvd_published_at": "2026-04-09T17:16:30Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nA cache key collision vulnerability in `TopicSelectorStore` allows an attacker to poison the match result cache, potentially causing private updates to be delivered to unauthorized subscribers or blocking delivery to authorized ones.\n\nThe cache key was constructed by concatenating the topic selector and topic with an underscore separator:\n\n```go\nk = \"m_\" + topicSelector + \"_\" + topic\n```\n\nBecause both topic selectors and topics can contain underscores, two distinct pairs can produce the same key:\n\n```\nselector=\"foo_bar\"  topic=\"baz\"     \u2192 key: \"m_foo_bar_baz\"\nselector=\"foo\"      topic=\"bar_baz\" \u2192 key: \"m_foo_bar_baz\"\n```\n\nAn attacker who can subscribe to the hub or publish updates with crafted topic names can exploit this to bypass authorization checks on private updates.\n\n### Patches\n\nThe vulnerability is fixed by replacing string-encoded cache keys with typed Go struct keys that are inherently collision-free:\n\n```go\ntype matchCacheKey struct {\n    topicSelector string\n    topic         string\n}\n```\n\nThe internal `TopicSelectorStoreCache` interface and sharded cache abstraction have also been removed in favor of a single typed otter cache.\n\nUsers should upgrade to version **0.22.0** or later.\n\n### Workarounds\n\nDisable the topic selector cache by setting `topic_selector_cache` to `-1` in the Caddyfile, or by passing a cache size of `0` when using the library directly. This eliminates the vulnerability at the cost of reduced performance.",
  "id": "GHSA-hwr4-mq23-wcv5",
  "modified": "2026-04-09T19:05:40Z",
  "published": "2026-04-08T19:53:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dunglas/mercure/security/advisories/GHSA-hwr4-mq23-wcv5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39972"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dunglas/mercure/commit/4964a69be904fd61e35b5f1e691271663b6fdd64"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dunglas/mercure"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dunglas/mercure/releases/tag/v0.22.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "mercure has Topic Selector Cache Key Collision"
}

GHSA-JHM7-29PJ-4XVF

Vulnerability from github – Published: 2026-04-16 21:09 – Updated: 2026-04-24 20:53
VLAI
Summary
@node-oauth/oauth2-server: PKCE code_verifier ABNF not enforced in token exchange allows brute-force redemption of intercepted authorization codes
Details

Summary

The token exchange path accepts RFC7636-invalid code_verifier values (including one-character strings) for S256 PKCE flows.
Because short/weak verifiers are accepted and failed verifier attempts do not consume the authorization code, an attacker who intercepts an authorization code can brute-force code_verifier guesses online until token issuance succeeds.

Root cause

  1. lib/pkce/pkce.js (getHashForCodeChallenge) only checks that verifier is a non-empty string before hashing for S256; it does not enforce RFC7636 ABNF (43..128 unreserved chars).
  2. lib/grant-types/authorization-code-grant-type.js compares hash(code_verifier) to stored codeChallenge without validating verifier format/length.
  3. In AuthorizationCodeGrantType.handle, authorization code revocation happens after verifier validation. Invalid guesses fail before revoke, so the same code can be retried repeatedly.

Steps to Reproduce

Setup

  • PKCE authorization code exists with:
  • codeChallengeMethod = "S256"
  • codeChallenge = BASE64URL(SHA256("z")) (verifier is one character, RFC-invalid)
  • Attacker has intercepted the authorization code value.

Reproduction

  1. Send repeated token requests with guessed code_verifier values:
POST /token HTTP/1.1
Host: oauth.example
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
client_id=client1&
client_secret=s3cret&
code=stolen-auth-code&
redirect_uri=https://client.example/callback&
code_verifier=<guess>
  1. Observe invalid guesses return invalid_grant.
  2. Continue guessing (a..z).
  3. When code_verifier=z, token issuance succeeds and returns bearer tokens.

Confirmed PoC output

BRUTE_FORCE_SUCCESS { tries: 26, guess: 'z', status: 200, tokenIssued: true }

Impact

An intercepted authorization code can be redeemed by brute-forcing low-entropy verifiers that the server should have rejected under RFC7636.
This weakens PKCE’s protection goal and allows token theft when clients generate short/predictable verifiers.

Recommended Fix

  1. Enforce pkce.codeChallengeMatchesABNF(request.body.code_verifier) in authorization code token exchange before hashing/comparison.
  2. Reject verifier values outside RFC7636 charset/length (43..128 unreserved).
  3. Invalidate authorization codes on failed verifier attempts (or add strict retry limits) to prevent online guessing.
Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.2.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@node-oauth/oauth2-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41213"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289",
      "CWE-307"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T21:09:50Z",
    "nvd_published_at": "2026-04-23T19:17:29Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe token exchange path accepts RFC7636-invalid `code_verifier` values (including one-character strings) for `S256` PKCE flows.  \nBecause short/weak verifiers are accepted and failed verifier attempts do not consume the authorization code, an attacker who intercepts an authorization code can brute-force `code_verifier` guesses online until token issuance succeeds.\n\n\n\n### Root cause\n\n1. `lib/pkce/pkce.js` (`getHashForCodeChallenge`) only checks that `verifier` is a non-empty string before hashing for `S256`; it does not enforce RFC7636 ABNF (`43..128` unreserved chars).\n2. `lib/grant-types/authorization-code-grant-type.js` compares `hash(code_verifier)` to stored `codeChallenge` without validating verifier format/length.\n3. In `AuthorizationCodeGrantType.handle`, authorization code revocation happens **after** verifier validation. Invalid guesses fail before revoke, so the same code can be retried repeatedly.\n\n## Steps to Reproduce\n\n### Setup\n\n- PKCE authorization code exists with:\n  - `codeChallengeMethod = \"S256\"`\n  - `codeChallenge = BASE64URL(SHA256(\"z\"))` (verifier is one character, RFC-invalid)\n- Attacker has intercepted the authorization code value.\n\n### Reproduction\n\n1. Send repeated token requests with guessed `code_verifier` values:\n\n```http\nPOST /token HTTP/1.1\nHost: oauth.example\nContent-Type: application/x-www-form-urlencoded\n\ngrant_type=authorization_code\u0026\nclient_id=client1\u0026\nclient_secret=s3cret\u0026\ncode=stolen-auth-code\u0026\nredirect_uri=https://client.example/callback\u0026\ncode_verifier=\u003cguess\u003e\n```\n\n2. Observe invalid guesses return `invalid_grant`.\n3. Continue guessing (`a`..`z`).\n4. When `code_verifier=z`, token issuance succeeds and returns bearer tokens.\n\n### Confirmed PoC output\n\n```text\nBRUTE_FORCE_SUCCESS { tries: 26, guess: \u0027z\u0027, status: 200, tokenIssued: true }\n```\n\n## Impact\n\nAn intercepted authorization code can be redeemed by brute-forcing low-entropy verifiers that the server should have rejected under RFC7636.  \nThis weakens PKCE\u2019s protection goal and allows token theft when clients generate short/predictable verifiers.\n\n## Recommended Fix\n\n1. Enforce `pkce.codeChallengeMatchesABNF(request.body.code_verifier)` in authorization code token exchange before hashing/comparison.\n2. Reject verifier values outside RFC7636 charset/length (`43..128` unreserved).\n3. Invalidate authorization codes on failed verifier attempts (or add strict retry limits) to prevent online guessing.",
  "id": "GHSA-jhm7-29pj-4xvf",
  "modified": "2026-04-24T20:53:49Z",
  "published": "2026-04-16T21:09:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/node-oauth/node-oauth2-server/security/advisories/GHSA-jhm7-29pj-4xvf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41213"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/node-oauth/node-oauth2-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@node-oauth/oauth2-server: PKCE code_verifier ABNF not enforced in token exchange allows brute-force redemption of intercepted authorization codes"
}

GHSA-JHP4-JVQ3-W5XR

Vulnerability from github – Published: 2026-02-25 19:00 – Updated: 2026-02-25 19:00
VLAI
Summary
Parse Dashboard Has a Cache Key Collision that Leaks Master Key to Read-Only Sessions
Details

Impact

The ConfigKeyCache uses the same cache key for both master key and read-only master key when resolving function-typed keys. Under specific timing conditions, a read-only user can receive the cached full master key, or a regular user can receive the cached read-only master key.

Patches

The fix uses distinct cache keys for master key and read-only master key.

Workarounds

Avoid using function-typed master keys, or remove the agent configuration block from your dashboard configuration.

Resources

  • GitHub advisory: https://github.com/parse-community/parse-dashboard/security/advisories/GHSA-jhp4-jvq3-w5xr
  • Fixed in: https://github.com/parse-community/parse-dashboard/releases/tag/9.0.0-alpha.8
Severity
7.0 (High)
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-dashboard"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.3.0-alpha.42"
            },
            {
              "fixed": "9.0.0-alpha.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27610"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-25T19:00:07Z",
    "nvd_published_at": "2026-02-25T03:16:05Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe `ConfigKeyCache` uses the same cache key for both master key and read-only master key when resolving function-typed keys. Under specific timing conditions, a read-only user can receive the cached full master key, or a regular user can receive the cached read-only master key.\n\n### Patches\n\nThe fix uses distinct cache keys for master key and read-only master key.\n\n### Workarounds\n\nAvoid using function-typed master keys, or remove the `agent` configuration block from your dashboard configuration.\n\n### Resources\n\n- GitHub advisory: https://github.com/parse-community/parse-dashboard/security/advisories/GHSA-jhp4-jvq3-w5xr\n- Fixed in: https://github.com/parse-community/parse-dashboard/releases/tag/9.0.0-alpha.8",
  "id": "GHSA-jhp4-jvq3-w5xr",
  "modified": "2026-02-25T19:00:07Z",
  "published": "2026-02-25T19:00:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-dashboard/security/advisories/GHSA-jhp4-jvq3-w5xr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27610"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-dashboard/commit/f92a9ef5246d57e51696bd881a15f3b133b2bb50"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-dashboard"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-dashboard/releases/tag/9.0.0-alpha.8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Parse Dashboard Has a Cache Key Collision that Leaks Master Key to Read-Only Sessions"
}

GHSA-M6C6-H9PC-2F7X

Vulnerability from github – Published: 2026-03-31 18:31 – Updated: 2026-03-31 18:31
VLAI
Details

An incorrect startup configuration of affected versions of Zscaler Client Connector on Windows may cause a limited amount of traffic from being inspected under rare circumstances.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-22569"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-31T16:16:28Z",
    "severity": "MODERATE"
  },
  "details": "An incorrect startup configuration of affected versions of Zscaler Client Connector on Windows may cause a limited amount of traffic from being inspected under rare circumstances.",
  "id": "GHSA-m6c6-h9pc-2f7x",
  "modified": "2026-03-31T18:31:31Z",
  "published": "2026-03-31T18:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22569"
    },
    {
      "type": "WEB",
      "url": "https://help.zscaler.com/zscaler-client-connector/client-connector-app-release-summary-2025"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M9GF-397R-HWPG

Vulnerability from github – Published: 2024-09-09 15:30 – Updated: 2025-11-03 22:48
VLAI
Summary
AngularJS allows attackers to bypass common image source restrictions
Details

Improper sanitization of the value of the [srcset] attribute in AngularJS allows attackers to bypass common image source restrictions, which can also lead to a form of Content Spoofing https://owasp.org/www-community/attacks/Content_Spoofing .

This issue affects AngularJS versions 1.3.0-rc.4 and greater.

Note: The AngularJS project is End-of-Life and will not receive any updates to address this issue. For more information see here https://docs.angularjs.org/misc/version-support-status .

Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L
2.9 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "angular"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0-rc.4"
            },
            {
              "last_affected": "1.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-8372"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-09T20:19:45Z",
    "nvd_published_at": "2024-09-09T15:15:12Z",
    "severity": "LOW"
  },
  "details": "Improper sanitization of the value of the `[srcset]` attribute in AngularJS allows attackers to bypass common image source restrictions, which can also lead to a form of  Content Spoofing https://owasp.org/www-community/attacks/Content_Spoofing .\n\nThis issue affects AngularJS versions 1.3.0-rc.4 and greater.\n\nNote:\nThe AngularJS project is End-of-Life and will not receive any updates to address this issue. For more information see  here https://docs.angularjs.org/misc/version-support-status .",
  "id": "GHSA-m9gf-397r-hwpg",
  "modified": "2025-11-03T22:48:13Z",
  "published": "2024-09-09T15:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8372"
    },
    {
      "type": "WEB",
      "url": "https://codepen.io/herodevs/full/xxoQRNL/0072e627abe03e9cda373bc75b4c1017"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/angular/angular.js"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/07/msg00005.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20241122-0002"
    },
    {
      "type": "WEB",
      "url": "https://www.herodevs.com/vulnerability-directory/cve-2024-8372"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AngularJS allows attackers to bypass common image source restrictions"
}

GHSA-Q3FP-VRQ4-532Q

Vulnerability from github – Published: 2024-08-06 21:30 – Updated: 2024-08-07 21:31
VLAI
Details

1Password 8 before 8.10.36 for macOS allows local attackers to exfiltrate vault items because XPC inter-process communication validation is insufficient.

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-42219"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-06T21:16:03Z",
    "severity": "HIGH"
  },
  "details": "1Password 8 before 8.10.36 for macOS allows local attackers to exfiltrate vault items because XPC inter-process communication validation is insufficient.",
  "id": "GHSA-q3fp-vrq4-532q",
  "modified": "2024-08-07T21:31:45Z",
  "published": "2024-08-06T21:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42219"
    },
    {
      "type": "WEB",
      "url": "https://app-updates.agilebits.com"
    },
    {
      "type": "WEB",
      "url": "https://support.1password.com/kb/202408a"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R6GG-58H5-PW3W

Vulnerability from github – Published: 2026-06-12 18:31 – Updated: 2026-06-12 18:31
VLAI
Details

The Aqara Cloud OAuth Authorization Endpoint (open-cn.aqara.com/oauth/authorize) is vulnerable to a redirect bypass due to lax controls on domain matching, which is an instance of "CWE-1289: Improper Validation of Unsafe Equivalence in Input" and has an estimated CVSS of CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N (9.3 Critical).

Severity
9.3 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-50090"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-12T16:16:32Z",
    "severity": "CRITICAL"
  },
  "details": "The Aqara Cloud OAuth Authorization Endpoint (open-cn.aqara.com/oauth/authorize) is vulnerable to a redirect bypass due to lax controls on domain matching, which is an instance of \"CWE-1289: Improper Validation of Unsafe Equivalence in Input\" and has an estimated CVSS of CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N (9.3 Critical).",
  "id": "GHSA-r6gg-58h5-pw3w",
  "modified": "2026-06-12T18:31:59Z",
  "published": "2026-06-12T18:31:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50090"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xn0tsa/theres-no-place-like-home"
    },
    {
      "type": "WEB",
      "url": "https://www.runzero.com/advisories/aqara-oauth-redirect-validation-bypass-cve-2026-50090"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RP9M-7R4C-75QG

Vulnerability from github – Published: 2026-04-03 04:07 – Updated: 2026-04-08 11:54
VLAI
Summary
fast-jwt: Cache Confusion via cacheKeyBuilder Collisions Can Return Claims From a Different Token (Identity/Authorization Mixup)
Details

NOTE: While the library exposes a mechanism which could introduce the vulnerability, this issue is created by developer-supplied code and not by the library itself. We will add a warning and some education for users around the possible issues however since the defaults work we will not be updating the library beyond that for this advisory.

Impact

Setting up a custom cacheKeyBuilder method which does not properly create unique keys for different tokens can lead to cache collisions. This could cause tokens to be mis-identified during the verification process leading to:

  • Valid tokens returning claims from different valid tokens
  • Users being mis-identified as other users based on the wrong token

This could result in: - User impersonation - UserB receives UserA's identity and permissions - Privilege escalation - Low-privilege users inherit admin-level access - Cross-tenant data access - Users gain access to other tenants' resources - Authorization bypass - Security decisions made on wrong user identity

Affected Configurations

This vulnerability ONLY affects applications that BOTH:

  1. Enable caching using the cache option
  2. Use custom cacheKeyBuilder functions that can produce collisions

VULNERABLE examples:

// Collision-prone: same audience = same cache key
cacheKeyBuilder: (token) => {
  const { aud } = parseToken(token)
  return `aud=${aud}`
}

// Collision-prone: grouping by user type
cacheKeyBuilder: (token) => {
  const { aud } = parseToken(token)
  return aud.includes('admin') ? 'admin-users' : 'regular-users'
}

// Collision-prone: tenant + service grouping
cacheKeyBuilder: (token) => {
  const { iss, aud } = parseToken(token)
  return `${iss}-${aud}`
}

SAFE examples:

// Default hash-based (recommended)
createVerifier({ cache: true })  // Uses secure default

// Include unique user identifier
cacheKeyBuilder: (token) => {
  const { sub, aud, iat } = parseToken(token)
  return `${sub}-${aud}-${iat}`
}

// No caching (always safe)
createVerifier({ cache: false })

Not Affected

  • Applications using default caching
  • Applications with caching disabled

Assessment Guide

To determine if you're affected:

  1. Check if caching is enabled: Look for cache: true or cache: in verifier configuration
  2. Check for custom cache key builders: Look for cacheKeyBuilder function in configuration
  3. Analyze collision potential: Review if your cacheKeyBuilder can produce identical keys for different users/tokens
  4. If no custom cacheKeyBuilder: You are NOT affected (default is safe)

Mitigations

Mitigations include:

  • Ensure uniqueness of keys produced in cacheKeyBuilder
  • Remove custom cacheKeyBuilder method
  • Disable caching

fast-jwt allows enabling a verification cache through the cache option. The cache key is derived from the token via cacheKeyBuilder.

When a custom cacheKeyBuilder produces collisions between different tokens, the verifier may return the cached payload of a previous token instead of validating and returning the payload of the current token.

This results in cross-token payload reuse and identity confusion.

Two distinct valid JWTs can be verified successfully but mapped to the same cached entry, causing the verifier to return claims belonging to a different token.

This affects authentication and authorization decisions when applications trust the returned payload.

Affected component

src/verifier.js

Relevant logic:

cache enabled via createCache

cache population via cacheSet

lookup based on cacheKeyBuilder(token)

cached payload returned without re-verification

Impact

Identity / authorization confusion via cache collision.

If two tokens generate the same cache key:

token A is verified → payload stored in cache

token B is verified → cache hit occurs

verifier returns payload from token A instead of B

Observed effect:

subject mismatch

claim mismatch

authorization decision performed on wrong identity

Potential real-world consequences:

user impersonation (logical)

privilege confusion

incorrect RBAC evaluation

gateway / middleware auth inconsistencies

This is especially dangerous when:

cache is enabled (recommended for performance)

custom cacheKeyBuilder is used

identity claims (sub / aud / iss) drive authorization

Root cause

The verifier assumes the cache key uniquely identifies the token and its claims.

However:

cacheKeyBuilder is user-controlled

collisions are not detected

cache entries store decoded payload

cached payload is returned without binding validation

This creates a trust boundary break between:

token → cache key → cached payload

Proof of concept

Environment:

fast-jwt: 6.1.0

Node.js: v24.13.1

PoC:

const { createSigner, createVerifier } = require('fast-jwt')

const sign = createSigner({ key: 'secret' })

// Two distinct tokens const t1 = sign({ sub: 'userA', aud: 'admin' }) const t2 = sign({ sub: 'userB', aud: 'admin' })

// Deliberately unsafe cache key builder (collision) const verify = createVerifier({ key: 'secret', cache: true, cacheKeyBuilder: () => 'static-key' })

console.log('verify t1') const p1 = verify(t1) console.log('t1 PASS sub=', p1.sub)

console.log('verify t2') const p2 = verify(t2) console.log('t2 PASS sub=', p2.sub)

console.log('verify t2 again') const p3 = verify(t2) console.log('t2-again PASS sub=', p3.sub)

console.log('verify t1 again') const p4 = verify(t1) console.log('t1-again PASS sub=', p4.sub)

Observed output:

verify t1 t1 PASS sub= userA

verify t2 t2 PASS sub= userA

verify t2 again t2-again PASS sub= userA

verify t1 again t1-again PASS sub= userA

The verifier returns payload from userA when verifying userB.

Expected behavior

Cache must not allow returning claims from a different token.

Verification must remain bound to the actual token being validated.

Even if cache collisions occur, the verifier should:

revalidate signature

re-decode payload

or invalidate cache entry

Why this is not “just misuse”

This is not merely a user mistake.

Reasons:

fast-jwt explicitly exposes cacheKeyBuilder as an extension point.

The documentation suggests performance tuning via custom key builders.

No safeguards exist against collisions.

No verification binding is performed between:

cached payload

original token

The verifier trusts cache output as authoritative identity.

This creates a security-sensitive invariant:

"cache key uniqueness"

which is neither enforced nor validated.

Security-critical libraries must assume extension hooks can be misused and implement defensive checks, especially when identity decisions are derived from cached values.

Security classification

logical authorization flaw

cache confusion vulnerability

identity boundary break

Closest CWE:

CWE-440 — Expected Behavior Violation

Suggested fix (minimal and safe)

Bind cache entries to token integrity.

Option A — safest:

Store token hash along with payload and verify match before returning cache.

Conceptual patch:

const tokenHash = hashToken(token)

cache.set(key, { tokenHash, payload })

...

const entry = cache.get(key)

if (entry && entry.tokenHash === hashToken(token)) { return entry.payload }

Option B — simpler:

Disable cache usage when custom cacheKeyBuilder is provided.

Option C — defensive:

Always re-validate signature when cache hit occurs.

Notes

Default cacheKeyBuilder is safe (hash-based).

Issue appears when custom builders are used — a documented and supported feature.

Impact increases in:

API gateways

auth middleware

RBAC layers relying on payload.sub / payload.aud

This vulnerability is independent from:

RegExp statefulness issue

ReDoS claim validation issue

It is a separate flaw in cache design and trust model.

PoC did on my computer: 'use strict'

const fs = require('node:fs') const path = require('node:path') const { createSigner, createVerifier } = require('./src')

function nowSec() { return Math.floor(Date.now() / 1000) }

const sign = createSigner({ key: 'secret' }) const t1 = sign({ sub: 'userA', aud: 'admin', iat: nowSec() }) const t2 = sign({ sub: 'userB', aud: 'admin', iat: nowSec() })

function badKeyBuilder() { return 'aud=admin' }

const verify = createVerifier({ key: 'secret', cache: true, cacheTTL: 60000, cacheKeyBuilder: badKeyBuilder })

function run(tok) { try { const out = verify(tok) return { ok: true, sub: out.sub, aud: out.aud } } catch (e) { return { ok: false, code: e.code || String(e), message: e.message } } }

const results = [] results.push({ step: 'verify(t1)', token: 't1', result: run(t1) }) results.push({ step: 'verify(t2)', token: 't2', result: run(t2) }) results.push({ step: 'verify(t2) again', token: 't2', result: run(t2) }) results.push({ step: 'verify(t1) again', token: 't1', result: run(t1) })

const evidence = { title: 'fast-jwt cache confusion when cacheKeyBuilder collisions occur', environment: { node: process.version, fastJwt: require('./package.json').version }, config: { cache: true, cacheTTL: 60000, cacheKeyBuilder: "returns constant key 'aud=admin' (realistic collision pattern)" }, tokens: { t1: { claims: { sub: 'userA', aud: 'admin' }, jwt: t1 }, t2: { claims: { sub: 'userB', aud: 'admin' }, jwt: t2 } }, observed: results }

const outPath = path.join(process.cwd(), 'evidence-cache-keybuilder-confusion.json') fs.writeFileSync(outPath, JSON.stringify(evidence, null, 2)) console.log('Wrote evidence to:', outPath)

for (const r of results) { console.log(r.step, '=>', r.result.ok ? PASS sub=${r.result.sub} : FAIL ${r.result.code}) }

Output: PS C:\Users\Franciny Rojas\Desktop\crypto-research\fast-jwt> node poc_cache_keybuilder_confusion_evidence.js Wrote evidence to: C:\Users\Franciny Rojas\Desktop\crypto-research\fast-jwt\evidence-cache-keybuilder-confusion.json verify(t1) => PASS sub=userA verify(t2) => PASS sub=userA verify(t2) again => PASS sub=userA verify(t1) again => PASS sub=userA PS C:\Users\Franciny Rojas\Desktop\crypto-research\fast-jwt>

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "fast-jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.1"
            },
            {
              "fixed": "6.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35039"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289",
      "CWE-345",
      "CWE-706"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T04:07:09Z",
    "nvd_published_at": "2026-04-06T17:17:13Z",
    "severity": "CRITICAL"
  },
  "details": "_NOTE_: While the library exposes a mechanism which could introduce the vulnerability, this issue is created by developer-supplied code and not by the library itself. We will add a warning and some education for users around the possible issues however since the defaults work we will not be updating the library beyond that for this advisory.\n\n## Impact\n\nSetting up a custom cacheKeyBuilder method which does not properly create unique keys for different tokens can lead to cache collisions. This could cause tokens to be mis-identified during the verification process leading to:\n\n- Valid tokens returning claims from different valid tokens\n- Users being mis-identified as other users based on the wrong token\n\nThis could result in:\n- User impersonation - UserB receives UserA\u0027s identity and permissions\n- Privilege escalation - Low-privilege users inherit admin-level access\n- Cross-tenant data access - Users gain access to other tenants\u0027 resources\n- Authorization bypass - Security decisions made on wrong user identity\n\n## Affected Configurations\n\nThis vulnerability ONLY affects applications that BOTH:\n\n1. Enable caching using the cache option\n2. Use custom cacheKeyBuilder functions that can produce collisions\n\nVULNERABLE examples:\n```\n// Collision-prone: same audience = same cache key\ncacheKeyBuilder: (token) =\u003e {\n  const { aud } = parseToken(token)\n  return `aud=${aud}`\n}\n\n// Collision-prone: grouping by user type\ncacheKeyBuilder: (token) =\u003e {\n  const { aud } = parseToken(token)\n  return aud.includes(\u0027admin\u0027) ? \u0027admin-users\u0027 : \u0027regular-users\u0027\n}\n\n// Collision-prone: tenant + service grouping\ncacheKeyBuilder: (token) =\u003e {\n  const { iss, aud } = parseToken(token)\n  return `${iss}-${aud}`\n}\n```\n\nSAFE examples:\n```\n// Default hash-based (recommended)\ncreateVerifier({ cache: true })  // Uses secure default\n\n// Include unique user identifier\ncacheKeyBuilder: (token) =\u003e {\n  const { sub, aud, iat } = parseToken(token)\n  return `${sub}-${aud}-${iat}`\n}\n\n// No caching (always safe)\ncreateVerifier({ cache: false })\n```\n### Not Affected\n\n- Applications using **default caching**\n- Applications with **caching disabled**\n \n## Assessment Guide\n\nTo determine if you\u0027re affected:\n\n1. Check if caching is enabled: Look for cache: true or cache: \u003cnumber\u003e in verifier configuration\n2. Check for custom cache key builders: Look for cacheKeyBuilder function in configuration\n3. Analyze collision potential: Review if your cacheKeyBuilder can produce identical keys for different users/tokens\n4. If no custom cacheKeyBuilder: You are NOT affected (default is safe)\n\n## Mitigations\n\nMitigations include:\n\n- Ensure uniqueness of keys produced in cacheKeyBuilder\n- Remove custom cacheKeyBuilder method\n- Disable caching\n\n---\n\nfast-jwt allows enabling a verification cache through the cache option.\nThe cache key is derived from the token via cacheKeyBuilder.\n\nWhen a custom cacheKeyBuilder produces collisions between different tokens, the verifier may return the cached payload of a previous token instead of validating and returning the payload of the current token.\n\nThis results in cross-token payload reuse and identity confusion.\n\nTwo distinct valid JWTs can be verified successfully but mapped to the same cached entry, causing the verifier to return claims belonging to a different token.\n\nThis affects authentication and authorization decisions when applications trust the returned payload.\n\nAffected component\n\nsrc/verifier.js\n\nRelevant logic:\n\ncache enabled via createCache\n\ncache population via cacheSet\n\nlookup based on cacheKeyBuilder(token)\n\ncached payload returned without re-verification\n\nImpact\n\nIdentity / authorization confusion via cache collision.\n\nIf two tokens generate the same cache key:\n\ntoken A is verified \u2192 payload stored in cache\n\ntoken B is verified \u2192 cache hit occurs\n\nverifier returns payload from token A instead of B\n\nObserved effect:\n\nsubject mismatch\n\nclaim mismatch\n\nauthorization decision performed on wrong identity\n\nPotential real-world consequences:\n\nuser impersonation (logical)\n\nprivilege confusion\n\nincorrect RBAC evaluation\n\ngateway / middleware auth inconsistencies\n\nThis is especially dangerous when:\n\ncache is enabled (recommended for performance)\n\ncustom cacheKeyBuilder is used\n\nidentity claims (sub / aud / iss) drive authorization\n\nRoot cause\n\nThe verifier assumes the cache key uniquely identifies the token and its claims.\n\nHowever:\n\ncacheKeyBuilder is user-controlled\n\ncollisions are not detected\n\ncache entries store decoded payload\n\ncached payload is returned without binding validation\n\nThis creates a trust boundary break between:\n\ntoken \u2192 cache key \u2192 cached payload\n\nProof of concept\n\nEnvironment:\n\nfast-jwt: 6.1.0\n\nNode.js: v24.13.1\n\nPoC:\n\nconst { createSigner, createVerifier } = require(\u0027fast-jwt\u0027)\n\nconst sign = createSigner({ key: \u0027secret\u0027 })\n\n// Two distinct tokens\nconst t1 = sign({ sub: \u0027userA\u0027, aud: \u0027admin\u0027 })\nconst t2 = sign({ sub: \u0027userB\u0027, aud: \u0027admin\u0027 })\n\n// Deliberately unsafe cache key builder (collision)\nconst verify = createVerifier({\n  key: \u0027secret\u0027,\n  cache: true,\n  cacheKeyBuilder: () =\u003e \u0027static-key\u0027\n})\n\nconsole.log(\u0027verify t1\u0027)\nconst p1 = verify(t1)\nconsole.log(\u0027t1 PASS sub=\u0027, p1.sub)\n\nconsole.log(\u0027verify t2\u0027)\nconst p2 = verify(t2)\nconsole.log(\u0027t2 PASS sub=\u0027, p2.sub)\n\nconsole.log(\u0027verify t2 again\u0027)\nconst p3 = verify(t2)\nconsole.log(\u0027t2-again PASS sub=\u0027, p3.sub)\n\nconsole.log(\u0027verify t1 again\u0027)\nconst p4 = verify(t1)\nconsole.log(\u0027t1-again PASS sub=\u0027, p4.sub)\n\nObserved output:\n\nverify t1\nt1 PASS sub= userA\n\nverify t2\nt2 PASS sub= userA\n\nverify t2 again\nt2-again PASS sub= userA\n\nverify t1 again\nt1-again PASS sub= userA\n\nThe verifier returns payload from userA when verifying userB.\n\nExpected behavior\n\nCache must not allow returning claims from a different token.\n\nVerification must remain bound to the actual token being validated.\n\nEven if cache collisions occur, the verifier should:\n\nrevalidate signature\n\nre-decode payload\n\nor invalidate cache entry\n\nWhy this is not \u201cjust misuse\u201d\n\nThis is not merely a user mistake.\n\nReasons:\n\nfast-jwt explicitly exposes cacheKeyBuilder as an extension point.\n\nThe documentation suggests performance tuning via custom key builders.\n\nNo safeguards exist against collisions.\n\nNo verification binding is performed between:\n\ncached payload\n\noriginal token\n\nThe verifier trusts cache output as authoritative identity.\n\nThis creates a security-sensitive invariant:\n\n\"cache key uniqueness\"\n\nwhich is neither enforced nor validated.\n\nSecurity-critical libraries must assume extension hooks can be misused and implement defensive checks, especially when identity decisions are derived from cached values.\n\nSecurity classification\n\nlogical authorization flaw\n\ncache confusion vulnerability\n\nidentity boundary break\n\nClosest CWE:\n\nCWE-440 \u2014 Expected Behavior Violation\n\nSuggested fix (minimal and safe)\n\nBind cache entries to token integrity.\n\nOption A \u2014 safest:\n\nStore token hash along with payload and verify match before returning cache.\n\nConceptual patch:\n\nconst tokenHash = hashToken(token)\n\ncache.set(key, { tokenHash, payload })\n\n...\n\nconst entry = cache.get(key)\n\nif (entry \u0026\u0026 entry.tokenHash === hashToken(token)) {\n  return entry.payload\n}\n\nOption B \u2014 simpler:\n\nDisable cache usage when custom cacheKeyBuilder is provided.\n\nOption C \u2014 defensive:\n\nAlways re-validate signature when cache hit occurs.\n\nNotes\n\nDefault cacheKeyBuilder is safe (hash-based).\n\nIssue appears when custom builders are used \u2014 a documented and supported feature.\n\nImpact increases in:\n\nAPI gateways\n\nauth middleware\n\nRBAC layers relying on payload.sub / payload.aud\n\nThis vulnerability is independent from:\n\nRegExp statefulness issue\n\nReDoS claim validation issue\n\nIt is a separate flaw in cache design and trust model.\n\nPoC did on my computer:\n\u0027use strict\u0027\n\nconst fs = require(\u0027node:fs\u0027)\nconst path = require(\u0027node:path\u0027)\nconst { createSigner, createVerifier } = require(\u0027./src\u0027)\n\nfunction nowSec() {\n  return Math.floor(Date.now() / 1000)\n}\n\nconst sign = createSigner({ key: \u0027secret\u0027 })\nconst t1 = sign({ sub: \u0027userA\u0027, aud: \u0027admin\u0027, iat: nowSec() })\nconst t2 = sign({ sub: \u0027userB\u0027, aud: \u0027admin\u0027, iat: nowSec() })\n\nfunction badKeyBuilder() {\n  return \u0027aud=admin\u0027\n}\n\nconst verify = createVerifier({\n  key: \u0027secret\u0027,\n  cache: true,\n  cacheTTL: 60000,\n  cacheKeyBuilder: badKeyBuilder\n})\n\nfunction run(tok) {\n  try {\n    const out = verify(tok)\n    return { ok: true, sub: out.sub, aud: out.aud }\n  } catch (e) {\n    return { ok: false, code: e.code || String(e), message: e.message }\n  }\n}\n\nconst results = []\nresults.push({ step: \u0027verify(t1)\u0027, token: \u0027t1\u0027, result: run(t1) })\nresults.push({ step: \u0027verify(t2)\u0027, token: \u0027t2\u0027, result: run(t2) })\nresults.push({ step: \u0027verify(t2) again\u0027, token: \u0027t2\u0027, result: run(t2) })\nresults.push({ step: \u0027verify(t1) again\u0027, token: \u0027t1\u0027, result: run(t1) })\n\nconst evidence = {\n  title: \u0027fast-jwt cache confusion when cacheKeyBuilder collisions occur\u0027,\n  environment: {\n    node: process.version,\n    fastJwt: require(\u0027./package.json\u0027).version\n  },\n  config: {\n    cache: true,\n    cacheTTL: 60000,\n    cacheKeyBuilder: \"returns constant key \u0027aud=admin\u0027 (realistic collision pattern)\"\n  },\n  tokens: {\n    t1: { claims: { sub: \u0027userA\u0027, aud: \u0027admin\u0027 }, jwt: t1 },\n    t2: { claims: { sub: \u0027userB\u0027, aud: \u0027admin\u0027 }, jwt: t2 }\n  },\n  observed: results\n}\n\nconst outPath = path.join(process.cwd(), \u0027evidence-cache-keybuilder-confusion.json\u0027)\nfs.writeFileSync(outPath, JSON.stringify(evidence, null, 2))\nconsole.log(\u0027Wrote evidence to:\u0027, outPath)\n\nfor (const r of results) {\n  console.log(r.step, \u0027=\u003e\u0027, r.result.ok ? `PASS sub=${r.result.sub}` : `FAIL ${r.result.code}`)\n}\n\nOutput:\nPS C:\\Users\\Franciny Rojas\\Desktop\\crypto-research\\fast-jwt\u003e node poc_cache_keybuilder_confusion_evidence.js\nWrote evidence to: C:\\Users\\Franciny Rojas\\Desktop\\crypto-research\\fast-jwt\\evidence-cache-keybuilder-confusion.json\nverify(t1) =\u003e PASS sub=userA\nverify(t2) =\u003e PASS sub=userA\nverify(t2) again =\u003e PASS sub=userA\nverify(t1) again =\u003e PASS sub=userA\nPS C:\\Users\\Franciny Rojas\\Desktop\\crypto-research\\fast-jwt\u003e",
  "id": "GHSA-rp9m-7r4c-75qg",
  "modified": "2026-04-08T11:54:56Z",
  "published": "2026-04-03T04:07:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-rp9m-7r4c-75qg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35039"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/commit/de121056c6415b58770c60640881eaec67ac4ceb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nearform/fast-jwt"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "fast-jwt: Cache Confusion via cacheKeyBuilder Collisions Can Return Claims From a Different Token (Identity/Authorization Mixup)"
}
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list