Search the public rule index by CVE, GHSA, CWE, language, framework, author, or rule slug. Filter by language, framework, severity, confidence, license, and validation status.
The JWT signing function defaults to a symmetric algorithm (like 'HS256') and subsequently places it in the token header, but fails to check if the provided private key is an asymmetric JSON Web Key (JWK) containing its own structured 'alg' (algorithm) property. This allows for algorithm confusion attacks where an asymmetric key is mistakenly processed as a
The JWT signing function creates a token header using a provided or default algorithm parameter without verifying if the provided key object contains its own native 'alg' or 'kid' properties. When a JSON Web Key (JWK) is passed natively to this signing function, it may be used with a mismatched symmetric algorithm (e.g., 'HS256'), leading to severe algorithm
JWSObject.parse() is called and the payload is consumed without first calling .verify(verifier). Parsing a JWSObject only deserializes the token structure — the cryptographic signature is NOT checked until .verify() is explicitly called and its boolean result asserted. An attacker with a MITM position can substitute a crafted JWT (e.g., a forged OIDC discove
A sighash FFI callback closure returns `None` on hash-type validation failure without overwriting the output buffer with random bytes. When the C/C++ FFI bridge does not treat `None` as a failure signal, the sighash buffer retains a stale digest from a prior computation. An attacker can prime the buffer with a valid digest (via a first script opcode), then t
AWS SNS webhook handler dispatches on req.body.Type without first verifying the SNS message signature (CWE-347). Unauthenticated callers can POST a forged SNS payload to trigger workflow automations, unsubscribe contacts, corrupt delivery metrics, or exhaust billing credits. Verify the RSA Signature field against a certificate fetched from a validated Signin
A JWT token parsed with `jwt.Parse` or `jwt.ParseWithClaims` is accessed by checking if it is non-nil without also verifying the token's validity (`token.Valid`) or checking the returned error. Invalid tokens (e.g., forged signatures) may still evaluate as non-nil, leading to authentication bypass. Always check `token.Valid` or ensure the parsing error is ha
Unconditional extraction of a SAML assertion element via array indexing (e.g., `assertion[0]`) without ensuring exactly one assertion is present. This weak validation pattern enables SAML Assertion Wrapping (XML Signature Wrapping) vulnerabilities. An attacker may inject an unsigned forged assertion alongside a legitimately signed assertion to bypass authent
JWT validation via lcobucci/jwt does not include a `SignedWith` constraint. Only time-based or other non-cryptographic constraints are passed to `validator()->validate()` / `validator()->assert()`, so the token's cryptographic signature is never verified. An attacker can forge or tamper with the JWT payload (e.g. impersonate any user via a `user_uuid` claim)
A missing MAC checksum validation was detected for FIPS fastpath input. The 8-byte signature is explicitly skipped using `in_uint8s` instead of being read and verified. This allows a man-in-the-middle to manipulate the ciphertext undetected. Ensure the signature is read and validated with `xrdp_sec_fips_check_sig` against the decrypted payload.
A JWS "none" algorithm class defines a verify() method that returns a constant (e.g., False or True) instead of inspecting the signature argument. RFC 7518 §3.6 requires a "none" JWS to carry an empty signature. The verify() implementation must therefore explicitly check that the signature is empty (e.g., `return sig == b""`). Returning a constant leaves sig
A cryptographic verification function returns `True` explicitly when the generated hash or value is falsey. This indicates a fail-open behavior where unsupported algorithms or missing values bypass the integrity check. Verification should fail closed by returning `False` when the hash cannot be computed.
Certificate verification does not account for alternate fingerprints generated by ECDSA signature malleability (high-S/low-S forms). An attacker can alter the signature to its alternate valid form, changing its fingerprint without affecting signature validity, and thus bypass a fingerprint-based blocklist.
JWT payload is parsed by manually splitting the token on '.' and base64url-decoding the payload segment, then trusting the resulting claims without verifying the cryptographic signature. An attacker can forge a token whose payload contains arbitrary claims (e.g. `sub`, `aud`, `iss`, `exp`, custom role/admin claims) and the syntactic claim checks will pass be
Signature verification incorrectly returns early and skips validation when exact-match fields are empty, ignoring regular expression constraints. Ensure regex variables are also verified to prevent bypassing policies during keyless artifact verification.
Re-encoding parsed query parameters (like SAMLRequest or SAMLResponse) using urlencode() to reconstruct a query string for signature validation is unsafe. Framework query parsing (e.g., `getQueryParams()`) may drop duplicate parameters or decode values differently than they appear in the raw request. This can allow an attacker to bypass SAML signature valida
Extracting trusted SAML assertion fields via REXML::XPath while binding the `id` XPath variable to `signed_element_id` (e.g. `REXML::XPath.first(doc, "/p:Response/a:Assertion[@ID=$id]...", { ..., "id" => doc_to_validate.signed_element_id })`) is vulnerable to XML Signature Wrapping (CVE-2025-25292 / GHSL-2024-330). Nokogiri (used for canonicalization/signatu
SAML signature-validation pipeline re-queries the raw XML document with REXML::XPath using `signed_element_id` as the `@ID` lookup variable to fetch downstream identity content (NameID, Attributes, Subject, etc.). The cryptographic signature was verified by Nokogiri on a (potentially) different document tree; trusting REXML's ID-based lookup on the raw docum
The application validates a SAML request or response by accepting only the inflated XML string instead of an envelope object containing the HTTP-Redirect `Signature` and `SigAlg` parameters. This implicitly bypasses cryptographic verification of the SAML payload, allowing attackers to forge logout requests and potentially compromise session integrity. Modify
XML Signature Wrapping (CVE-2024-45409): SAML signature validation uses a document-root-relative XPath ("//ds:...") to locate ds:Reference, ds:CanonicalizationMethod, ds:DigestMethod, ds:DigestValue, or ds:Transforms/ds:Transform. Because these queries traverse the entire document instead of the already-authenticated SignedInfo/Reference subtree, an attacker
The `supabase.auth.getSession()` method extracts session data but does not cryptographically verify the JWT signature. This can allow authentication bypass if the token is forged or revoked. To securely validate the session, always call `supabase.auth.getUser()` in the same context to ensure the JWT is properly verified.
A hardcoded, incomplete list of strings (like `-----BEGIN PUBLIC KEY-----`) is used to prevent asymmetric keys from being used as HMAC secrets. This can lead to algorithm confusion vulnerabilities if unhandled key types (e.g., OpenSSH ECDSA) are provided, allowing attackers to forge tokens. Use robust key parsing and format validation instead of string block
