Common Weakness Enumeration

CWE-345

Discouraged

Insufficient Verification of Data Authenticity

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.

939 vulnerabilities reference this CWE, most recent first.

GHSA-98GC-8MJ5-CC3R

Vulnerability from github – Published: 2023-09-05 03:30 – Updated: 2024-04-04 07:26
VLAI
Details

IBM Aspera Faspex 5.0.5 could allow a remote attacked to bypass IP restrictions due to improper access controls. IBM X-Force ID: 259649.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-35906"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-291",
      "CWE-345",
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-05T01:15:07Z",
    "severity": "HIGH"
  },
  "details": "IBM Aspera Faspex 5.0.5 could allow a remote attacked to bypass IP restrictions due to improper access controls.  IBM X-Force ID:  259649.",
  "id": "GHSA-98gc-8mj5-cc3r",
  "modified": "2024-04-04T07:26:29Z",
  "published": "2023-09-05T03:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35906"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/259649"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7029681"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-98W5-WQP9-W466

Vulnerability from github – Published: 2022-05-17 03:38 – Updated: 2024-04-23 17:21
VLAI
Summary
Drupal Incorrect cache context on password reset page
Details

The user password reset form in Drupal 8.x before 8.2.3 allows remote attackers to conduct cache poisoning attacks by leveraging failure to specify a correct cache context.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0"
            },
            {
              "fixed": "8.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "drupal/drupal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0"
            },
            {
              "fixed": "8.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-9450"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-23T17:21:07Z",
    "nvd_published_at": "2016-11-25T18:59:00Z",
    "severity": "HIGH"
  },
  "details": "The user password reset form in Drupal 8.x before 8.2.3 allows remote attackers to conduct cache poisoning attacks by leveraging failure to specify a correct cache context.",
  "id": "GHSA-98w5-wqp9-w466",
  "modified": "2024-04-23T17:21:07Z",
  "published": "2022-05-17T03:38:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9450"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/drupal/core/CVE-2016-9450.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/drupal/drupal/CVE-2016-9450.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/drupal/core"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/SA-CORE-2016-005"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/94367"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Drupal Incorrect cache context on password reset page"
}

GHSA-9G98-5MJ6-F9MV

Vulnerability from github – Published: 2023-03-02 23:25 – Updated: 2023-03-02 23:25
VLAI
Summary
Keycloak vulnerable to user impersonation via stolen UUID code
Details

Keycloak's OpenID Connect user authentication was found to incorrectly authenticate requests. An authenticated attacker who could also obtain a certain piece of info from a user request, from a victim within the same realm, could use that data to impersonate the victim and generate new session tokens.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-services"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "21.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-0264"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-02T23:25:43Z",
    "nvd_published_at": "2023-08-04T18:15:11Z",
    "severity": "HIGH"
  },
  "details": "Keycloak\u0027s OpenID Connect user authentication was found to incorrectly authenticate requests. An authenticated attacker who could also obtain a certain piece of info from a user request, from a victim within the same realm, could use that data to impersonate the victim and generate new session tokens.",
  "id": "GHSA-9g98-5mj6-f9mv",
  "modified": "2023-03-02T23:25:43Z",
  "published": "2023-03-02T23:25:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-9g98-5mj6-f9mv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0264"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/commit/ec8109112e67208c13e13f6d1f8706a5a3ba8d4c"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-0264"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Keycloak vulnerable to user impersonation via stolen UUID code"
}

GHSA-9GGR-2464-2J32

Vulnerability from github – Published: 2025-09-22 14:42 – Updated: 2025-11-03 18:31
VLAI
Summary
Authlib: JWS/JWT accepts unknown crit headers (RFC violation → possible authz bypass)
Details

Summary

Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (crit), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, bork or cnf) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation.

Affected Component and Versions

  • Library: Authlib (JWS verification)
  • API: authlib.jose.JsonWebSignature.deserialize_compact(...)
  • Version tested: 1.6.3
  • Configuration: Default; no allowlist or special handling for crit

Details

RFC 7515 (JWS) §4.1.11 defines crit as a “must‑understand” list: recipients MUST understand and enforce every header parameter listed in crit, otherwise they MUST reject the token. Security‑sensitive semantics such as token binding (e.g., cnf from RFC 7800) are often conveyed via crit.

