we_are_coded.by CODE · The world, decoded
БГ
Concept

Memory bugs

The BasicsUpdated on 13 July 2026we are coded

Behind most "critical vulnerability discovered" headlines sits the same old trick - as old as software itself.

Checked on13 July 2026
In short: every program borrows a piece of memory while it runs, then has to give it back. The bug is that it sometimes forgets to erase the address it's pointing to after the memory has already been freed. That's exactly where the attacker sneaks in and plants their own data, and the program runs it as if it were its own. That's "use-after-free", and its cousin is the "buffer overflow". These two terms sit behind a surprisingly large share of the news about hacked systems.

Picture a hotel room you've just checked out of. The front desk has already given it to someone else, but your key, for some reason, still works. You walk in, leave something of yours in the drawer, and the next guest, without suspecting anything, packs it into their own luggage. That's exactly what "use-after-free" does. The program tells the computer "I'm done with this memory", but forgets to throw away the key. The attacker walks into the same "room" and leaves code there, which the program later runs with full trust.

A buffer overflow is a bit blunter. The program sets aside room for, say, one short name. If someone types something twice as long into the field, the overflow spills straight into the memory next to it - right where the program's own instructions often sit. Rewrite that neighboring memory carefully enough, and you literally rewrite what the computer does next.

Neither bug is exotic. They've existed since we started writing software in languages that don't check memory boundaries themselves - they leave that to the programmer. Who gets it wrong. Constantly. Because checking costs resources, and the old languages were written in an era when resources were more expensive than the risk.

This is why we have Rust. The language is built so the compiler physically stops you before you can compile code that would leave a key in someone else's hand. The rule is built into the language itself, not left to the programmer's good will. A large part of the industry is now shifting that way, because thousands of manual checks can't beat one compiler armed with logic.

The key stays with you even after the room belongs to someone else, and that's exactly where the attacker walks in.

Looked at aesthetically

I'm skeptical of every "we found a new vulnerability" from the last few months - behind a large share of those headlines sits exactly this same old story, dressed up in a new product. It's not a new category of risk. It's an old debt the industry refuses to pay off all at once.

The truth that doesn't sound good to investors is that rewriting software in a safer language costs money and time, and companies would rather patch the next specific breach than change the foundation. Until that math changes, we'll keep reading the same headline, just with a different logo on top.

The visual is generated code art. No third-party images.
Official primary sources
→Chromium Security - Memory safety (around 70% of serious vulnerabilities are memory bugs)→CISA/NSA - The Case for Memory Safe Roadmaps