Rule Information
Tags
pythoncryptographyrc4arc4stream-cipherbroken-cryptoCWE-327OWASP-A02
CWE References
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset python/PYTHON-CRYPTO-SEC-001 --project .1
2
3
4
5
6
7
8
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
About This Rule
Understanding the vulnerability and how it is detected
This rule detects instantiation of the ARC4 (RC4) algorithm via the `cryptography` library's `cryptography.hazmat.primitives.ciphers.algorithms.ARC4` class. RC4 was once widely deployed in SSL/TLS, WEP, and WPA, but it has been cryptographically broken for over a decade.
RC4 produces a biased keystream: the first few bytes are strongly correlated with the key, and the output distribution is non-uniform across the full byte range. The BEAST, RC4NOMORE, and related attacks exploit these biases to recover plaintext from captured ciphertext. RFC 7465 explicitly prohibits RC4 in all versions of TLS, and NIST SP 800-131A disallows it for federal use.
The rule matches `CryptoCipherAlgorithms.method("ARC4")` — any call to the ARC4 constructor in the hazmat algorithms module. There is no safe configuration for RC4; the algorithm itself is the problem, regardless of key size.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Biased Keystream Enables Plaintext Recovery
RC4's keystream is statistically biased from the very first byte. Attackers who observe enough ciphertext encrypted under the same or related keys can statistically recover the plaintext. The RC4NOMORE attack demonstrated full HTTP cookie recovery in under 75 hours against a live HTTPS connection using only network traffic capture.
2
Prohibited in TLS by RFC 7465
RFC 7465 (2015) mandates that TLS implementations MUST NOT negotiate any RC4-based cipher suite. Code that uses RC4 in a network context directly violates this requirement and will fail compliance reviews for any system handling PCI DSS, HIPAA, or FedRAMP data.
3
No Authentication -- Ciphertext is Malleable
RC4 provides only stream confidentiality, with no built-in integrity or authentication. An attacker who can flip bits in the ciphertext will produce predictable, corresponding bit flips in the plaintext, enabling undetected message tampering without knowledge of the key.
4
Key Reuse Eliminates All Security
If the same RC4 key is ever reused across two messages, an attacker who XORs the two ciphertexts removes the keystream entirely. Both plaintexts can then be recovered using statistical analysis. WEP was broken at scale this way, and the same risk applies to any RC4-encrypted data at rest or in transit.
How to Fix
Recommended remediation steps
- 1Replace ARC4 with AES-256-GCM (AESGCM from cryptography.hazmat.primitives.ciphers.aead) for authenticated encryption
- 2Use ChaCha20-Poly1305 (ChaCha20Poly1305) as an alternative when AES hardware acceleration is unavailable
- 3Never reuse a key with any stream cipher -- generate a cryptographically random key per encryption operation
- 4Migrate any data previously encrypted with RC4 by decrypting and re-encrypting under AES-256-GCM with a new key
- 5Run this rule in CI to prevent RC4 from being reintroduced during future development or library upgrades
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule matches calls to the ARC4 constructor in the cryptography library's hazmat algorithms module via the QueryType pattern `CryptoCipherAlgorithms.method("ARC4")`. It fires whenever the ARC4 class is instantiated, regardless of key size or any surrounding wrapper logic. There is no safe configuration for RC4, so no sanitizer exclusions apply. The companion rule PYTHON-CRYPTO-SEC-001a covers the same algorithm in the PyCryptodome library.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
OWASP Top 10
A02:2021 - Cryptographic Failures
PCI DSS v4.0
Requirement 4.2.1 -- use strong cryptography for data protection
NIST SP 800-131A
Transitioning to approved algorithms -- RC4/DES/3DES disallowed
NIST SP 800-53
SC-13: Cryptographic Protection
RFC 7465
RC4 cipher suites are prohibited in all versions of TLS
References
External resources and documentation
Similar Rules
Explore related security rules for Python
HIGH
RC4 (ARC4) Cipher Usage via PyCryptodome
Detects use of the RC4 stream cipher through PyCryptodome's ARC4 module, which has known keystream biases and is prohibited by RFC 7465.
HIGH
Blowfish Cipher Usage via cryptography Library
Detects use of the Blowfish cipher through the cryptography library, which has a 64-bit block size making it vulnerable to Sweet32 birthday attacks after approximately 32GB of data.
HIGH
DES Cipher Usage via PyCryptodome
Detects use of single DES through PyCryptodome, which has only a 56-bit key that has been publicly brute-forceable since 1999 and is disallowed by FIPS 46-3 (withdrawn 2005).
Frequently Asked Questions
Common questions about RC4 (ARC4) Cipher Usage via cryptography Library
RC4 was widely deployed before researchers fully characterized its keystream
biases. The BEAST attack (2011), the RC4NOMORE attack (2015), and two decades
of academic analysis have conclusively shown that RC4's output is non-uniform
enough to recover plaintext from realistic traffic volumes. RFC 7465 formalized
the prohibition in 2015. Legacy deployment does not imply safety.
No. The weakness is in the keystream generation algorithm itself, not in how
the key is selected or derived. A random IV prevents identical keystreams across
sessions, but the per-byte biases in the RC4 output remain exploitable. The
correct fix is to replace the algorithm entirely -- use AES-GCM or
ChaCha20-Poly1305.
Decrypt all RC4-protected data using the existing key, then re-encrypt with
AES-256-GCM using a freshly generated 256-bit key. Securely destroy the old
RC4 key after migration. For data in transit (e.g., archived TLS sessions),
captured ciphertext cannot be retroactively fixed -- disable RC4 cipher suites
at the TLS negotiation layer and rotate session keys going forward.
No. The rule matches the ARC4 constructor call, not string literals or comments.
A variable named arc4_key or a comment explaining RC4's weaknesses will not
trigger a finding. Only actual instantiation of the ARC4 class fires.
PCI DSS QSAs flag RC4 as a violation of Requirement 4.2.1 during on-site
assessments. FedRAMP assessors treat it as a HIGH finding under NIST SP 800-53
SC-13. For TLS, external scanners will assign an F grade if RC4 cipher suites
are negotiable. Running this rule in CI provides auditable evidence that RC4
is not present in the codebase.
No. ChaCha20-Poly1305 is faster than RC4 on hardware without AES-NI instruction
support, and AES-GCM with AES-NI acceleration is faster still. The cryptography
library provides both via its AEAD primitives. There is no performance
justification for choosing RC4 on any modern platform.
New feature
Get these findings posted directly on your GitHub pull requests
The RC4 (ARC4) Cipher Usage via cryptography Library rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.