Observed behavior with Authlib 1.6.3: - When a compact JWS contains a protected header with crit: ["cnf"] and a cnf object, or crit: ["bork"] with an unknown parameter, Authlib verifies the signature and returns the payload without rejecting the token or enforcing semantics of the critical parameter. - By contrast, Java Nimbus JOSE+JWT (9.37.x) and Node jose v5 both reject such tokens by default when crit lists unknown names.

Impact in heterogeneous fleets: - A strict ingress/gateway (Nimbus/Node) rejects a token, but a lenient Python microservice (Authlib) accepts the same token. This split‑brain acceptance bypasses intended security policies and can enable replay or privilege escalation if crit carries binding or policy information.

Proof of Concept (PoC)

This repository provides a multi‑runtime PoC demonstrating the issue across Python (Authlib), Node (jose v5), and Java (Nimbus).

Prerequisites

  • Python 3.8+
  • Node.js 18+
  • Java 11+ with Maven

Setup

Enter the directory authlib-crit-bypass-poc & run following commands.

make setup
make tokens

Tokens minted

  • tokens/unknown_crit.jwt with protected header: { "alg": "HS256", "crit": ["bork"], "bork": "x" }
  • tokens/cnf_header.jwt with protected header: { "alg": "HS256", "crit": ["cnf"], "cnf": {"jkt": "thumb-42"} }

Reproduction

Run the cross‑runtime demo:

make  demo

Expected output for each token (strict verifiers reject; Authlib accepts):

For tokens/unknown_crit.jwt:

Strict(Nimbus): REJECTED (unknown critical header: bork)
Strict(Node jose): REJECTED (unrecognized crit)
Lenient(Authlib): ACCEPTED -> payload={'sub': '123', 'role': 'user'}

For tokens/cnf_header.jwt:

Strict(Nimbus): REJECTED (unknown critical header: cnf)
Strict(Node jose): REJECTED (unrecognized crit)
Lenient(Authlib): ACCEPTED -> payload={'sub': '123', 'role': 'user'}

Environment notes: - Authlib version used: 1.6.3 (from PyPI) - Node jose version: ^5 - Nimbus JOSE+JWT version: 9.37.x - HS256 secret is 32 bytes to satisfy strict verifiers: 0123456789abcdef0123456789abcdef

Impact

  • Class: Violation of JWS crit “must‑understand” semantics; specification non‑compliance leading to authentication/authorization policy bypass.
  • Who is impacted: Any service that relies on crit to carry mandatory security semantics (e.g., token binding via cnf) or operates in a heterogeneous fleet with strict verifiers elsewhere.
  • Consequences: Split‑brain acceptance (gateway rejects while a backend accepts), replay, or privilege escalation if critical semantics are ignored.

