Padding oracle

What it means

Some encryption modes, notably CBC, pad the last block of data to a fixed size. When your application decrypts a value and finds the padding wrong, it may return a different error, or take a different time, than for other failures. That difference is the oracle.

An attacker who can submit altered ciphertext and see whether the padding was accepted learns one byte at a time. With enough requests they can decrypt the whole value, and in some cases build a valid one of their own.

Why it matters

The target is usually a value you thought was sealed: an encrypted cookie, a hidden form field, a reset token, an encrypted URL parameter. If it can be decrypted, it can be read. If it can be forged, it can carry a different user id or role.

The best-known case, Vaudenay's 2002 attack, broke real products for years afterwards. The lesson holds today: any difference in how a decryption failure is handled can become an exploit path, even when nobody sees the key.

How it shows up

You meet it in apps that encrypt data themselves, in older framework versions, and in custom token or cookie schemes using AES-CBC with no integrity check. The telltale is two different outcomes for bad padding and for a bad value, such as a 500 error against a plain rejection.

The fix is to use authenticated encryption so tampered data is refused before decryption, and to return one identical error for every failure. Also check that you do not trust encrypted client-side values for anything that matters.