Most developers learn a hard lesson at some point in their careers: just because data is encrypted doesn't mean it’s safe from tampering.

It’s an easy trap to fall into. If an attacker doesn't have the secret key, they can't read the data. And if they can't read it, how could they possibly modify it to do something malicious?

But cryptography is unforgiving, and it treats secrecy and integrity as two entirely separate jobs. This exact misunderstanding is what makes the CBC (Cipher Block Chaining) Bit Flipping attack possible.

Here is a look at how an attacker can manipulate encrypted data without ever knowing the secret key.

The Problem with Chaining Blocks

To understand the attack, you have to look at how CBC mode actually processes data.

When you use AES, it doesn't encrypt your file as one massive chunk. Instead, it chops the data into 16-byte blocks. In CBC mode, these blocks are cryptographically chained together to hide patterns. The encrypted output of the first block gets mathematically mixed into the plaintext of the second block before it gets encrypted, and so on down the line.

It’s a clever way to keep data confidential. But it introduces a structural quirk during decryption.

When a server receives the data and decrypts it, the process works in reverse. To figure out the original plaintext of Block 2, the server decrypts it, and then combines it with the encrypted ciphertext of Block 1.

Because the previous encrypted block dictates the final output of the next block, attackers have a way in.

Blind Tampering

An attacker intercepts your encrypted traffic. They don't have the key, so it just looks like gibberish to them. But they know you are using CBC mode.

The attacker intentionally alters a few bits in the ciphertext of Block 1 and sends the traffic along to your server.

When your server decrypts the data, it processes the attacker's scrambled Block 1. Because of how the chain works, that blind alteration in Block 1 cascades directly into the math for Block 2.

The attacker doesn't need to read the message. By simply flipping bits in the encrypted text, they can systematically manipulate the decrypted text that your application ultimately processes.

The Session Cookie Exploit

To see why this is dangerous, look at how older web apps handled session management.

Developers used to store user state in encrypted cookies, assuming the encryption made them tamper-proof. A cookie might secretly contain a string like this:

userid=994;role=user;

An attacker logs in, gets their encrypted cookie, and intercepts it. They run a script to methodically flip bits in the ciphertext, sending thousands of requests back to the server until the server accepts one that gives them elevated access.

Because the server only checks if the data decrypts—and doesn't verify if it was tampered with—it blindly processes the attacker's modified data. Suddenly, that decrypted string looks like this:

userid=994;role=admi;

The attacker just escalated their privileges without ever reading the cookie or knowing the encryption key.

The Fix: Don't Just Encrypt, Authenticate

The underlying flaw here isn't necessarily CBC mode itself; it’s the assumption that encryption guarantees integrity.

• Confidentiality keeps attackers from reading data.
• Integrity keeps attackers from altering data.

Modern cryptography solves this by bundling both together. Today, the standard approach is to use Authenticated Encryption, with AES-GCM being the most common default.

Unlike traditional CBC, AES-GCM generates a cryptographic tag—essentially a tamper-evident seal—alongside the ciphertext. When the server receives the data, it checks the seal first. If a single bit has been flipped in transit, the seal breaks, the math fails, and the server drops the data entirely before it even tries to process it.

If you are forced to use CBC mode, the defense is an Encrypt-then-MAC architecture. You encrypt the data, generate a unique authentication code (MAC) for that specific ciphertext, and verify it on the receiving end before decryption starts.

The takeaway is simple: secret data isn't automatically trustworthy data. If your system relies on encrypted data to make decisions, you have to prove it hasn't been altered before you use it.