Why We Are Still Fighting the Same Vulnerabilities from 2004

TLDR: Despite two decades of industry awareness, memory safety issues and injection flaws remain the primary drivers of critical security incidents. This post analyzes why the industry continues to struggle with these preventable classes of vulnerabilities and how the shift toward Secure by Design principles aims to force manufacturers to take ownership of product security. For researchers and pentesters, this means shifting focus from finding novel bypasses to pressuring vendors to eliminate entire classes of bugs at the architectural level.

Software security is currently stuck in a loop. Every year, we see massive, headline-grabbing breaches caused by vulnerabilities that have been well-understood since the early 2000s. When a major incident hits, the industry often focuses on the specific exploit chain or the cleverness of the attacker. Yet, if you look at the root cause, you rarely find a groundbreaking, never-before-seen vulnerability. Instead, you find a classic SQL injection or a memory corruption bug that could have been prevented by choosing a different language or implementing basic input validation.

The Myth of the Novel Attack

Security researchers often chase the high of finding a zero-day in a complex, modern system. While that work is vital, it often obscures a more uncomfortable truth: the vast majority of successful attacks against critical infrastructure are not sophisticated. They are the result of systemic failures in how we build software.

Take the MOVEit Transfer incident from 2023. It was a massive, high-impact event, but the underlying vulnerability was a SQL injection. We have known how to prevent SQL injection since at least 2004, when parameterized queries became the standard. When we see these vulnerabilities in 2025, it is not a failure of the researcher to find them; it is a failure of the manufacturer to build a product that makes it impossible for a developer to write vulnerable code.

Why Memory Safety Matters

Memory safety is perhaps the most egregious example of this cycle. We continue to build critical infrastructure in languages that provide no memory safety guarantees, and then we act surprised when a buffer overflow leads to remote code execution.

The data is clear. When companies like Google or Microsoft move core components of their products to memory-safe languages like Rust, the number of memory-related vulnerabilities drops significantly. This is not a theoretical benefit. It is a measurable, repeatable outcome. If you are a pentester, you know that finding a memory corruption bug in a C++ codebase is often a matter of time and effort. If that same component were written in a memory-safe language, that entire category of bugs would vanish.

The Role of Transparency and Disclosure

A major part of the problem is the lack of transparency in how vendors handle vulnerabilities. When a company hides its security flaws or refuses to provide clear, actionable information about them, they are essentially asking the security community to do their job for them.

The Common Vulnerabilities and Exposures (CVE) system is meant to be a record of truth, but it is often treated as a PR hurdle rather than a tool for systemic improvement. We need to move toward a model where filing a CVE is not just a way to track a bug, but a way to signal that a specific class of vulnerability is still present in a product. If a vendor is repeatedly filing CVEs for the same class of injection, that is a clear signal that their development lifecycle is broken.

What This Means for Pentesters

For those of us in the trenches, this means our engagement strategy needs to evolve. Instead of just reporting a single bug, we should be looking at the patterns. If you find a SQL injection in one part of an application, look for the pattern that allowed it. Is the developer using a custom database wrapper that doesn't enforce parameterized queries? Is there a lack of centralized input validation?

When you write your reports, don't just provide the payload. Provide the architectural recommendation. Tell the vendor that they need to move to a library that handles sanitization automatically or that they need to switch to a language that prevents these classes of bugs by design.

Moving Beyond the Patch Cycle

We cannot patch our way out of this. The current model of "find bug, report bug, patch bug" is a treadmill that only benefits the attacker. The only way to break the cycle is to force a shift in responsibility. Manufacturers must be held accountable for the security of their products, not just for the patches they release after a breach.

This is the core of the Secure by Design movement. It is about making the secure path the easiest path for developers. It is about building systems where entire classes of vulnerabilities are impossible to introduce. As researchers, our role is to keep the pressure on. We need to continue to expose these systemic failures and demand that vendors stop treating security as an afterthought. The next time you find a classic vulnerability in a modern product, don't just treat it as another bug bounty. Treat it as a failure of the product's design and push for the architectural change that will prevent it from ever happening again.