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.
TOTP verification with ROTP is performed without specifying the `after` timestamp parameter. This allows valid one-time passwords to be reused/replayed within the drift window. Pass `after:` or `:after => last_use_timestamp` to prevent OTP replay.
OIDC token validation checks audience or issuer claims but does not verify the 'nonce' claim against an expected nonce. This may allow replay attacks or authentication bypass using captured OIDC tokens.
Authentication code validation short-circuits based on cached validity status ($AUTH['valid']), allowing authentication bypass without verifying the submitted verification code or checking for single-use replay.
EVM transaction verification checks transaction hash settlement against charge parameters without verifying that the transaction hash is unused or committing it to a deduplication store, allowing capture-replay attacks.
The circular buffer replay window clears an entry at `count % length` before incrementing `count`. If the newly validated index coincides with the current counter modulo length, setting the slot to `seen = true` is immediately overwritten by `seen = false`, leaving the system vulnerable to request replay. Increment `count` before resetting the slot at the up
The `TryAdd` method for a token replay cache always returns `true` (or lacks a `return false;` path). If it does not explicitly return `false` on duplicate items, calling components will assume the token is new, preventing replay protection from working successfully. Ensure the method returns `false` when the token already exists in the cache.
The CAPTCHA response is validated but not invalidated upon successful form processing, which may allow CAPTCHA reuse and replay attacks (CVE-2026-45734).
Using a fixed-size LinkedHashMap with size-based eviction in removeEldestEntry for token or JTI replay tracking is vulnerable to replay attacks via cache eviction flooding. Use an expiration-based cache or a dedicated replay validator with distributed backing.
Returning `false` from `isOneTimeAction` allows the required action to be executed multiple times using the same action token. If an action token (such as an execute-actions email link) is intercepted, it can be replayed to perform sensitive actions maliciously, such as unauthorized authenticator enrollment. Ensure that sensitive actions are strictly one-tim
Peer state or endpoint address is updated before validating the anti-replay counter, allowing replayed packets to hijack roaming endpoints or disrupt session state.
The application validates TOTP tokens using `verifyKey()`, which does not prevent tokens from being reused within their validity window. This allows for capture-replay attacks where an intercepted token is reused to bypass authentication. To prevent this, use `verifyKeyNewer()` and persist the timestamp of the last successful authentication to ensure one-tim
