Memory Safety Vulnerabilities Are Still Winning. Here's Why That Number Is Probably Worse Than It Looks.

Google's Threat Intelligence Group (GTIG) recently published its 2025 Zero-Day review, and one figure in particular deserves more attention than it's getting in embedded security circles. Memory safety issues, primarily use-after-free and out-of-bounds write vulnerabilities, accounted for roughly 35 percent of all vulnerabilities exploited in the wild last year.

Thirty-five percent is a significant number—more than one in three. While it's less than half, suggesting some progress has been made, this shouldn't be read as a success story. The fact that over a third of respondents still report these concerns indicates the industry has substantial work ahead.

What That 35 Percent Actually Represents

The Google figure is drawn from known exploited vulnerabilities: the confirmed, reported, and attributed cases where a zero-day was used in the wild before a patch was available. That's a specific and relatively narrow slice of the actual vulnerability landscape.

When you look at the broader population of vulnerabilities across embedded, IoT, ICS, and OT environments, the proportion of memory safety issues runs considerably higher than 35 percent. Depending on the system and the research methodology, figures in the 40 to 70 percent range are well-supported. 

For example, Microsoft's Security Response Center, which triages every reported Microsoft security vulnerability, found that approximately 70 percent of the vulnerabilities assigned a CVE each year were memory safety issues. Additionally, the Google Security Blog regularly publishes articles on their progress toward memory safety, with memory safety vulnerabilities in Android once accounting for 76 percent.

The gap between the GTIG number and the broader empirical picture reflects what gets attributed and reported, not what's actually present in production systems and certainly not what has been exploited but not discovered. The recent Salt Typhoon breach is one example of a case where threat actors maintained persistent access to U.S. telecommunications infrastructure for an extended period before detection.

In industrial control systems and operational technology environments specifically, the situation is likely worse than either figure suggests. These systems are built on long-lived C and C++ codebases, often developed decades before memory safety was treated as a design constraint, frequently running without the update infrastructure that consumer-facing products take for granted. The vulnerability density is high, the patch cadence is slow, and the attribution pipeline that feeds threat intelligence reports is underdeveloped compared to the enterprise and browser spaces.

So when Google reports that 35 percent of exploited zero-days in 2025 were memory-based, that's a useful signal. Engineers working in embedded environments should understand they're looking at the visible portion of a larger problem.

Why This Class of Vulnerability Keeps Winning

Use-after-free and out-of-bounds writes aren't new or exotic. The techniques for exploiting them are well-documented, widely understood, and increasingly commoditized. Their persistence as a leading exploit vector is a structural feature of how most embedded software is written, not a gap in defender awareness.

The programming languages that dominate embedded development, C and C++, do not provide memory safety by default. The developer is responsible for managing allocation, deallocation, and boundary checking. At the scale and complexity of modern embedded stacks, that's a near-impossible standard to maintain consistently, and even experienced teams with rigorous processes produce memory vulnerabilities. The relevant question isn't whether memory safety issues will appear in C and C++ codebases, it's when they'll be discovered, by whom, and in what context.

The GTIG report correctly identifies use-after-free as a top vector in browsers and OS kernels. Those environments are under intense scrutiny, receive continuous fuzzing and research attention, and have relatively mature patch infrastructure. Even with all of that investment, memory vulnerabilities remain a leading exploit vector. In embedded environments, which receive a fraction of that scrutiny and have far more constrained update mechanisms, there's no basis for expecting better outcomes from the same underlying languages and development practices.

The Embedded Security Gap

Google's data also reflects a broader pattern that should concern anyone working in industrial and operational technology: enterprise technologies are attracting increasing zero-day attention. Almost half of 2025's tracked zero-days targeted enterprise-grade systems, and the report notes that edge devices and security appliances are prime targets for state-sponsored actors.

Operational technology environments sit at an uncomfortable intersection here. They're often invisible to the threat intelligence ecosystem that generates reports like Google's, but they're increasingly connected to enterprise networks, accessible from the internet, and running software stacks that predate modern security practices. At the same time, many OT devices are shifting away from bespoke or open-source RTOSs toward embedded Linux distributions such as Yocto. While this transition improves flexibility and interoperability, it also expands the attack surface by introducing widely used enterprise software components into OT environments. As a result, vulnerabilities traditionally associated with enterprise systems increasingly apply to OT devices as well, further blurring the boundary between these domains.

Memory corruption in an ICS controller or an embedded safety system doesn't need to enable credential theft or data exfiltration to be consequential. Code execution on a system that controls physical processes carries a different category of risk than the same vulnerability in an enterprise application, and that context matters considerably when reading aggregate statistics about exploit types.

Remediation Is a Solved Problem — If You Use the Right Tools

The path to reducing memory safety exposure in embedded systems is well understood, even if it isn't uniformly applied.

Rewriting C and C++ codebases in memory-safe languages is a genuine long-term strategy, but also an undertaking that takes years, requires scarce engineering talent, and introduces new validation burdens under functional safety standards that are particularly demanding in embedded contexts. That path is worth pursuing for new development and for high-risk components where resources permit. For deployed systems and the long tail of legacy code that will remain in production for another decade, it's not a realistic near-term option.

Static analysis and fuzzing catch a share of memory vulnerabilities before they reach production, particularly when applied continuously as part of a development pipeline. However, a study by North Carolina State University shows that for Linux operating system software over a 10-year period, only 2.5% of memory vulnerabilities were identified in vulnerability scanning tools.

The most immediately actionable path for existing codebases is runtime protection applied at build time. Code protections like Load-time Function Randomization can eliminate or significantly mitigate entire classes of memory vulnerabilities without requiring rewrites, without adding agents, and without the performance overhead that has historically made these approaches impractical in resource-constrained embedded environments. When a vulnerability is disclosed in a deployed system, runtime protections already in place dramatically narrow the window of exploitability while a patch works its way through validation and distribution.

Treating this class of vulnerability as primarily a patch management problem is where many organizations go wrong. The cycle of discovery, CVE issuance, and patch deployment was designed for a faster, more connected software environment than most embedded systems operate in. A use-after-free vulnerability in firmware running on a five-year update cycle presents a fundamentally different risk profile than the same vulnerability class in a browser that updates weekly. Runtime protection doesn't replace patching, but it changes the stakes of the interval between discovery and remediation considerably.

What the Number Tells Us

Returning to that 35 percent figure, the right way to read Google's data is as a baseline for a category of risk that has proven remarkably persistent across decades of security investment, tooling improvement, and industry attention, not as a report card.

Memory safety vulnerabilities are not declining as a share of real-world exploitation because the underlying conditions that produce them haven't changed. The languages are still dominant. The codebases are still large, complex, and difficult to audit. The embedded environments where these issues concentrate are still under-resourced for security relative to the consumer and enterprise spaces that generate most threat intelligence. And as we see more and more adoption of LLM-enabled coding assistants, we’ll see more and more memory safety vulnerabilities get introduced to compiled code.

The knowledge, standards, tooling, and techniques to meaningfully reduce exposure all exist. The gap is largely one of implementation, where organizations need to have proven protections applied to the systems that carry the most risk before a vulnerability is exploited, rather than after.