References

  • RFC 7515: JSON Web Signature (JWS), §4.1.11 crit
  • RFC 7800: Proof‑of‑Possession Key Semantics for JWTs (cnf)
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59420"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-22T14:42:12Z",
    "nvd_published_at": "2025-09-22T18:15:46Z",
    "severity": "HIGH"
  },
  "details": "## Summary\nAuthlib\u2019s JWS verification accepts tokens that declare unknown critical header parameters (`crit`), violating RFC 7515 \u201cmust\u2011understand\u201d semantics. An attacker can craft a signed token with a critical header (for example, `bork` or `cnf`) that strict verifiers reject but Authlib accepts. In mixed\u2011language fleets, this enables split\u2011brain verification and can lead to policy bypass, replay, or privilege escalation.\n\n## Affected Component and Versions\n- Library: Authlib (JWS verification)\n- API: `authlib.jose.JsonWebSignature.deserialize_compact(...)`\n- Version tested: 1.6.3\n- Configuration: Default; no allowlist or special handling for `crit`\n\n## Details\nRFC 7515 (JWS) \u00a74.1.11 defines `crit` as a \u201cmust\u2011understand\u201d list: recipients MUST understand and enforce every header parameter listed in `crit`, otherwise they MUST reject the token. Security\u2011sensitive semantics such as token binding (e.g., `cnf` from RFC 7800) are often conveyed via `crit`.\n\nObserved behavior with Authlib 1.6.3:\n- When a compact JWS contains a protected header with `crit: [\"cnf\"]` and a `cnf` object, or `crit: [\"bork\"]` with an unknown parameter, Authlib verifies the signature and returns the payload without rejecting the token or enforcing semantics of the critical parameter.\n- By contrast, Java Nimbus JOSE+JWT (9.37.x) and Node `jose` v5 both reject such tokens by default when `crit` lists unknown names.\n\nImpact in heterogeneous fleets:\n- A strict ingress/gateway (Nimbus/Node) rejects a token, but a lenient Python microservice (Authlib) accepts the same token. This split\u2011brain acceptance bypasses intended security policies and can enable replay or privilege escalation if `crit` carries binding or policy information.\n\n## Proof of Concept (PoC)\nThis repository provides a multi\u2011runtime PoC demonstrating the issue across Python (Authlib), Node (`jose` v5), and Java (Nimbus).\n\n### Prerequisites\n- Python 3.8+\n- Node.js 18+\n- Java 11+ with Maven\n\n### Setup\n\nEnter the directory **authlib-crit-bypass-poc** \u0026 run following commands.\n```bash\nmake setup\nmake tokens\n```\n\n### Tokens minted\n- `tokens/unknown_crit.jwt` with protected header:\n  `{ \"alg\": \"HS256\", \"crit\": [\"bork\"], \"bork\": \"x\" }`\n- `tokens/cnf_header.jwt` with protected header:\n  `{ \"alg\": \"HS256\", \"crit\": [\"cnf\"], \"cnf\": {\"jkt\": \"thumb-42\"} }`\n\n### Reproduction\nRun the cross\u2011runtime demo:\n```bash\nmake  demo\n```\n\nExpected output for each token (strict verifiers reject; Authlib accepts):\n\nFor `tokens/unknown_crit.jwt`:\n```\nStrict(Nimbus): REJECTED (unknown critical header: bork)\nStrict(Node jose): REJECTED (unrecognized crit)\nLenient(Authlib): ACCEPTED -\u003e payload={\u0027sub\u0027: \u0027123\u0027, \u0027role\u0027: \u0027user\u0027}\n```\n\nFor `tokens/cnf_header.jwt`:\n```\nStrict(Nimbus): REJECTED (unknown critical header: cnf)\nStrict(Node jose): REJECTED (unrecognized crit)\nLenient(Authlib): ACCEPTED -\u003e payload={\u0027sub\u0027: \u0027123\u0027, \u0027role\u0027: \u0027user\u0027}\n```\n\nEnvironment notes:\n- Authlib version used: `1.6.3` (from PyPI)\n- Node `jose` version: `^5`\n- Nimbus JOSE+JWT version: `9.37.x`\n- HS256 secret is 32 bytes to satisfy strict verifiers: `0123456789abcdef0123456789abcdef`\n\n## Impact\n- Class: Violation of JWS `crit` \u201cmust\u2011understand\u201d semantics; specification non\u2011compliance leading to authentication/authorization policy bypass.\n- Who is impacted: Any service that relies on `crit` to carry mandatory security semantics (e.g., token binding via `cnf`) or operates in a heterogeneous fleet with strict verifiers elsewhere.\n- Consequences: Split\u2011brain acceptance (gateway rejects while a backend accepts), replay, or privilege escalation if critical semantics are ignored.\n\n## References\n- RFC 7515: JSON Web Signature (JWS), \u00a74.1.11 `crit`\n- RFC 7800: Proof\u2011of\u2011Possession Key Semantics for JWTs (`cnf`)",
  "id": "GHSA-9ggr-2464-2j32",
  "modified": "2025-11-03T18:31:42Z",
  "published": "2025-09-22T14:42:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-9ggr-2464-2j32"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59420"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/6b1813e4392eb7c168c276099ff7783b176479df"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00032.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authlib: JWS/JWT accepts unknown crit headers (RFC violation \u2192 possible authz bypass)"
}

GHSA-9H64-69XJ-VX28

Vulnerability from github – Published: 2025-02-04 15:31 – Updated: 2025-02-06 21:32
VLAI
Details

