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.

55 vulnerabilities reference this CWE, most recent first.

GHSA-GX25-V2F3-PPXQ

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

Improper input validation in the apps and endpoints configuration in PowerShell Universal before 2026.1.4 allows an authenticated user with permissions to create or modify Apps or Endpoints to override existing application or system routes, resulting in unintended request routing and denial of service via a conflicting URL path.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-3563"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-17T20:16:14Z",
    "severity": "MODERATE"
  },
  "details": "Improper input validation in the apps and endpoints configuration in PowerShell Universal before 2026.1.4 allows an authenticated user with permissions to create or modify Apps or Endpoints to override existing application or system routes, resulting in unintended request routing and denial of service via a conflicting URL path.",
  "id": "GHSA-gx25-v2f3-ppxq",
  "modified": "2026-03-17T21:31:45Z",
  "published": "2026-03-17T21:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3563"
    },
    {
      "type": "WEB",
      "url": "https://devolutions.net/security/advisories/DEVO-2026-0008"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H6C8-CWW8-35HF

Vulnerability from github – Published: 2026-03-26 17:21 – Updated: 2026-03-27 21:30
VLAI
Summary
OpenFGA has an Authorization Bypass through cached keys
Details

Description

In OpenFGA, under specific conditions, models using conditions with caching enabled can result in two different check requests producing the same cache key. This can result in OpenFGA reusing an earlier cached result for a different request.

Am I Affected?

Users are affected if the following preconditions are met: 1. The model has relations which rely on condition evaluation. 1. Caching is enabled.

Fix

Upgrade to OpenFGA v1.13.1.

Acknowledgement

OpenFGA would like to thank @Amemoyoi for the discovery and responsible disclosure.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openfga/openfga"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33729"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289",
      "CWE-20",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T17:21:50Z",
    "nvd_published_at": "2026-03-27T01:16:20Z",
    "severity": "MODERATE"
  },
  "details": "### Description\nIn OpenFGA, under specific conditions, models using conditions with caching enabled can result in two different check requests producing the same cache key. This can result in OpenFGA reusing an earlier cached result for a different request.\n\n### Am I Affected?\nUsers are affected if the following preconditions are met:\n1. The model has relations which rely on condition evaluation.\n1. Caching is enabled.\n\n### Fix\nUpgrade to OpenFGA v1.13.1.\n\n### Acknowledgement\nOpenFGA would like to thank @Amemoyoi for the discovery and responsible disclosure.",
  "id": "GHSA-h6c8-cww8-35hf",
  "modified": "2026-03-27T21:30:41Z",
  "published": "2026-03-26T17:21:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/security/advisories/GHSA-h6c8-cww8-35hf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33729"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/commit/049b50ccd2cc7e163bd897f3d17a7b859ad146f8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openfga/openfga"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openfga/openfga/releases/tag/v1.13.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenFGA has an Authorization Bypass through cached keys"
}

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-HFQP-M279-7MJ7

Vulnerability from github – Published: 2026-07-30 15:31 – Updated: 2026-08-21 09:32
VLAI
Details

Date::Manip versions through 6.99 for Perl return corrupted dates via non-ASCII decimal digits that pass the numeric range tests in check.

The parse regexes capture year, month and day with the \d shorthand, which on a character string matches the whole Unicode decimal digit property \p{Nd} and not just [0-9]. Date::Manip::Base::check then validates the captured fields with numeric comparisons alone ($y<1 || $y>9999, $m<1 || $m>12, $d<1 || $d>$days), and _parse_check stores the numified fields ($y+0). Perl truncates a string at the first character that is not an ASCII digit, so a field whose leading characters are ASCII digits numifies to an in-range prefix and satisfies every test: a year field of three ASCII digits followed by U+0664 ARABIC-INDIC DIGIT FOUR numifies to 202, giving the year 0202, and one non-ASCII digit in the month or day field shifts those fields the same way. The hour, minute and second fields match explicit ASCII character classes (0?[0-9], [0-5][0-9]) and do not shift, though a non-ASCII digit in a fractional hour or minute field truncates the fraction.

Any caller that passes an untrusted character string to ParseDate() or Date::Manip::Date->parse() can get back a date that differs from the string it parsed, with no parse error. Where the parsed date gates logic such as an expiry check or a retention window, the shift goes unnoticed.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-60074"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T14:17:02Z",
    "severity": "HIGH"
  },
  "details": "Date::Manip versions through 6.99 for Perl return corrupted dates via non-ASCII decimal digits that pass the numeric range tests in check.\n\nThe parse regexes capture year, month and day with the `\\d` shorthand, which on a character string matches the whole Unicode decimal digit property `\\p{Nd}` and not just `[0-9]`. Date::Manip::Base::check then validates the captured fields with numeric comparisons alone (`$y\u003c1 || $y\u003e9999`, `$m\u003c1 || $m\u003e12`, `$d\u003c1 || $d\u003e$days`), and _parse_check stores the numified fields (`$y+0`). Perl truncates a string at the first character that is not an ASCII digit, so a field whose leading characters are ASCII digits numifies to an in-range prefix and satisfies every test: a year field of three ASCII digits followed by U+0664 ARABIC-INDIC DIGIT FOUR numifies to 202, giving the year 0202, and one non-ASCII digit in the month or day field shifts those fields the same way. The hour, minute and second fields match explicit ASCII character classes (`0?[0-9]`, `[0-5][0-9]`) and do not shift, though a non-ASCII digit in a fractional hour or minute field truncates the fraction.\n\nAny caller that passes an untrusted character string to ParseDate() or Date::Manip::Date-\u003eparse() can get back a date that differs from the string it parsed, with no parse error. Where the parsed date gates logic such as an expiry check or a retention window, the shift goes unnoticed.",
  "id": "GHSA-hfqp-m279-7mj7",
  "modified": "2026-08-21T09:32:02Z",
  "published": "2026-07-30T15:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60074"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SBECK-github/Date-Manip/pull/54"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/SBECK/Date-Manip-6.99/source/lib/Date/Manip/Base.pm#L602-614"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/SBECK/Date-Manip-6.99/source/lib/Date/Manip/Date.pm#L1536-1539"
    },
    {
      "type": "WEB",
      "url": "https://security.metacpan.org/patches/D/Date-Manip/6.99/CVE-2026-60074-r1.patch"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/07/30/19"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

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"
}
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