Storing an unkeyed plaintext hash (such as 'original_hash' or 'plaintext_hash') in metadata headers allows offline plaintext confirmation and cross-file correlation without the decryption key.
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
- 12M
- Verified
- 4797
- Authors
- 2
Sensitive private key material should not be stored directly in SharedPreferences because preference files are stored without restricted permissions (e.g. 0644). Store private keys in a dedicated owner-only file (mode 0600) or secure credential storage.
Plaintext action argument inherits sensitivity from source attribute instead of enforcing `sensitive?: true`, risking cleartext exposure in logs, inspect dumps, and error reports.
Raw API token or secret is embedded directly into a dictionary passed to template rendering instead of using an opaque handle or hashed identifier.
Values serialized with `Ash.Type.dump_to_embedded/3` are stored directly without redacting nested sensitive attributes. If the attribute represents an embedded resource, union, or list containing sensitive fields (`sensitive?: true`), those sensitive values will be exposed in cleartext.
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.
Direct encoding of raw input arguments into JSON for database auditing or logging without redaction. Sensitive tokens or passwords may be logged in plaintext. Ensure inputs are sanitized or filtered before storing them.
A cryptographic token generated securely or retrieved from an incoming request is stored or verified in the database in plaintext. If the database leaks, an attacker can leverage these active tokens for unauthorized access. Always hash active authentication tokens (e.g., using SHA-256) before storing or verifying them in the database.
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.
The return value of 'px_cipher_encrypt' is ignored. Unchecked cipher encryption errors can lead to uninitialized buffer usage, emitting cleartext data or bypassing MDC checks.
A server-side OAuth2 configuration (`config.OAUTH2_CONFIG`) is assigned directly into a Jinja template render context (e.g., `page_props`) without filtering out secret fields. `OAUTH2_CONFIG` entries contain `OAUTH2_CLIENT_ID` and `OAUTH2_CLIENT_SECRET`, which will be embedded verbatim in the rendered HTML/JS of an unauthenticated page and disclosed to any v
Sensitive information such as tokens, passwords, or credentials was passed directly as a command-line argument. Command-line arguments are exposed system-wide via the process list (e.g., `/proc/[pid]/cmdline` or `ps`), allowing any local unprivileged user to observe the sensitive data. To remediate this, pass sensitive information via environment variables,
Persisting RKE FullState (PKI CertificatesBundle, EncryptionConfig, RancherKubernetesEngineConfig) into a Kubernetes ConfigMap named "full-cluster-state" in kube-system exposes the cluster CA private key, etcd encryption-at-rest keys, and credentials to any principal with ConfigMap read access (e.g. the built-in `view` ClusterRole). This allows privilege esc
The file has no special protections associated with it. Using .noFileProtection or FileProtectionType.none for file protection means that the file is not encrypted on disk, leaving it vulnerable to unauthorized access if the device is compromised or if the file is accessed outside of the app's sandbox. To enhance security, it's crucial to use appropriate fil