Thunderbird displayed an incorrect sender address if the From field of an email used the invalid group name syntax that is described in CVE-2024-49040. This vulnerability affects Thunderbird < 128.7 and Thunderbird < 135.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-0510"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-04T14:15:31Z",
    "severity": "MODERATE"
  },
  "details": "Thunderbird displayed an incorrect sender address if the From field of an email used the invalid group name syntax that is described in CVE-2024-49040. This vulnerability affects Thunderbird \u003c 128.7 and Thunderbird \u003c 135.",
  "id": "GHSA-9h64-69xj-vx28",
  "modified": "2025-02-06T21:32:09Z",
  "published": "2025-02-04T15:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0510"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1940570"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2025-10"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2025-11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9H8M-8M65-P47H

Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-05-24 19:05
VLAI
Details

Insufficient verification of data authenticity in Peloton TTR01 up to and including PTV55G allows an attacker with physical access to boot into a modified kernel/ramdisk without unlocking the bootloader.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-33887"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-15T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Insufficient verification of data authenticity in Peloton TTR01 up to and including PTV55G allows an attacker with physical access to boot into a modified kernel/ramdisk without unlocking the bootloader.",
  "id": "GHSA-9h8m-8m65-p47h",
  "modified": "2022-05-24T19:05:19Z",
  "published": "2022-05-24T19:05:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33887"
    },
    {
      "type": "WEB",
      "url": "https://fccid.io/2AA3N-TTR01"
    },
    {
      "type": "WEB",
      "url": "https://www.mcafee.com/blogs/consumer/mobile-and-iot-security/is-your-peloton-spinning-up-malware"
    },
    {
      "type": "WEB",
      "url": "https://youtu.be/RLjXfvb0ADw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9HMG-827W-9RHJ

Vulnerability from github – Published: 2026-05-05 17:15 – Updated: 2026-06-08 23:28
VLAI
Summary
nuts-node has JWT type confusion in v1 access token introspection that allows VP replay as access token
Details

Summary

The v1 access token introspection endpoint (/auth/v1/introspect_access_token) accepts any JWT signed by a key present on the node, without validating the JWT type, issuer-to-key binding, or required claims. This allows a Verifiable Presentation (VP) JWT to be replayed as an access token and receive an active: true introspection response.

Background

In the v1 auth flow (Nuts RFC003), access tokens are JWTs signed by the authorizer's key with: - iss = authorizer organization DID - sub = requester organization DID - service = purpose of use (e.g. "eOverdracht") - typ header = "JWT" (default, not explicitly set)

Verifiable Presentations are also JWTs with typ: "JWT" (per W3C VC Data Model 1.1). The W3C VC Data Model 2.0 changed this to vp+jwt specifically to prevent this class of confusion attack (See Securing Verifiable Credentials using JOSE and COSE 3.1.1).

Vulnerability details

The introspection endpoint performs only standard JWT checks. It does not perform the following Nuts-specific access token checks:

  1. Validate the typ header: both ATs and VPs use "JWT"
  2. Bind iss to the signing key: it doesn't verify that the iss claim matches the DID extracted from the kid
  3. Validate required claims: service can be empty; vp claim is silently ignored by FromMap() which uses lenient JSON unmarshaling

Attack scenario

Prerequisites: Attacker (Org B) has received a VP JWT from the victim (Org A) during a normal access token request flow.

  1. Org A creates a VP JWT signed with Org A's key and sends it to Org B (normal protocol flow) to request an access token
  2. Org B presents this VP JWT to Org A's resource server as a bearer access token
  3. Resource server calls Org A's v1 introspection endpoint
  4. Introspection checks privateKeyStore.Exists(kid), which passes, because Org A's key is on Org A's node
  5. JSON unmarshaling is lenient; the vp claim is silently ignored
  6. Returns active: true with service: "", iss: "", sub: <Org A's DID>

Mitigating factors

  • service is empty: resource servers that strictly require a non-empty service field may reject the request at the application level
  • iss is empty: VP JWTs don't set iss, so resource servers checking this field would see an empty value
  • Short-lived VPs: VPs typically expire within minutes, narrowing the attack window
  • v1 is legacy: the v2 flow uses opaque access tokens and is not affected

Severity rationale

While the introspection endpoint incorrectly returns active: true for a replayed VP, we consider this not practically exploitable in the current deployment landscape. Resource servers require valid service, iss and aud values to route requests to the correct databases. A replayed VP returns empty service, empty iss, and wrong sub (Org A instead of B), making it unusable for meaningful access. The attack also requires the victim to first present a VP to the attacker through a legitimate protocol flow, and VPs are short-lived.

The severity reflects that the protection against exploitation is accidental (resource servers need service for routing, not for security) and we cannot guarantee how all resource server implementations handle the active: true response with missing fields.

The fix

Affected versions: all v5.x releases prior to v5.4.31, and all v6.x releases prior to v6.2.3. From v5.4.31 and v6.2.3 onward, the following checks have been added to IntrospectAccessToken:

  1. iss-to-kid binding: extract the DID from the kid header and verify it matches the iss claim
  2. Required claims validation: reject tokens where service is empty
  3. typ header validation: requires access tokens to be of typ: "at+jwt"

Additionally, the access token creation code has been updated to use typ: "at+jwt" per RFC 9068.

Patch

Patches are available at https://github.com/nuts-foundation/nuts-node/releases/tag/v5.4.31 and https://github.com/nuts-foundation/nuts-node/releases/tag/v6.2.3.

Workaround

If users are unable to update their nuts-node, resource servers can mitigate this risk by explicitly validating the introspection response: reject responses where service is empty, where iss is empty or does not match the expected authorizer DID, or where sub does not match the expected requester DID (Org B instead of A).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nuts-foundation/nuts-node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41164"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T17:15:32Z",
    "nvd_published_at": "2026-05-26T18:16:47Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe v1 access token introspection endpoint (`/auth/v1/introspect_access_token`) accepts any JWT signed by a key present on the node, without validating the JWT type, issuer-to-key binding, or required claims. This allows a Verifiable Presentation (VP) JWT to be replayed as an access token and receive an `active: true` introspection response.\n\n## Background\n\nIn the v1 auth flow ([Nuts RFC003](https://nuts-foundation.gitbook.io/v1/rfc/rfc003-oauth2-authorization)), access tokens are JWTs signed by the authorizer\u0027s key with:\n- `iss` = authorizer organization DID\n- `sub` = requester organization DID\n- `service` = purpose of use (e.g. `\"eOverdracht\"`)\n- `typ` header = `\"JWT\"` (default, not explicitly set)\n\nVerifiable Presentations are also JWTs with `typ: \"JWT\"` (per W3C VC Data Model 1.1). The W3C VC Data Model 2.0 changed this to `vp+jwt` specifically to prevent this class of confusion attack (See [Securing Verifiable Credentials using JOSE and COSE 3.1.1](https://www.w3.org/TR/vc-jose-cose/#securing-with-jose)).\n\n## Vulnerability details\n\nThe introspection endpoint performs only standard JWT checks. It does not perform the following Nuts-specific access token checks:\n\n1. **Validate the `typ` header**: both ATs and VPs use `\"JWT\"`\n2. **Bind `iss` to the signing key**: it doesn\u0027t verify that the `iss` claim matches the DID extracted from the `kid`\n3. **Validate required claims**: `service` can be empty; `vp` claim is silently ignored by `FromMap()` which uses lenient JSON unmarshaling\n\n## Attack scenario\n\n**Prerequisites:** Attacker (Org B) has received a VP JWT from the victim (Org A) during a normal access token request flow.\n\n1. Org A creates a VP JWT signed with Org A\u0027s key and sends it to Org B (normal protocol flow) to request an access token\n2. Org B presents this VP JWT to Org A\u0027s resource server as a bearer access token\n3. Resource server calls Org A\u0027s v1 introspection endpoint\n4. Introspection checks `privateKeyStore.Exists(kid)`, which passes, because Org A\u0027s key is on Org A\u0027s node\n5. JSON unmarshaling is lenient; the `vp` claim is silently ignored\n6. Returns `active: true` with `service: \"\"`, `iss: \"\"`, `sub: \u003cOrg A\u0027s DID\u003e`\n\n## Mitigating factors\n\n- **`service` is empty**: resource servers that strictly require a non-empty `service` field may reject the request at the application level\n- **`iss` is empty**: VP JWTs don\u0027t set `iss`, so resource servers checking this field would see an empty value\n- **Short-lived VPs**: VPs typically expire within minutes, narrowing the attack window\n- **v1 is legacy**: the v2 flow uses opaque access tokens and is not affected\n\n## Severity rationale\n\nWhile the introspection endpoint incorrectly returns `active: true` for a replayed VP, we consider this not practically exploitable in the current deployment landscape. Resource servers require valid `service`, `iss` and `aud` values to route requests to the correct databases. A replayed VP returns empty `service`, empty `iss`, and wrong `sub` (Org A instead of B), making it unusable for meaningful access. The attack also requires the victim to first present a VP to the attacker through a legitimate protocol flow, and VPs are short-lived.\n\nThe severity reflects that the protection against exploitation is accidental (resource servers need `service` for routing, not for security) and we cannot guarantee how all resource server implementations handle the `active: true` response with missing fields.\n\n## The fix\n\nAffected versions: all v5.x releases prior to v5.4.31, and all v6.x releases prior to v6.2.3. From v5.4.31 and v6.2.3 onward, the following checks have been added to `IntrospectAccessToken`:\n\n1. **`iss`-to-`kid` binding**: extract the DID from the `kid` header and verify it matches the `iss` claim\n2. **Required claims validation**: reject tokens where `service` is empty\n3. **`typ` header validation**: requires access tokens to be of `typ: \"at+jwt\"`\n\nAdditionally, the access token creation code has been updated to use `typ: \"at+jwt\"` per RFC 9068.\n\n## Patch\n\nPatches are available at https://github.com/nuts-foundation/nuts-node/releases/tag/v5.4.31 and https://github.com/nuts-foundation/nuts-node/releases/tag/v6.2.3.\n\n## Workaround\n\nIf users are unable to update their nuts-node, resource servers can mitigate this risk by explicitly validating the introspection response: reject responses where `service` is empty, where `iss` is empty or does not match the expected authorizer DID, or where `sub` does not match the expected requester DID (Org B instead of A).",
  "id": "GHSA-9hmg-827w-9rhj",
  "modified": "2026-06-08T23:28:00Z",
  "published": "2026-05-05T17:15:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nuts-foundation/nuts-node/security/advisories/GHSA-9hmg-827w-9rhj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41164"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nuts-foundation/nuts-node"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuts-foundation/nuts-node/releases/tag/v5.4.31"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuts-foundation/nuts-node/releases/tag/v6.2.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "nuts-node has JWT type confusion in v1 access token introspection that allows VP replay as access token"
}

