Rule Information
Tags
pythonpycryptodomexorxor-cipherno-encryptiontrivially-reversibleCWE-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-006 --project .1
2
3
4
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 calls to `Crypto.Cipher.XOR.new()` from the PyCryptodome library. The XOR cipher is not a cryptographic algorithm in any meaningful sense. It XORs the plaintext byte-by-byte with a repeating key. Recovering the plaintext requires only the key, and recovering the key requires only a known plaintext segment -- which is almost always available given the structured nature of most data formats.
A single-byte XOR key has only 256 possible values. Even a 32-byte key can be recovered through frequency analysis if sufficient ciphertext is available. Unlike the one-time pad (which requires a truly random key as long as the message and never reused), the XOR cipher in PyCryptodome operates with an arbitrary, typically short, reused key -- providing essentially no security.
PyCryptodome includes XOR for educational purposes and for use as a building block in custom cipher construction, not for data protection. The rule matches `PyCryptoCipherXOR.method("new")`. Any use of XOR for protecting real data should be replaced with AES-GCM immediately.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Known-Plaintext Immediately Recovers the Key
If an attacker knows any segment of the plaintext -- which is trivial for structured data like JSON, HTTP headers, file format magic bytes, or XML -- XORing the known plaintext with the corresponding ciphertext directly reveals the key bytes for that segment. If the key is shorter than the message (which it always is with repeating XOR), the entire key can be recovered from a small known-plaintext window.
2
Frequency Analysis Recovers Key Without Known Plaintext
For natural language or structured data, statistical frequency analysis (the same technique used to break Vigenere ciphers) can recover the XOR key without any known plaintext. The attacker only needs sufficient ciphertext. This attack runs in seconds with publicly available tools against any multi-byte XOR key used to encrypt realistic data.
3
No Authentication or Integrity Protection
XOR provides no integrity checking whatsoever. An attacker who knows the plaintext structure (which is typically easy to infer) can flip any bit in the ciphertext and produce a predictable change in the decrypted output. This enables undetected message forgery and data manipulation.
4
Provides Only Obfuscation, Not Encryption
Using XOR creates a false sense of security. Data "encrypted" with XOR will pass casual inspection but provides no protection against any technical adversary. Code that uses XOR to protect sensitive data has effectively no access control on that data -- it is equivalent to storing it in plaintext from a security perspective.
How to Fix
Recommended remediation steps
- 1Replace Crypto.Cipher.XOR with AES in GCM mode (AES.new(key, AES.MODE_GCM)) for actual encryption
- 2Use ChaCha20-Poly1305 via the cryptography library as an alternative authenticated cipher
- 3If data obfuscation is the only goal (e.g., obscuring values in memory temporarily), use a proper cryptographic primitive rather than XOR
- 4Treat any data previously protected only with XOR as if it were stored in plaintext and assess exposure accordingly
- 5For performance-sensitive use cases where XOR seems attractive, AES-GCM with AES-NI hardware acceleration is both faster and cryptographically sound
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule matches calls to `Crypto.Cipher.XOR.new()` in PyCryptodome via the QueryType pattern `PyCryptoCipherXOR.method("new")`. It fires on any XOR cipher object instantiation regardless of key length or context. There is no safe use of the XOR cipher for data protection. No sanitizer exclusions apply. This rule has no companion rule in the `cryptography` library as that library does not expose an XOR cipher primitive.
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
References
External resources and documentation
Similar Rules
Explore related security rules for Python
HIGH
RC4 (ARC4) Cipher Usage via cryptography Library
Detects use of the RC4 stream cipher through the cryptography library's ARC4 algorithm, which has known keystream biases and is prohibited by RFC 7465.
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
RC2 (ARC2) Cipher Usage via PyCryptodome
Detects use of the RC2/ARC2 cipher through PyCryptodome, which has a weak key schedule and an effective key length that can be reduced to 40 bits by protocol negotiation, making it vulnerable to brute-force attacks.
Frequently Asked Questions
Common questions about XOR Cipher Usage via PyCryptodome
Yes, for two reasons. First, any attacker with access to the process memory or
a memory dump can recover the key and plaintext trivially. Second, code reviewers
and auditors will flag XOR as non-compliant regardless of the intended use case.
If you need to protect configuration values in memory, use OS-level secrets
management (environment variables, secrets managers, keychain APIs) rather than
application-layer obfuscation. XOR provides no meaningful protection.
RC4 generates a pseudorandom keystream using a complex internal state machine
before XORing with the plaintext. The security of RC4 relies on the difficulty
of predicting or distinguishing that keystream from random. PyCryptodome's XOR
cipher simply repeats the literal key bytes in a cycle -- there is no
pseudorandom generation, no security margin, and no key expansion. RC4 is a
broken cipher; XOR is not a cipher at all.
PyCryptodome documents XOR as a tool for building and testing custom ciphers,
not for protecting data. The only production-adjacent use case is operating
as a component inside a larger, carefully designed cipher construction --
and even then, the design must be reviewed by a cryptographer. Any use of
XOR to protect sensitive data at rest or in transit is inappropriate.
For a single-byte key: instantly, by trying all 256 values. For a multi-byte
repeating key: within seconds using the Kasiski examination or Index of
Coincidence method to determine key length, followed by frequency analysis on
each key-length-offset position. Automated tools available online will break
most XOR-obfuscated data without any manual cryptanalysis. The data should be
treated as plaintext.
Extremely urgent. Deployment secrets (API keys, database credentials, signing
keys) protected only with XOR are functionally unprotected. Any developer with
access to the config file and knowledge of one expected value (such as a
known API key prefix) can recover the XOR key and decrypt all other secrets
in seconds. Replace with a proper secrets manager (HashiCorp Vault, AWS Secrets
Manager, GCP Secret Manager) and rotate all secrets immediately.
This rule specifically matches `Crypto.Cipher.XOR.new()` via PyCryptodome.
It does not flag general use of the ^ bitwise XOR operator in Python code.
Other rules cover hardcoded secrets and insecure key derivation patterns,
but this specific rule targets the XOR cipher primitive in PyCryptodome.
New feature
Get these findings posted directly on your GitHub pull requests
The XOR Cipher Usage via PyCryptodome rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.