Common Weakness Enumeration

CWE-1289

Allowed

Improper Validation of Unsafe Equivalence in Input

Abstraction: Base · Status: Incomplete

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.

75 vulnerabilities reference this CWE, most recent first.

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.

Show details on source website

{
  "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.

Show details on source website

{
  "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.
Show details on source website

{
  "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
Show details on source website

{
  "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.

Show details on source website

{
  "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 .

Show details on source website

{
  "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-P7V4-JPP9-2M3Q

Vulnerability from github – Published: 2026-09-16 09:30 – Updated: 2026-09-16 09:30
VLAI
Details

Improper Validation of Unsafe Equivalence in Input in ZenHive mpp allows an unauthenticated remote client to pass the Tempo duplicate-submission gate twice with one signed transaction.

MPP.Methods.Tempo reserves the pre-broadcast dedup slot on the caller-supplied hex in reserve_hash_atomic/2, keyed through store_key/1 on tx.raw rather than on a canonical form of the transaction. The deserializer stores the caller's hex verbatim and accepts both recovery-id encodings, so one signed transaction submitted once with v=27 and once with v=0 yields two distinct reserve keys, and both pass the reserve and reach the broadcast path. The plug-level credential replay store is deliberately carved out for tempo in lib/mpp/replay.ex, leaving this reserve as the only gate, and the post-broadcast mark writes the canonical hash key that the raw-keyed reserve never reads.

What the duplicate submission yields depends on the node: a nonce-reuse rejection fails closed, while a node that answers with the canonical hash for an already-known transaction returns a second valid Payment-Receipt for a single on-chain payment.

This issue affects mpp: from 0.2.0 before 0.16.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-88255"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-16T09:17:07Z",
    "severity": "MODERATE"
  },
  "details": "Improper Validation of Unsafe Equivalence in Input in ZenHive mpp allows an unauthenticated remote client to pass the Tempo duplicate-submission gate twice with one signed transaction.\n\nMPP.Methods.Tempo reserves the pre-broadcast dedup slot on the caller-supplied hex in reserve_hash_atomic/2, keyed through store_key/1 on tx.raw rather than on a canonical form of the transaction. The deserializer stores the caller\u0027s hex verbatim and accepts both recovery-id encodings, so one signed transaction submitted once with v=27 and once with v=0 yields two distinct reserve keys, and both pass the reserve and reach the broadcast path. The plug-level credential replay store is deliberately carved out for tempo in lib/mpp/replay.ex, leaving this reserve as the only gate, and the post-broadcast mark writes the canonical hash key that the raw-keyed reserve never reads.\n\nWhat the duplicate submission yields depends on the node: a nonce-reuse rejection fails closed, while a node that answers with the canonical hash for an already-known transaction returns a second valid Payment-Receipt for a single on-chain payment.\n\nThis issue affects mpp: from 0.2.0 before 0.16.2.",
  "id": "GHSA-p7v4-jpp9-2m3q",
  "modified": "2026-09-16T09:30:29Z",
  "published": "2026-09-16T09:30:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZenHive/mpp/security/advisories/GHSA-8x7x-5j8g-8hcx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88255"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZenHive/mpp/commit/e12bd4a1cea2e97c2a01fc059c48e5594a7b4a43"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZenHive/mpp/commit/f8904666061fbab695874856d8fcd02c471dfe1b"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-88255.html"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-88255"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

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.

Show details on source website

{
  "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).

Show details on source website

{
  "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-R946-P43H-MW8H

Vulnerability from github – Published: 2026-10-07 03:30 – Updated: 2026-10-07 03:30
VLAI
Details

In affected versions of Octopus Server, an authenticated user with permission to modify roles could bypass the protections preventing access abuse resulting in privilege escalation. It was possible for the built-in role to be weakened and the attacker's account added to a privileged team. This was achievable due to improper validation of unsafe equivalence in inputs.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-102478"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-07T02:16:56Z",
    "severity": "HIGH"
  },
  "details": "In affected versions of Octopus Server, an authenticated user with permission to modify roles could bypass the protections preventing access abuse resulting in privilege escalation. It was possible for the built-in role to be weakened and the attacker\u0027s account added to a privileged team. This was achievable due to improper validation of unsafe equivalence in inputs.",
  "id": "GHSA-r946-p43h-mw8h",
  "modified": "2026-10-07T03:30:23Z",
  "published": "2026-10-07T03:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102478"
    },
    {
      "type": "WEB",
      "url": "https://advisories.octopus.com/post/2026/sa2026-11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

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.