GHSA-9JPJ-G8VV-J5MF

Vulnerability from github – Published: 2026-04-04 06:26 – Updated: 2026-04-07 14:24
VLAI
Summary
OpenClaw: Gemini OAuth exposed the PKCE verifier through the OAuth state parameter
Details

Summary

Before OpenClaw 2026.4.2, the Gemini OAuth flow reused the PKCE verifier as the OAuth state value. Because the provider reflected state back in the redirect URL, the verifier could be exposed alongside the authorization code.

Impact

Anyone who could capture the redirect URL could learn both the authorization code and the PKCE verifier, defeating PKCE's interception protection for that flow and enabling token redemption.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.4.1
  • Patched versions: >= 2026.4.2
  • Latest published npm version: 2026.4.1

Fix Commit(s)

  • a26f4d0f3ef0757db6c6c40277cc06a5de76c52f — separate OAuth state from the PKCE verifier

OpenClaw thanks @BG0ECV for reporting.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.4.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34511"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-04T06:26:55Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nBefore OpenClaw 2026.4.2, the Gemini OAuth flow reused the PKCE verifier as the OAuth `state` value. Because the provider reflected `state` back in the redirect URL, the verifier could be exposed alongside the authorization code.\n\n## Impact\n\nAnyone who could capture the redirect URL could learn both the authorization code and the PKCE verifier, defeating PKCE\u0027s interception protection for that flow and enabling token redemption.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.4.1`\n- Patched versions: `\u003e= 2026.4.2`\n- Latest published npm version: `2026.4.1`\n\n## Fix Commit(s)\n\n- `a26f4d0f3ef0757db6c6c40277cc06a5de76c52f` \u2014 separate OAuth state from the PKCE verifier\n\nOpenClaw thanks @BG0ECV for reporting.",
  "id": "GHSA-9jpj-g8vv-j5mf",
  "modified": "2026-04-07T14:24:16Z",
  "published": "2026-04-04T06:26:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-9jpj-g8vv-j5mf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34511"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/a26f4d0f3ef0757db6c6c40277cc06a5de76c52f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-pkce-verifier-exposure-via-oauth-state-parameter"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Gemini OAuth exposed the PKCE verifier through the OAuth state parameter"
}

