How Padding Oracle Attacks Work

Introduction

In 2014, Google researchers discovered that a nine-year-old protocol — SSL 3.0 — could be exploited to decrypt HTTPS session cookies in roughly 256 requests. The attack, named POODLE (CVE-2014-3566), did not break AES. It did not steal encryption keys. It exploited something far simpler: the fact that a server would tell you, through its error messages, whether the bytes at the end of a decrypted message formed valid padding. That single bit of feedback — valid or invalid padding — was enough to recover plaintext one byte at a time. It is a padding oracle attack, and POODLE was far from the last example. LUCKY13 in 2013 demonstrated a timing-based variant. CBC cipher suites remained in widespread use for years after both disclosures, partly because the fix required replacing an entire mode of operation, not patching a single line of code.

A padding oracle attack exploits a class of cryptographic errors that arise when a system decrypts ciphertext before verifying its integrity. When a block cipher like AES operates in CBC (Cipher Block Chaining) mode, it requires plaintext to be a multiple of 16 bytes — the block size. Data is padded to reach that multiple using a scheme called PKCS#7, and after decryption, the padding is checked and removed. If an attacker can cause the system to attempt decryption on modified ciphertext and observe whether the padding was valid, they have an oracle — an information source they can query systematically to recover the original plaintext without ever learning the key.

Understanding padding oracle attacks matters for two reasons. First, AES-CBC is still deployed in legacy systems, VPNs, and encrypted storage formats — knowing the attack helps you assess the risk in your environment. Second, the defense — authenticated encryption — is the design principle that modern cryptography is built on, and understanding what it replaces reveals why AES-GCM, ChaCha20-Poly1305, and similar AEAD constructions exist. Our explainer on AES-256-GCM covers the authentication mechanism that makes GCM immune to this class of attack.

What Is Padding in Block Cipher Modes?

Block ciphers like AES encrypt fixed-size chunks of data — 16 bytes for AES. When your plaintext is not a perfect multiple of 16 bytes, a padding scheme adds extra bytes to bring it up to size. The most common scheme, PKCS#7, fills the remaining bytes with a value equal to the number of padding bytes added. If 3 bytes of padding are needed, the last three bytes of the padded plaintext are all 0x03. If 1 byte is needed, the last byte is 0x01. A full block of padding (16 bytes) is added if the plaintext already ends on a block boundary, to signal that all 16 bytes of the last block are padding.

When decryption occurs, the receiving system reads the last byte of the decrypted block to determine how many padding bytes to expect, then verifies that all those bytes have the correct value. If they do not — for example, the last byte claims 5 bytes of padding but those 5 bytes are not all 0x05 — decryption fails with a padding error.

This error distinction — valid padding vs. invalid padding — is the oracle. Any system that behaves differently based on whether padding is valid is leaking information about the decrypted plaintext, regardless of whether that difference manifests as an explicit error message, a different HTTP response code, or a measurable timing difference.

How Padding Oracle Attacks Work

Understanding this attack requires understanding how CBC decryption works at the byte level. In CBC mode, each ciphertext block is XOR’d with the previous ciphertext block after decryption to produce the plaintext. This means that modifying bytes in one ciphertext block changes the corresponding plaintext bytes of the next block in a predictable, controllable way.

Here is the attack mechanism, step by step:

Step 1: Identify the oracle. The attacker needs a target that accepts ciphertext and reveals whether decryption produced valid padding. This could be a web application returning a 500 error on padding failure and a 200 on success, a TLS server returning different alert codes, or a system with measurable timing differences between the two outcomes.

Step 2: Isolate one ciphertext block. The attacker takes a ciphertext block and the block immediately before it (the IV block for the first block). Call the target block C₂ and the preceding block C₁.

Step 3: Modify C₁ to probe the last byte. The attacker modifies the last byte of C₁, sending the modified ciphertext to the oracle. Since modifying C₁’s last byte changes C₂’s last decrypted byte via the XOR operation, the attacker cycles through all 256 possible values. Eventually, one value causes the decrypted last byte to equal 0x01 — valid single-byte PKCS#7 padding. The oracle accepts it.

Step 4: Calculate the original plaintext byte. From the value of C₁’s last byte that produced valid padding and the known XOR relationship, the attacker can calculate what the intermediate decrypted value is, and from that, the original plaintext byte. This single byte has been recovered without the key.

Step 5: Repeat for all remaining bytes. The attacker continues this process, targeting successive bytes from right to left within each block, then repeating for all blocks. Each byte requires at most 256 oracle queries. A 16-byte block requires at most 4,096 queries. For a 256-byte ciphertext, full decryption requires fewer than 65,536 queries — feasible in minutes over a network.

The attack’s elegance is that it makes no assumption about the encryption key and does not attempt to factor any large number. It purely exploits the malleability of CBC ciphertext and the system’s error feedback.

VIDEO · READY 16:9

PLAY

Padding Oracle Attack

Padding Oracle Attacks vs. Authenticated Encryption

This table compares the relevant design dimensions between CBC mode (vulnerable) and AEAD modes (immune).

