Directly reading the Kubernetes ServiceAccount token from '/var/run/secrets/kubernetes.io/serviceaccount/token' can expose cluster credentials if the token is transmitted in outbound requests. Use a scoped token with a restricted audience instead.
Rule Explorer
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.
- Public rules
- 4797
- Downloads
- 6.6M
- Verified
- 4797
- Authors
- 2
API response sanitization unsets password fields but omits unsetting pass_indatabase_crypted, which may leak password verifiers to unauthorized API consumers.
Plugin configuration option for credential field '$NAME' is missing 'sensitive: True', potentially exposing secrets in API responses.
Authentication plugin for cleartext credentials ('dialog' or 'mysql_clear_password') does not enforce a secure connection requirement via requireSecure() or requireSsl() returning true, allowing sensitive credentials to be sent over unencrypted transports.
Database credentials may be sent in the initial handshake response before validating authentication plugin security requirements and MitM resistance, potentially exposing plaintext credentials to a rogue server or MitM attacker.
Authentication plugin sends cleartext credentials without requiring a secure connection (TLS or local socket).
Request options and headers are reused across an HTTP redirect without checking whether the destination URL is cross-origin. Credential headers and authentication options should be stripped before following cross-origin redirects to prevent credential leakage.
Configuring Git to use the 'store' credential helper or embedding plaintext credentials directly into a credential helper script causes credentials to be stored unencrypted on disk. Pass credentials via environment variables or secure credential managers instead.
AsyncHttpClient instances unconditionally copy Realm credentials to arbitrary redirect targets without checking domain boundaries. This propagates plaintext credentials on cross-domain redirects or HTTPS-to-HTTP downgrades. To fix this, ensure the realm is stripped when crossing origin boundaries securely.
An npm publish step sets NODE_AUTH_TOKEN from a long-lived static repository secret. Long-lived tokens can be stolen, leaked, or misused by anyone who can push a matching git tag to publish malicious packages as part of a supply chain attack (CVE-2026-34841). Replace static token authentication with OIDC: grant 'id-token: write' to the workflow's permissions
During a cross-origin redirect, sensitive headers such as Cookie and Proxy-Authorization might not be properly removed. This can expose active session credentials and proxy tokens to untrusted third-party servers. Ensure that you clear all sensitive headers when the redirect target differs from the current origin.
Directly assigning a password variable or field to a JWT-designated struct field is dangerous. JWT fields are often assumed to be non-confidential identity tokens and are frequently serialized and exposed in monitoring endpoints or logs. This can lead to plaintext credential leakage (e.g., CVE-2026-33216 in NATS). Only assign validated identity tokens to JWT
JWT tokens often contain sensitive information in their payload. Storing them in a cookie without encryption exposes this data (such as user IDs or emails) to anyone who can access the cookie. Ensure the JWT is encrypted before saving it in an HTTP cookie.
A cloned HTTP request failed to strip Authentication/Authorization headers before a redirect. This can leak credentials to a third party. Ensure these headers are stripped alongside 'Host' or 'Cookie'.
The application is storing a password in the JWT token payload. Storing passwords in JWT token payloads is an insecure practice that can lead to compromised credentials. The password transmitted in the JWT payload is not encrypted and therefore visible to anyone who intercepts the token. It is recommended to avoid storing sensitive information like passwords
Hardcoded JWT secret or private key was found. Hardcoding secrets like JWT signing keys poses a significant security risk. If the source code ends up in a public repository or is compromised, the secret is exposed. Attackers could then use the secret to generate forged tokens and access the system. Store it properly in an environment variable. Here are some
The object is passed strictly to jose.JWT.sign(...). Make sure that sensitive information is not exposed through JWT token payload.
No token revoking configured for `express-jwt`. A leaked token could still be used and unable to be revoked. Consider using function as the `isRevoked` option.
Consider changing the default session cookie name. An attacker can use it to fingerprint the server and target attacks accordingly.
'Default session middleware settings: `domain` not set. It indicates the domain of the cookie; use it to compare against the domain of the server in which the URL is being requested. If they match, then check the path attribute next.'
'Default session middleware settings: `path` not set. It indicates the path of the cookie; use it to compare against the request path. If this and domain match, then send the cookie in the request.'