GHSA-9M63-33Q3-XQ5X

Vulnerability from github – Published: 2025-03-10 22:24 – Updated: 2025-03-14 20:02
VLAI
Summary
Vela Server Has Insufficient Webhook Payload Data Verification
Details

Impact

Users with an enabled repository with access to repo level CI secrets in Vela are vulnerable to the exploit.

Any user with access to the CI instance and the linked source control manager can perform the exploit.

Method

By spoofing a webhook payload with a specific set of headers and body data, an attacker could transfer ownership of a repository and its repo level secrets to a separate repository.

These secrets could be exfiltrated by follow up builds to the repository.

Patches

v0.26.3 — Image: target/vela-server:v0.26.3 v0.25.3 — Image: target/vela-server:v0.25.3

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

There are no workarounds to the issue.

References

Are there any links users can visit to find out more?

Please see linked CWEs (common weakness enumerators) for more information.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/go-vela/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.25.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.26.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/go-vela/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.26.0"
            },
            {
              "fixed": "0.26.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27616"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-10T22:24:35Z",
    "nvd_published_at": "2025-03-10T19:15:41Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nUsers with an enabled repository with access to repo level CI secrets in Vela are vulnerable to the exploit. \n\nAny user with access to the CI instance and the linked source control manager can perform the exploit.\n\n### Method\nBy spoofing a webhook payload with a specific set of headers and body data, an attacker could transfer ownership of a repository and its repo level secrets to a separate repository. \n\nThese secrets could be exfiltrated by follow up builds to the repository.\n\n### Patches\n`v0.26.3` \u2014 Image: `target/vela-server:v0.26.3`\n`v0.25.3` \u2014 Image: `target/vela-server:v0.25.3`\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nThere are no workarounds to the issue.\n\n### References\n_Are there any links users can visit to find out more?_\n\nPlease see linked CWEs (common weakness enumerators) for more information.",
  "id": "GHSA-9m63-33q3-xq5x",
  "modified": "2025-03-14T20:02:47Z",
  "published": "2025-03-10T22:24:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vela/server/security/advisories/GHSA-9m63-33q3-xq5x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27616"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vela/server/commit/257886e5a3eea518548387885894e239668584f5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vela/server/commit/67c1892e2464dc54b8d2588815dfb7819222500b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vela/server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vela/server/releases/tag/v0.25.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vela/server/releases/tag/v0.26.3"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3509"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vela Server Has Insufficient Webhook Payload Data Verification"
}