The critical insight in the middle column is “if MAC verified first.” The Cryptographic Doom Principle — articulated by cryptographer Moxie Marlinspike — states that any system performing cryptographic operations on attacker-controlled data before verifying authenticity is doomed to be exploited. Encrypt-then-MAC is safe because the MAC is verified before any decryption attempt; MAC-then-Encrypt, used in older TLS versions, is vulnerable because decryption happens before MAC verification, creating the oracle window.

Real-World Use Cases

POODLE and TLS downgrade attacks. CVE-2014-3566 demonstrated that even if a server supports modern TLS, an active man-in-the-middle attacker can force a downgrade to SSL 3.0 by injecting errors into the TLS handshake negotiation until the client falls back to a legacy protocol. Once on SSL 3.0, the attacker exploits the padding oracle in SSL 3.0’s CBC handling to decrypt session cookies from each HTTPS request. The fix required servers to disable SSL 3.0 entirely and implement TLS_FALLBACK_SCSV (RFC 7507) to prevent protocol downgrade. Understanding how this interacts with the broader TLS handshake protocol explains why TLS 1.3 removed all non-AEAD cipher suites.

Web application encrypted cookies and tokens. Many web frameworks historically stored encrypted session data in client-side cookies using AES-CBC — the Java Encrypted Session and Ruby on Rails’ older cookie encryption are examples. When the framework’s error handling revealed padding validity through its response behavior, the entire session store was vulnerable. Tools like padbuster automated the attack, making cookie decryption trivial for any target system that leaked padding information. OWASP documents this as a standard vulnerability category and recommends authenticated encryption for all token storage.

Encrypted storage format vulnerabilities. Older versions of LUKS (Linux Unified Key Setup) for disk encryption and some backup tools used AES-CBC without authentication. While these formats do not typically provide the attacker real-time oracle feedback, any system that logs, displays, or otherwise reacts differently to corrupted vs. valid decrypted data creates an offline oracle. The full disk encryption article covers how modern LUKS2 uses AEAD to eliminate this risk.

Common Mistakes to Avoid

Exposing different error messages for padding vs. decryption failures. Even subtle behavioral differences create oracles. Your application should return the same generic error, with the same latency, regardless of whether decryption failed due to a bad key, corrupted ciphertext, or invalid padding. “Constant-time” error handling — where the code path always takes the same amount of time regardless of the failure reason — is essential.

Using AES-CBC without a MAC. CBC mode provides no integrity guarantee. Any new system should use AES-GCM or ChaCha20-Poly1305 for symmetric encryption. If you are maintaining legacy code that uses AES-CBC, you must add a MAC, ordered as Encrypt-then-MAC, and you must verify the MAC before any decryption attempt occurs. See our ChaCha20-Poly1305 explainer for details on the stream-cipher AEAD alternative.

Trusting the protocol to protect legacy cipher suites. TLS 1.2 supports AEAD cipher suites, but it also supports dozens of CBC cipher suites with varying MAC constructions. If your server still offers CBC cipher suites for TLS 1.2 backward compatibility, any client that negotiates them is vulnerable to LUCKY13-style timing attacks. Audit your cipher suite configuration with a tool like SSL Labs and disable all CBC cipher suites if your clients support AEAD. LUCKY13 is itself a timing-based side-channel attack — the same class of implementation-level exploit covered in depth in Side-Channel Attacks Explained, which details how attackers extract secrets from timing differences, power traces, and CPU cache behavior.

Leaving SSL 3.0 or TLS 1.0 enabled on legacy endpoints. Even if you have deployed TLS 1.3 on your primary endpoints, a forgotten load balancer or legacy administrative interface running SSL 3.0 is vulnerable. Include all endpoints — not just public-facing web servers — in your TLS audit scope.

Getting Started

Migrate to AES-GCM or ChaCha20-Poly1305 for all new encryption. Both are AEAD modes: they compute an authentication tag that must be verified before decryption proceeds, eliminating the padding oracle window entirely. Neither mode uses padding — they operate in counter mode internally. The authentication tag verification failure is indistinguishable from any other decryption failure, providing no oracle feedback to an attacker. Review our AES-256-GCM guide for the specifics of GCM authentication and nonce management.

Audit all TLS endpoints for CBC cipher suite support. Use SSL Labs Server Test or testssl.sh to scan your public-facing endpoints. Look specifically for cipher suites with “CBC” in the name — these should be disabled. Your configuration should offer only ECDHE-based AEAD cipher suites: AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305. Disable TLS 1.0 and 1.1 entirely; they mandate CBC support.

Review all encrypted session storage for authenticated encryption. Scan your application codebase and framework documentation for any use of AES-CBC, AES-ECB, or other non-AEAD modes for storing session tokens, encrypted cookies, or application-level encrypted fields. Replace each use with an AEAD primitive. For applications using the tokenization vs encryption trade-off, understand that tokenization sidesteps this problem entirely by replacing sensitive values rather than encrypting them.

Test for padding oracle vulnerabilities in existing systems. Tools like padbuster and the padding-oracle-attacker Python library allow you to test whether a system leaks padding information. Run these against any legacy endpoint using CBC encryption before decommissioning or before deciding to leave it in service. A system that leaks padding information should be treated as a critical finding, not a medium-severity informational issue.