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 verification algorithm is dynamically populated from the unverified token header (`alg`). This allows an attacker to forge tokens using algorithm confusion (e.g., supplying HS256 signed with an asymmetric public key). Always hardcode or whitelist allowed algorithms explicitly (e.g. `algorithms: ['RS256']`).
OAuth message verification dynamically resolves the signature algorithm from the untrusted request parameter without checking against an allowlist of permitted signature methods. This allows signature algorithm downgrade/confusion attacks.
Configuring SMB minimum version to SMB1 allows negotiation down to the legacy SMB1/CIFS protocol, which lacks mandatory message signing/encryption and is vulnerable to NTLM relay and MITM tampering attacks. Use SMB202 or higher instead.
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
The JWT `sign` function generates a token header using a separate algorithm parameter rather than extracting the algorithm and Key ID directly from the private key object. This omission leaves the framework vulnerable to algorithm confusion during verification because the algorithm and key are not cryptographically bound together.
MessageDigest.getInstance("MD5") is hardcoded in a class that specifies an algorithm parameter, ignoring the configured algorithm.
A key derivation function accepts an iteration parameter but uses wc_HKDF instead of a password-based key derivation function like wc_PBKDF2. HKDF does not support computational work factor scaling, severely weakening offline password security.
Dynamically populated hashing algorithms from external inputs or parsed strings can lead to cryptographic downgrade attacks. An attacker may force the application to use a weaker algorithm (e.g., 'md5') when validating signatures. Enforce strong algorithms by hardcoding the expected algorithm (e.g., 'sha256') or validating it strictly against an allowlist be
Deriving a JWT secret key using an MD5 hash restricts the key's entropy to at most 128 bits and can make tokens vulnerable to offline forgery attacks, especially if the hashed input (like a password) is predictable. Use a cryptographically secure random value generation (e.g., SecureRandom or UUIDs) for symmetric signature secrets.
Authentication or access token derived from `config('app.key')` using MD5 (e.g. `md5(config('app.key') . 'suffix')`). MD5 is cryptographically weak and the construction is an unkeyed hash (not a true HMAC), producing a static, deterministic token that can be brute-forced or leaked via query strings, server logs, browser history and proxy logs. Use `hash_hmac
This rule detects Authlib's internal pattern before CVE-2026-28490 was fixed, where an algorithm is retrieved from a registry without validating whether it is deprecated when an explicit whitelist config is missing. This allowed insecure algorithms like RSA1_5 and 'none' to be used by default.
Using a static hash of an object's `.secret` attribute (e.g., `hashlib.sha1(order.secret).hexdigest()`) for URL or webhook authentication is vulnerable to replay attacks across endpoints. Because the signature is not attached to a specific endpoint, an attacker can capture it from one view (like a return URL) and reuse it on another (like a webhook notify UR
The ciphertext produced is susceptible to alteration by an adversary. This mean that the cipher provides no way to detect that the data has been tampered with. If the ciphertext can be controlled by an attacker, it could be altered without detection.
KotlinCWE-327This specific mode of CBC with PKCS5Padding is susceptible to padding oracle attacks. An adversary could potentially decrypt the message if the system exposed the difference between plaintext with invalid padding or valid padding. The distinction between valid and invalid padding is usually revealed through distinct error messages being returned for each con
KotlinCWE-327The crypt functions are not recommended due to the significantly small key space. Modern hardware can crack crypt produced passwords relatively quickly. Consider using the Argon2id password hashing algorithm provided by libsodium. For more information please see: https://libsodium.gitbook.io/doc/password_hashing.
Use of `{algorithm:'none'}` detected with `jsonwebtoken`. Using none as the algorithm for jsonwebtoken can directly impact the integrity of the information transfer through the JWT token. Consider using a secure algorithm to sign your JWT token such as HMAC or RSA. Some safe usage examples: ``` let token = jwt.sign({user:"user1"}, 'secret', {algorithm: 'HS25
JSCWE-327Cryptographic algorithms provide many different modes of operation, only some of which provide message integrity. Without message integrity it could be possible for an adversary to attempt to tamper with the ciphertext which could lead to compromising the encryption key. Newer algorithms apply message integrity to validate ciphertext has not been tampered wi
JavaCWE-327Cryptographic block ciphers can be configured to pad individual blocks if there is not enough input data to match the size of the block. This specific mode of CBC used in combination with PKCS5Padding is susceptible to padding oracle attacks. An adversary could potentially decrypt the message if the system exposed the difference between plaintext with invali
JavaCWE-327The RC4 algorithm is vulnerable to many attacks and should no longer be used for encrypting data streams. Consider using libsodium's `crypto_secretstream_xchacha20poly1305` stream cipher encryption functions instead. For more information please see: https://libsodium.gitbook.io/doc/secret-key_cryptography/secretstream If you must be FIPS compliant, consider
Cryptographic algorithms provide many different modes of operation, only some of which provide message integrity. Without message integrity it could be possible for an adversary to attempt to tamper with the ciphertext which could lead to compromising the encryption key. Newer algorithms apply message integrity to validate ciphertext has not been tampered wi
JavaCWE-327The DES algorithm has not been recommended for over 15 years and was withdrawn from NIST (FIPS 46-3) in 2005. Consider using libsodium's `crypto_secretbox_easy` authenticated encryption functions instead. For more information please see: https://libsodium.gitbook.io/doc/secret-key_cryptography/secretbox. If you must be FIPS compliant, consider using OpenSSLs
The application was found using an insecure or risky digest or signature algorithm. MD5 and SHA1 hash algorithms have been found to be vulnerable to producing collisions. This means that two different values, when hashed, can lead to the same hash value. If the application is trying to use these hash methods for storing passwords, then it is recommended to s
PythonCWE-327The application was found using an insecure or risky digest or signature algorithm. MD2, MD4, MD5 and SHA1 hash algorithms have been found to be vulnerable to producing collisions. This means that two different values, when hashed, can lead to the same hash value. If the application is trying to use these hash methods for storing passwords, then it is recomm
PythonCWE-327
