ECB Mode Usage (cryptography lib)

HIGH

ECB mode is deterministic and leaks plaintext patterns. Use AES-GCM or AES-CTR+HMAC instead.

Rule Information

Language
Python
Category
Cryptography
Author
Shivasurya
Shivasurya
Last Updated
2026-03-22
Tags
pythoncryptographyecbcipher-modeweak-modeCWE-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-030 --project .
1
2
3
4
5
6
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

Detects usage of ECB (Electronic Codebook) mode via `modes.ECB()` from the `cryptography` library. ECB is the simplest block cipher mode and is fundamentally insecure for any practical use: it encrypts each block of plaintext independently, so identical plaintext blocks always produce identical ciphertext blocks under the same key. This deterministic property means ECB encryption preserves patterns in the plaintext and provides no semantic security. The "ECB penguin" is the canonical demonstration: encrypting a bitmap image with ECB mode produces a ciphertext image where the penguin outline is still clearly visible, despite using AES (a strong cipher). ECB provides no protection against chosen-plaintext attacks and allows partial plaintext recovery through pattern analysis. ECB also provides no ciphertext integrity or authentication, making it vulnerable to arbitrary block substitution without detection. This is a hard vulnerability rule, not an audit rule. There is no legitimate use of ECB mode for encrypting non-trivial data — replace it with AES-GCM (confidentiality + authentication in one primitive) or AES-CTR with HMAC (Encrypt-then-MAC).

How to Fix

Recommended remediation steps

  • 1Replace `modes.ECB()` with `AESGCM` from `cryptography.hazmat.primitives.ciphers.aead` — it provides authenticated encryption (confidentiality + integrity) in a single API.
  • 2If you need unauthenticated stream encryption, use `modes.CTR()` and add a separate HMAC over the ciphertext (Encrypt-then-MAC pattern). Never decrypt before verifying the MAC.
  • 3For PyCryptodome callers, use `AES.new(key, AES.MODE_GCM)` and call `encrypt_and_digest()` to get both ciphertext and authentication tag.
  • 4Never use ECB mode for any real data — even a single block. Databases, file encryption, key wrapping, and token generation that use ECB are all vulnerable.

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; ECB is not considered strong cryptography
NIST SP 800-131A
Minimum 2048-bit RSA/DSA keys; guidance covers algorithm and mode selection
NIST SP 800-57
Key Management -- minimum key strengths for security levels
NIST SP 800-53
SC-13: Cryptographic Protection -- use FIPS-approved algorithms and modes

References

External resources and documentation

Similar Rules

Explore related security rules for Python

Frequently Asked Questions

Common questions about ECB Mode Usage (cryptography lib)

AES is a secure block cipher — it provides a strong pseudorandom permutation for each 128-bit block in isolation. ECB mode applies AES independently to each block with no interaction between blocks. This means two identical 16-byte plaintext blocks encrypted with the same key always produce identical ciphertext blocks. An attacker can detect block repetitions, infer structure, and partially recover plaintext through pattern analysis — all without breaking AES itself. The mode is the vulnerability, not the cipher.
ECB is safe only for encrypting a single block of truly random data (e.g., wrapping a random AES key). For any structured data, multi-block data, or data containing attacker- influenced values, ECB is insecure. In practice, the only correct answer is to replace ECB with GCM or CTR+HMAC — there is no scenario where you should choose ECB for new code.
No. ECB provides only confidentiality (and weak confidentiality at that). An attacker can rearrange, replace, or duplicate ciphertext blocks without any detection. This enables block substitution attacks where an attacker can swap encrypted records or replay encrypted tokens without knowing the key.
Yes — CBC adds an XOR with the previous ciphertext block (chaining), which breaks the identical-block pattern leakage. However, CBC without a MAC is still vulnerable to padding oracle attacks (POODLE, Lucky13) and ciphertext manipulation. See SEC-031 for audit coverage of unauthenticated CBC usage.
The ECB penguin is a famous demonstration where the Linux mascot (Tux) is encrypted with AES-ECB. The resulting ciphertext, when rendered as an image, still clearly shows the penguin outline because identical blocks of pixels produce identical encrypted blocks. The original image by Philip Levis and adapted as a cryptography teaching tool makes the vulnerability immediately intuitive.
Yes. Notable examples include Adobe's 2013 password database breach (150M+ accounts encrypted with 3DES-ECB, allowing password frequency analysis from ciphertext alone) and numerous token-based authentication systems where ECB-encrypted session tokens allowed forging of privileged session identifiers.

New feature

Get these findings posted directly on your GitHub pull requests

The ECB Mode Usage (cryptography lib) rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.

See how it works