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.
Short-circuiting password verification with a user existence check introduces an observable timing side-channel (CWE-208) allowing username enumeration.
Cryptographic signatures or digests are compared using standard equality operators (`eq` or `==`), which terminate early upon mismatch and expose the application to timing side-channel attacks. Use a constant-time comparison method such as `secure_compare` or `String::Compare::ConstantTime::equals_strict`.
Sensitive tokens or secrets are compared using non-constant-time equality operators (`===` or `==`). This leaks timing information and may allow attackers to deduce valid tokens via side-channel attacks. Use `hash_equals()` for constant-time comparison instead.
Comparing cryptographic hashes using non-constant-time functions (`ZEPHIR_IS_IDENTICAL`) makes the application vulnerable to timing attacks. An attacker may use observable timing discrepancies to forge valid MACs or signatures byte-by-byte. Use a constant-time comparison function such as `zephir_hash_equals`.
Potential timing side channel due to early break or use of non-constant-time comparison functions (memcmp, strcmp, etc.) during authentication. Use constant-time comparison functions and ensure evaluation does not exit early based on matching results.
A non-constant-time shift-and-add modular multiplication routine was detected. The loop `while $EXP > 0` and the branch `if $EXP & 1 == 1` make the execution time proportional to the bit-length and Hamming weight of the multiplier. When operating on cryptographic secrets, this timing side-channel can leak the secret multiplier. Replace this with a branchless
Non-constant-time comparison of secret/token field '$ATTR' using the == operator. Python's str.__eq__ short-circuits on the first mismatching byte, leaking timing information that allows an attacker to recover the secret byte-by-byte (CWE-208). Replace with secrets.compare_digest($OBJ.$ATTR, $TOKEN) or hmac.compare_digest($OBJ.$ATTR, $TOKEN), which run in co
Authentication function compares the supplied plaintext against a placeholder bcrypt hash when the user's stored password is empty (a CWE-208 timing-attack mitigation), but the success guard only checks `err == nil` without also requiring that the stored password is non-empty. An unauthenticated attacker who submits the plaintext that matches the placeholder
The password reset / account recovery handler awaits an artificial delay only on the "user not found" / "no email" branches and returns early, while the success path (email sent) returns without an equivalent delay. This timing differential is observable by an unauthenticated attacker and enables username/email enumeration (CWE-208 / CWE-204). Pad all branch
A short-circuiting logical operator `||` is used in a padding validation check, causing non-constant time execution. This makes the validation vulnerable to timing side-channel padding oracle attacks. Use a bitwise `|` to ensure both conditions are always evaluated.
The constant-time "is non-zero" bitwise idiom `(x | x.wrapping_neg()) >> N` produces a boolean-shaped (0 or 1) result. Without a `core::hint::black_box()` optimization barrier wrapping this expression itself, LLVM may rewrite downstream mask arithmetic into a conditional branch on targets without a conditional-move instruction (notably `thumbv6m-none-eabi` /
Hardcoded default SCRAM iterations during mock secret generation creates an observable response discrepancy (CWE-208), allowing unauthenticated user enumeration when non-default iteration counts are used. Assign the runtime configured iteration variable instead.
Comparing an authentication token (like the Authorization header) using standard equality operators (`in`, `not in`, `==`, `!=`) can lead to a timing side-channel. These operators short-circuit and leak the length of the matching prefix, allowing an attacker to guess the token character by character. Use `secrets.compare_digest` or `hmac.compare_digest` inst
The SM2 modular inversion function `ecp_sm2p256_inv_mod_ord` is not implemented in a constant-time manner on 64-bit ARM platforms, creating a timing side-channel (CVE-2025-9231). The patch replaces this custom implementation with 0 (NULL) to fall back to a safe, constant-time inversion algorithm.
A non-constant time comparison (`==` or `!=`) is used to verify authentication tokens from request headers. An attacker can exploit this by measuring server response times to guess the valid token character-by-character. Use `crypto/subtle.ConstantTimeCompare` instead for securely comparing secrets.
Using `Arrays.equals()` to compare security-sensitive data (like signatures, hashes, or tokens) introduces a timing side-channel vulnerability because it stops comparing at the first mismatched byte. An attacker can exploit this observable timing discrepancy to forge or guess the expected value byte-by-byte. Use `java.security.MessageDigest.isEqual()` for a
Using non-constant time methods like `.find()` or `.index()` to locate a padding separator byte (e.g., `b'\x01'` or `b'\x00'`) during decryption introduces a timing side-channel. This leaks information about the plaintext structure and makes the application vulnerable to padding oracle attacks like Manger's attack. Use constant-time array parsing instead.
The application was found executing string comparisons using one of `===`, `!==`, `==` or `!=` against security sensitive values. String comparisons like this are not constant time, meaning the first character found not to match in the two strings will immediately exit the conditional statement. This allows an adversary to calculate or observe small timing d
JSCWE-208'String comparisons using ''==='', ''!=='', ''!='' and ''=='' is vulnerable to timing attacks. More info: https://snyk.io/blog/node-js-timing-attack-ccc-ctf/'
JSCWE-208
