The ecb mode weakness is the oldest and most visual mistake in block cipher usage. ECB encrypts every block of plaintext on its own, with no chaining and no IV, so two identical plaintext blocks always produce the same ciphertext block. That single fact leaks the structure of your data and lets an attacker rearrange or splice ciphertext to forge fields they were never meant to set. This post shows what leaks, how cut and paste forgery works, and why the fix is to stop using ECB.
How ECB encrypts
ECB stands for Electronic Code Book. The name is literal: it treats the cipher like a lookup table. Split the plaintext into blocks, encrypt each block independently under the key, concatenate the results.
C[0] = E(key, P[0]) C[1] = E(key, P[1]) C[2] = E(key, P[2])
There is no IV and no dependence between blocks. Compare that to CBC, which chains each block into the next. In ECB the same plaintext block always maps to the same ciphertext block, every time, across every message under that key. That determinism is the root of the whole problem.
The ecb mode weakness you can see
The famous demonstration is an image. Encrypt a bitmap of a simple shape with ECB, and the outline is still visible in the ciphertext. Flat regions of one color are blocks of identical plaintext, so they become blocks of identical ciphertext, and the pattern survives encryption. The pixels are scrambled but the shape is not hidden. ECB encrypts the values, never the relationships between them.
The same leak applies to any structured data, not just images. A record with repeated fields, a protocol with fixed headers, a database column with a small set of values: wherever plaintext blocks repeat, ECB advertises it. An observer can count distinct values, spot repeated commands, and map the shape of data they cannot read.
ECB keeps every repetition in your plaintext perfectly intact. It hides the bytes and publishes the pattern, which for structured data is often the part you needed to protect.
Cut and paste forgery
Leaking structure is the passive half. The active half is that ECB blocks are position independent, so an attacker can move them around. A ciphertext block that decrypts to some value decrypts to that same value no matter where you place it. That turns encrypted blocks into interchangeable tiles.
Take a SaaS app called Acme Notes that issues a session token whose plaintext is field aligned to 16 byte blocks:
block 0: email=bob@ac.me& block 1: role=user;id=042
Now suppose the attacker can register an account and control part of the plaintext, for example their email address. They register an address padded so that one full block of their own token is exactly:
role=admin;id=09
ECB encrypts that block the same way it would in any token, so the attacker captures its ciphertext. Then they take their ordinary session token and swap their real role block for the captured role=admin block. The server decrypts the spliced token block by block, with no chaining to notice the seam, and reads a valid admin role. No key was broken. The attacker assembled a forged plaintext out of legitimately encrypted tiles.
This is the same class of trust failure as a cbc bit flipping attack, where an attacker edits decrypted data without the key, and it rhymes with a predictable iv attack, where missing randomness lets equal plaintext leak through equal ciphertext. All three come from using a cipher without asking whether the output can be tampered with or reassembled. You can browse more of these basics on our blog, and the wider set lives in our cryptographic oracle attacks hub.
How to fix it
There is no safe tuning of ECB for general data. The fix is to replace it.
- Never use ECB for anything with structure. That means almost everything: tokens, records, messages, files. The only time identical plaintext blocks are not a leak is when your data is a single block or is already uniformly random, which is rare and easy to get wrong.
- Use an authenticated mode. AES GCM or ChaCha20 Poly1305 give you a fresh nonce per message, so identical plaintext no longer maps to identical ciphertext, and an authentication tag, so a spliced or reordered ciphertext is rejected before it is ever decrypted. That kills both the structure leak and the cut and paste forgery in one move.
- If you only need confidentiality, still authenticate. Even a randomized mode like CBC with a good IV is open to tampering without a MAC. Pairing encryption with integrity is the baseline, not an extra.
- Bind context into the authentication. Include the record type, the user, or the message position in the associated data, so a block or message cannot be lifted from one context and replayed in another.
- Reach for a library default. A modern crypto library hands you an authenticated mode by default and makes ECB the awkward, clearly labeled option. Take the default.
Notice the pattern one more time. AES is not weak. ECB is a correct, well specified mode that does exactly what it says. The weakness is the assumption that encrypting each block is the same as protecting the data, when in fact ECB preserves every repetition and lets blocks be shuffled freely. Code review misses it because the encrypt call looks ordinary on its line.
Catching this means reasoning about how an application builds a ciphertext, whether equal inputs can produce equal outputs, and whether anyone ever verifies that the blocks arrived in one piece. That assumption testing is exactly what an autonomous researcher is built to do. Read more on our about page.
Frequently asked questions
What is the ECB mode weakness?
ECB encrypts each block of plaintext independently, with no IV and no chaining, so two identical plaintext blocks always produce the same ciphertext block under a given key. That determinism leaks the structure of the data, the reason the encrypted image of a simple shape still shows its outline, and it lets an attacker rearrange or splice ciphertext blocks because each block decrypts to the same value wherever it is placed.
Why does the ECB penguin image still show the picture?
Flat regions of one color are long runs of identical plaintext blocks. ECB maps each identical block to the same ciphertext block, so those runs stay identical after encryption and the outline survives. ECB hides the byte values but keeps every repetition, and for images the repetition is the shape.
What is cut and paste forgery in ECB?
Because ECB blocks are position independent, a ciphertext block that decrypts to a value keeps that value anywhere you put it. An attacker who can influence part of the plaintext can make the system encrypt a block they want, such as one reading role=admin, then splice that captured ciphertext block into another token in place of the real role block. The server decrypts it with no chaining to catch the seam and trusts the forged field.
How do you fix the ECB mode weakness?
Stop using ECB for any data with structure, which is almost all data. Use an authenticated mode such as AES GCM or ChaCha20 Poly1305, which adds a fresh nonce so identical plaintext no longer maps to identical ciphertext, and an authentication tag so a spliced or reordered ciphertext is rejected before decryption. Bind context into the associated data so blocks cannot be replayed across messages.
Put an autonomous researcher on your own systems
UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.