Unauthenticated Cipher Mode Audit (cryptography lib)

MEDIUM

CBC/CTR/CFB/OFB mode detected — these modes provide confidentiality but NOT authentication. Verify HMAC is applied or migrate to GCM.

Rule Information

Language
Python
Category
Cryptography
Author
Shivasurya
Shivasurya
Last Updated
2026-03-22
Tags
pythoncryptographycipher-modeunauthenticatedcbcctrcfbofbCWE-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-031 --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

Audit rule that flags usage of CBC, CTR, CFB, and OFB cipher modes from the `cryptography` library via `modes.CBC()`, `modes.CTR()`, `modes.CFB()`, and `modes.OFB()`. These modes provide confidentiality but do NOT provide ciphertext authentication or integrity protection. Without a separate message authentication code (MAC), an attacker who can observe or manipulate ciphertext can mount padding oracle attacks (CBC), bit-flipping attacks (CTR/CFB/OFB), or replay attacks — all without knowing the encryption key. This is an audit rule, not a hard vulnerability rule. CBC with a correct Encrypt-then-MAC construction using HMAC-SHA256 is cryptographically sound, but the analysis engine cannot currently detect whether an HMAC is applied to the ciphertext after encryption. Therefore all four modes are flagged for manual review. False positives are expected for code that correctly combines these modes with HMAC — the recommended action is to verify the HMAC is present and suppress the finding if the implementation is correct. For new code, the simplest correct choice is AES-GCM via `AESGCM` from `cryptography.hazmat.primitives.ciphers.aead` — it provides both confidentiality and authentication in a single primitive with no risk of HMAC omission.

How to Fix

Recommended remediation steps

  • 1Migrate to `AESGCM` from `cryptography.hazmat.primitives.ciphers.aead` for new code — it provides authenticated encryption with no risk of forgetting the MAC.
  • 2If CBC is required (e.g., for protocol compatibility), use Encrypt-then-MAC with HMAC-SHA256. Always verify the MAC before decrypting — never decrypt-then-verify.
  • 3For CTR/CFB/OFB modes, add an HMAC over (nonce || ciphertext) before transmitting. Verify the HMAC on receipt before decryption.
  • 4Consider ChaCha20Poly1305 as an alternative AEAD if AES hardware acceleration is unavailable.
  • 5Do not use CBC for TLS-like record protocols — use TLS 1.3 which mandates AEAD-only cipher suites.

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; unauthenticated modes require additional MAC
NIST SP 800-131A
Minimum 2048-bit RSA/DSA keys; mode selection guidance covered by SP 800-38 series
NIST SP 800-57
Key Management -- key usage and algorithm selection for confidentiality and integrity
NIST SP 800-53
SC-13: Cryptographic Protection -- use FIPS-approved algorithms with appropriate modes

References

External resources and documentation

Similar Rules

Explore related security rules for Python

Frequently Asked Questions

Common questions about Unauthenticated Cipher Mode Audit (cryptography lib)

Yes — CBC used with Encrypt-then-MAC (ETM) where HMAC-SHA256 covers the IV and ciphertext is cryptographically sound. The critical requirements are: (1) use Encrypt-THEN-MAC, not MAC-then-Encrypt; (2) verify the MAC before performing any decryption; (3) use separate keys for encryption and MAC. The analysis engine flags CBC because it cannot detect whether HMAC is correctly applied, not because CBC+HMAC is inherently broken.
In CBC mode, decryption of each block depends on the previous ciphertext block via XOR. If a decryption endpoint reveals whether padding is valid (through different error messages, timing differences, or exceptions), an attacker can perform a byte-by-byte oracle attack to decrypt any ciphertext block without the key. Famous examples include POODLE (CVE-2014-3566) and Lucky13. Using Encrypt-then-MAC and rejecting invalid MACs before any decryption eliminates this attack surface.
CTR, CFB, and OFB modes produce keystream that is XORed with plaintext. An attacker who can modify a specific bit in the ciphertext will flip the corresponding bit in the decrypted plaintext in a predictable way — without knowing the key. Without a MAC, an attacker can modify ciphertext to produce controlled plaintext changes at known positions (e.g., flipping an "admin=false" flag to "admin=true" in an encrypted cookie).
CTR mode itself provides good confidentiality. The flag is not about CTR being broken but about CTR lacking authentication. If an application uses CTR mode without HMAC, it is vulnerable to bit-flipping attacks on decrypted data. The rule flags CTR as an audit checkpoint to confirm HMAC is present. CTR+HMAC is a valid construction.
All four modes (CBC, CTR, CFB, OFB) share the property of providing confidentiality without authentication. While CBC is also vulnerable to padding oracle attacks (an additional risk CTR avoids), both families require separate MAC protection. A single audit rule covering all four avoids missing any unauthenticated mode usage.
For new applications use AES-GCM via AESGCM — it is simpler (no separate MAC key, no risk of incorrect ETM ordering), hardware-accelerated on modern CPUs (AES-NI + PCLMULQDQ), and the standard choice in TLS 1.3, modern SSH, and cloud cryptography APIs. CBC+HMAC is acceptable when protocol compatibility requires it but introduces implementation complexity that GCM avoids.
Encrypt-then-MAC (ETM) applies HMAC to the ciphertext after encryption — the MAC covers the ciphertext and IV. Verification rejects tampered ciphertext before any decryption occurs, eliminating padding oracle attack surface. MAC-then-Encrypt applies HMAC to plaintext before encryption — the MAC is then encrypted. Verification requires decryption first, which re-exposes padding oracle vulnerabilities. Always use Encrypt-then-MAC.

New feature

Get these findings posted directly on your GitHub pull requests

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

See how it works