A JWT secret is loaded from configuration or environment and used without explicit length or weakness validation. If the variable is unset or overridden with weak values (e.g., an empty string), an attacker can forge valid JWTs to bypass authentication. Verify the length and strength of the secret before initializing the JWT instance.
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
- 12.1M
- Verified
- 4797
- Authors
- 2
`os.environ.get()` is reading a security-sensitive variable (JWT/secret/key/token/password) but supplies a hardcoded string literal as a fallback default. If the environment variable is unset, the application will sign/verify/encrypt with the public, attacker-known fallback (CVE-2026-42869, GHSA-4gxj-hw3c-3x2x). Secrets must have no in-code default — fail cl
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
bcrypt.hash() / bcrypt.hashSync() is being called with a hardcoded string literal as the password argument. This embeds a known credential into the source code (CWE-798: Use of Hard-coded Credentials). Even if the resulting bcrypt hash is stored in a database, the cleartext password is publicly visible in the repository, so any attacker can authenticate with
The application uses a statically hard-coded string as a fallback for a JWT or session secret when the environment variable is not configured. This allows an attacker to bypass authentication by signing a forged JSON Web Token (JWT) or session cookie using the known default secret. To fix, require the environment variable to be set, or dynamically generate a
A hard-coded string literal is used as the secret/key parameter of jsonwebtoken `sign` or `verify`. Embedding the HMAC signing key in source code allows anyone with access to the repository or a shipped bundle to recover the key and forge tokens with arbitrary identity and group claims, leading to authentication bypass and privilege escalation (see CVE-2025-
Hardcoded string literal used as a tonic gRPC `authorization` metadata value. This places a static, non-rotatable shared secret in the source tree, which is equivalent to no authentication at all once the code is published or leaked (CWE-798, CWE-287). Any peer that knows the literal can authenticate to the gRPC service. Replace the static token with a per-r
A hardcoded default value is provided for a secret. This exposes the application to authentication bypass if a custom secret is not configured, as attackers can forge valid tokens or credentials using the known default value. Ensure that secrets default to None or securely generated values, and enforce that they are explicitly configured in production.
Mojolicious applications and framework code should not use the predictable application moniker or insecure PRNGs like `rand` to generate session secrets or CSRF tokens. This allows an attacker to compute valid HMAC signatures and forge session cookies. Replace predictable secrets with strong cryptographic random strings (e.g. `Mojo::Util::urandom_urlsafe`).
Hardcoded static SSH password found in Packer configuration. This allows attackers with network access to gain root access to the VM during the image build process. Avoid default static credentials; inject dynamically generated passwords like '{{ uuid }}' or inject them through variables.
Packer Proxmox builder template defines an SSH builder user via ssh_username/ssh_password but no provisioner locks the account (e.g. `usermod -L {{user `ssh_username`}}`) before image capture. VM images produced from this template will ship with the default builder credentials enabled, allowing any attacker reachable on TCP/22 to SSH in and escalate to root
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