GHSA-9MC4-GRWM-PJ69

Vulnerability from github – Published: 2025-03-11 18:32 – Updated: 2025-03-11 18:32
VLAI
Details

Insufficient verification of data authenticity in some Zoom Workplace Apps may allow an unprivileged user to conduct a denial of service via network access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-0149"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-11T17:16:17Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient verification of data authenticity in some Zoom Workplace Apps may allow an unprivileged user to conduct a denial of service via network access.",
  "id": "GHSA-9mc4-grwm-pj69",
  "modified": "2025-03-11T18:32:16Z",
  "published": "2025-03-11T18:32:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0149"
    },
    {
      "type": "WEB",
      "url": "https://www.zoom.com/en/trust/security-bulletin/zsb-25008"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-111: JSON Hijacking (aka JavaScript Hijacking)

An attacker targets a system that uses JavaScript Object Notation (JSON) as a transport mechanism between the client and the server (common in Web 2.0 systems using AJAX) to steal possibly confidential information transmitted from the server back to the client inside the JSON object by taking advantage of the loophole in the browser's Same Origin Policy that does not prohibit JavaScript from one website to be included and executed in the context of another website.

CAPEC-141: Cache Poisoning

An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.

CAPEC-142: DNS Cache Poisoning

A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.

CAPEC-148: Content Spoofing

An adversary modifies content to make it contain something other than what the original content producer intended while keeping the apparent source of the content unchanged. The term content spoofing is most often used to describe modification of web pages hosted by a target to display the adversary's content instead of the owner's content. However, any content can be spoofed, including the content of email messages, file transfers, or the content of other network communication protocols. Content can be modified at the source (e.g. modifying the source file for a web page) or in transit (e.g. intercepting and modifying a message between the sender and recipient). Usually, the adversary will attempt to hide the fact that the content has been modified, but in some cases, such as with web site defacement, this is not necessary. Content Spoofing can lead to malware exposure, financial fraud (if the content governs financial transactions), privacy violations, and other unwanted outcomes.

CAPEC-218: Spoofing of UDDI/ebXML Messages

An attacker spoofs a UDDI, ebXML, or similar message in order to impersonate a service provider in an e-business transaction. UDDI, ebXML, and similar standards are used to identify businesses in e-business transactions. Among other things, they identify a particular participant, WSDL information for SOAP transactions, and supported communication protocols, including security protocols. By spoofing one of these messages an attacker could impersonate a legitimate business in a transaction or could manipulate the protocols used between a client and business. This could result in disclosure of sensitive information, loss of message integrity, or even financial fraud.

CAPEC-384: Application API Message Manipulation via Man-in-the-Middle

An attacker manipulates either egress or ingress data from a client within an application framework in order to change the content of messages. Performing this attack can allow the attacker to gain unauthorized privileges within the application, or conduct attacks such as phishing, deceptive strategies to spread malware, or traditional web-application attacks. The techniques require use of specialized software that allow the attacker to perform adversary-in-the-middle (CAPEC-94) communications between the web browser and the remote system. Despite the use of AiTH software, the attack is actually directed at the server, as the client is one node in a series of content brokers that pass information along to the application framework. Additionally, it is not true "Adversary-in-the-Middle" attack at the network layer, but an application-layer attack the root cause of which is the master applications trust in the integrity of code supplied by the client.

CAPEC-385: Transaction or Event Tampering via Application API Manipulation

An attacker hosts or joins an event or transaction within an application framework in order to change the content of messages or items that are being exchanged. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that look authentic but may contain deceptive links, substitute one item or another, spoof an existing item and conduct a false exchange, or otherwise change the amounts or identity of what is being exchanged. The techniques require use of specialized software that allow the attacker to man-in-the-middle communications between the web browser and the remote system in order to change the content of various application elements. Often, items exchanged in game can be monetized via sales for coin, virtual dollars, etc. The purpose of the attack is for the attack to scam the victim by trapping the data packets involved the exchange and altering the integrity of the transfer process.

CAPEC-386: Application API Navigation Remapping

An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of links/buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains links/buttons that point to an attacker controlled destination. Some applications make navigation remapping more difficult to detect because the actual HREF values of images, profile elements, and links/buttons are masked. One example would be to place an image in a user's photo gallery that when clicked upon redirected the user to an off-site location. Also, traditional web vulnerabilities (such as CSRF) can be constructed with remapped buttons or links. In some cases navigation remapping can be used for Phishing attacks or even means to artificially boost the page view, user site reputation, or click-fraud.

CAPEC-387: Navigation Remapping To Propagate Malicious Content

An adversary manipulates either egress or ingress data from a client within an application framework in order to change the content of messages and thereby circumvent the expected application logic.

CAPEC-388: Application API Button Hijacking

An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains buttons that point to an attacker controlled destination.

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.

CAPEC-701: Browser in the Middle (BiTM)

An adversary exploits the inherent functionalities of a web browser, in order to establish an unnoticed remote desktop connection in the victim's browser to the adversary's system. The adversary must deploy a web client with a remote desktop session that the victim can access.

← Back to the CWE list