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.
Directly converting decrypted token strings to integers using intval() without validating that the plaintext strictly contains digits allows forged or spliced CBC ciphertexts to bypass authentication/authorization checks.
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.
`webauthn_account_id` uses `super || ...` without checking the current route. If a user is already authenticated, `super` resolves to the active session's account ID rather than the target account being authenticated, leading to authentication bypass or account takeover.
Parsing a JWT using `SignedJWT.parse(...)` and extracting its claims via `getJWTClaimsSet()` without verifying its signature allows unauthenticated attackers to forge token claims and bypass security controls.
JWT claims or payload were retrieved from a `SignedJWT` parsed with `SignedJWT.parse()` without first verifying the cryptographic signature with `verify()`. An attacker can forge or alter the token claims to bypass authentication or escalate privileges.
JWT claims are parsed and retrieved without verifying the token's cryptographic signature, issuer, or audience. Attackers can forge unverified token claims or roles. Always verify the signature and validate claims using a TokenValidator, JWTProcessor, or JWSVerifier before reading claims.
Decryption function accepts embedded post-quantum private key from file metadata without verifying if the key is encrypted (CWE-287).
User confirmation email is resent without verifying if the user account is in a pending state or eligible for confirmation. This may allow unauthorized users to request confirmation tokens and potentially bypass approval workflows.
Encrypted token (#jose_jwe{}) without a verified inner signature was accepted as valid ({ok, ...}). OpenID Connect Core 1.0 section 2 and JARM processing rules mandate that encrypted ID tokens and JARM responses must be signed before encryption (Nested JWT). Unsigned encrypted payloads must be rejected.
Module registry client does not utilize registry authentication credentials for direct package downloads.
WordPress AJAX request made without security nonce verification token.
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.
Hardcoding 'dangerouslyDisableDefaultAuthPolicy' or 'dangerouslyAllowOutsideDevelopment' to 'true' in Backstage configuration disables default authentication policy enforcement or permits guest access in non-development environments.
Restoring settings into freepbx_settings without filtering or validating the AUTHTYPE setting can allow an attacker to disable authentication (AUTHTYPE=none).
Handling expired JWT tokens (`jwt.ErrTokenExpired`) by unconditionally returning `true` without verifying HTTP request headers or proxy identity assertions allows attackers with expired tokens to bypass authentication.
JWT claim 'sub' is assigned a constant or static variable instead of the account user identifier during token generation inside an account loop. This causes all generated tokens to share the same subject identity.
The JWT 'sub' (subject) claim is assigned a static string literal rather than a dynamic user or entity identifier. This causes all generated tokens to share identical subject identity, leading to broken authentication or authorization controls.
Defaulting a missing or nil authentication callback function to a no-op function unconditionally satisfies security requirements and bypasses authentication checks.
Deduplicating inputs with Set before normalizing them (e.g., with .map()) allows raw variations of identical values to bypass deduplication. Perform normalization prior to deduplication.
Hardcoding the 'sub' (subject) claim in JWT tokens to a static string literal causes all issued tokens to share the same subject identity. The 'sub' claim must uniquely identify the user or principal.
Extracting authentication credentials from `URL.User` on an HTTP request reads credentials from URL userinfo instead of standard HTTP Basic Auth headers (`req.BasicAuth()`). This can lead to authentication bypass or credential leakage.
The JWT 'sub' (subject) claim is set to a static identifier or string literal instead of a dynamic user identifier. Hardcoding the subject claim causes all generated tokens to share the same identity, breaking user isolation and authorization boundaries.
A static or hardcoded string literal is used for the JWT 'sub' (subject) claim. The 'sub' claim in a JWT must uniquely identify the principal or user account to prevent token identity collision and authorization bypass.
A static string literal is assigned to the JWT 'sub' (subject) claim in `jwt.MapClaims`. JWT subject claims should uniquely identify the principal or user account associated with the token. Assigning a fixed string to 'sub' causes all issued tokens to share the same subject, breaking user context isolation.
