Fuzzing

Every program expects input: a file, a number, text from a form. Normally, a program is tested with input that makes sense. Fuzzing does the opposite. A testing tool automatically generates vast amounts of input that is broken, absurd, or random. It throws these at the program and observes what happens. If the program crashes or behaves strangely, a vulnerability has been found. The name comes from the English word “fuzz,” meaning something like noise or blur.

Why random junk finds real security holes

Humans test software the way they imagine it being used. They enter a valid date, a plausible image file, a normal name. That is precisely why they overlook the cases nobody thinks of. An attacker, however, thinks of exactly that. He sends an image whose size field in the file header is falsified, or a name with 50,000 characters.

Many of the most dangerous security vulnerabilities arise from such unexpected input. A well-known pattern is the buffer overflow: the program reserves space for 100 characters but receives 5,000, overwriting memory that doesn’t belong to it. In the best case, it merely crashes. In the worst case, an attacker can inject their own code and take over the machine.

That is why fuzzing has become standard practice in large software projects today. Google has been running a program called OSS-Fuzz for years, which continuously tests open-source software. It has already found over ten thousand bugs in projects such as browsers, image libraries, and encryption software. No team of humans could perform this volume of testing by hand.

From blind guessing to targeted mutation

The simplest form is pure randomness: the tool rolls together random bytes and sends them off. This works poorly because most inputs fail at the very first check. An image viewer discards garbage data immediately, without ever reaching the interesting parts of the code. The same few lines end up being tested over and over.

Modern fuzzers therefore work in a mutation-based way. They start with real, valid sample files and change only small things about them: flip a byte, double a number, delete a chunk. This keeps the input close enough to what’s allowed to get deep into the program, while still being wrong enough to throw it off balance.

The most important trick is called coverage feedback. The fuzzer measures which lines of the program an input has actually reached. Inputs that trigger new, previously untouched spots in the code are kept and mutated further. The rest are discarded. This way, the tool gradually works its way into areas that random guessing would never have reached. It’s similar to a locksmith who doesn’t just try every key blindly, but follows up on every one that turns even slightly in the lock.

Fuzzing in developers' daily work and in the headlines

Fuzzing is never directly visible to users. You notice it only indirectly: browsers, operating systems, and messaging apps process files from the internet every day without crashing on every broken file. A large part of this robustness comes from years of automated testing. Many reported security vulnerabilities state directly in the report that they were discovered by a fuzzer.

Within companies, fuzzing usually runs continuously on dedicated servers, alongside normal development. When the fuzzer finds a crash, it automatically creates a ticket with the file that triggered it. This lets developers reproduce the bug exactly, which would otherwise be extremely tedious with random errors.

What’s new is the combination with language models. AI systems now write the small helper programs that show a fuzzer how a piece of software needs to be fed. This opens up code that no one used to bother with before. One common misconception persists nonetheless: fuzzing never proves that a program is secure. It only finds the bugs it happens to hit, and stays silent about all the others.