Understanding Memory Safety Vulnerabilities: Top Memory Bugs and How to Address Them

Posted on February 26, 2025
Author: Nicole Spewak

Memory safety vulnerabilities remain one of the most persistent and exploitable weaknesses across software. From enabling devastating cyberattacks to compromising critical systems, these vulnerabilities present a constant challenge for developers and security professionals alike.

Both the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) have emphasized the importance of addressing memory safety issues to defend critical infrastructure and stop malicious actors. Their guidance highlights the risks associated with traditional memory-unsafe languages, such as C and C++, which are prone to issues like buffer overflows and use-after-free errors.

In February 2025, CISA drilled down even deeper with their guidance, issuing an alert on “Eliminating Buffer Overflow Vulnerabilities.

Why do memory corruption vulnerabilities still exist, how do they manifest in practice, and what strategies can organizations implement to mitigate their risks effectively? Let’s take a look.

What Are Memory Safety Vulnerabilities?  

Memory safety vulnerabilities occur when a program performs unintended or erroneous operations in memory. These issues can lead to dangerous consequences like data corruption, unexpected application behavior, or even full system compromise. Common Weakness Enumeration (CWEs), a body of knowledge tracking software vulnerabilities, highlights these as some of the most severe weaknesses in software today.

Memory safety issues are inherently tied to programming languages and runtime environments. Languages like C and C++ offer control and performance but lack built-in memory safety mechanisms, making them more prone to such vulnerabilities.

Attackers leverage memory corruption vulnerabilities as access points to infiltrate systems, exploit weaknesses, and execute malicious actions. Addressing memory vulnerabilities is essential for safety and security, especially for industries like critical infrastructure, medical devices, aviation, and defense.

 

Types of Memory Safety Vulnerabilities 

There are many different types of memory safety vulnerabilities, but there are particular ones that developers and security professionals should understand. The six explained below are listed on the 2024 Common Weakness Enumeration (CWE™) Top 25 Most Dangerous Software Weaknesses list (CWE™ Top 25), and are familiar faces on the list from previous years. The CWE Top 25 lists vulnerabilities that are easy to exploit and that have significant consequences.

1. Buffer Overflows (CWE-119) 

A buffer overflow occurs when a program writes more data to a buffer than it can safely hold. This overflow can corrupt adjacent memory, potentially leading to crashes, data corruption, or even allowing attackers to execute arbitrary code. 

Example of a Buffer Overflow

A notable example of a buffer overflow vulnerability is CVE-2023-4966, also known as “CitrixBleed,” which affected Citrix NetScaler ADC and Gateway products in 2023. This critical flaw allowed attackers to bypass authentication, including multi-factor authentication, by exploiting a buffer overflow in the OpenID Connect Discovery endpoint.

 The vulnerability enabled unauthorized access to sensitive information, including session tokens, which could be used to hijack authenticated user sessions. Discovered in August 2023, CitrixBleed was actively exploited by various threat actors, including ransomware groups like LockBit, leading to high-profile attacks such as the Boeing ransomware incident. 

This vulnerability highlights the ongoing significance of buffer overflow vulnerabilities in critical infrastructure and the importance of prompt patching and session invalidation to mitigate potential compromises

2. Heap-Based Buffer Overflow (CWE-122) 

A heap-based buffer overflow occurs when a program writes more data to a buffer located in the heap memory than it can safely hold. This can lead to memory corruption, crashes, privilege escalation, and even arbitrary code execution by attackers manipulating the heap memory structure.

Example of a Heap-Based Buffer Overflow 

An example of a recent critical heap-based buffer overflow is CVE-2024-38812, a vulnerability in VMware vCenter Server, discovered during the 2024 Matrix Cup hacking competition in China. With a CVSS score of 9.8, this flaw allows attackers with network access to craft malicious packets exploiting the DCERPC protocol implementation, potentially leading to remote code execution. This heap overflow vulnerability was initially patched but required a subsequent update to fully address the issue.

3. Use-After-Free Errors (CWE-416) 

Use-after-free errors arise when a program continues to use a memory pointer after the memory it points to has been deallocated. This can lead to system crashes, data corruption, or exploitation through arbitrary code execution. 

Example of a Use-After-Free Error

CVE-2021-44710 is a critical use-after-free UAF vulnerability discovered in Adobe Acrobat Reader DC, affecting multiple versions. The vulnerability has a CVSS base score of 7.8, indicating its high severity. If successfully exploited, an attacker could potentially execute arbitrary code on the target system, leading to various severe consequences including application denial-of-service, security feature bypass, and privilege escalation.

4. Out-of-Bounds Write (CWE-787) 

An out-of-bounds write occurs when a program writes data outside the allocated memory buffer. This can corrupt data, cause crashes, or create vulnerabilities that attackers can exploit. 

Example of an Out-of-Bounds Write

CVE-2024-7695 is a critical out-of-bounds write vulnerability affecting multiple Moxa PT switch series. The flaw stems from insufficient input validation in the Moxa Service and Moxa Service (Encrypted) components, allowing attackers to write data beyond the intended memory buffer bounds.

With a CVSS 3.1 score of 7.5 (High), this vulnerability can be exploited remotely without authentication. Successful exploitation could lead to a denial-of-service condition, potentially causing significant downtime for critical systems by crashing or rendering the switch unresponsive.

5. Improper Input Validation (CWE-020) 

Improper input validation occurs when a system fails to adequately verify or sanitize inputs before they are processed. This flaw can lead to unintended behaviors, including command injection, buffer overflows, or unauthorized access. Attackers exploit this weakness by crafting malicious inputs, often bypassing security controls or causing system failures. Input validation issues are particularly common in web applications and embedded systems where external data is heavily relied upon. 

Example of Improper Input Validation

CVE-2024-5913 is a medium-severity vulnerability affecting multiple versions of Palo Alto Networks PAN-OS software. This improper input validation flaw allows an attacker with physical access to the device’s file system to elevate privileges.

6. Integer Overflow or Wraparound (CWE-190) 

Integer overflow or wraparound occurs when an arithmetic operation results in a value that exceeds the maximum (or minimum) limit of the data type, causing the value to “wrap around.” This vulnerability can lead to unpredictable behaviors, such as buffer overflows, memory corruption, or security bypasses. Attackers exploit this weakness by manipulating inputs to trigger overflows, often resulting in system crashes or unauthorized actions. This issue is common in low-level programming languages like C and C++, where integer operations are not inherently checked.

Example of an Integer Overflow

CVE-2022-2329 is a critical vulnerability (CVSS 3.1 Base Score: 9.8) affecting Schneider Electric’s Interactive Graphical SCADA System (IGSS) Data Server versions prior to 15.0.0.22074. This Integer Overflow or Wraparound vulnerability can cause a heap-based buffer overflow, potentially leading to denial of service and remote code execution when an attacker sends multiple specially crafted messages. Schneider Electric released a patch to address this vulnerability.

Memory CVEs Affecting Critical Infrastructure

Recently, nation-state actors, like the Volt Typhoon campaign, have demonstrated the potential real-world impact of memory safety vulnerabilities in the software used to run critical infrastructure.

Additionally, in the last few years, memory safety vulnerabilities within ICS have seen a steady upward trend. There were less than 1,000 CVEs in 2014 but nearly 3,000 in 2023 alone.

CVE Vulnerability

Here are a few examples of memory safety vulnerabilities directly impacting critical infrastructure.

Ivanti Connect Secure Flaw

A zero-day vulnerability (CVE-2025-0282) in Ivanti’s Connect Secure appliances allowed remote code execution, enabling malware deployment on affected devices.

Siemens UMC Vulnerability

A heap-buffer overflow flaw (CVE-2024-49775) in Siemens’ industrial control systems exposed critical infrastructure to risks of arbitrary code execution and disruption.  

Mercedes-Benz Infotainment System

Over a dozen vulnerabilities in the Mercedes-Benz MBUX system could allow attackers with physical access to disable anti-theft measures, escalate privileges, or compromise data.

Rockwell Automation Vulnerability

A denial-of-service and possible remote code execution vulnerability (CVE-2024-12372) in Rockwell Automation’s PowerMonitor 1000 Remote product. This heap-based buffer overflow could compromise system integrity.

Why Addressing Memory Vulnerabilities Is Critical 

Memory vulnerabilities represent a significant share of software-based attacks. According to a study by CISA, two-thirds of vulnerabilities in compiled code stem from memory safety issues. These vulnerabilities can impact industries that depend heavily on legacy systems written in C and C++—industries like aerospace, manufacturing, and energy infrastructure.

Key Risks Posed by Memory Vulnerabilities:

  • Remote Control Exploits: Attackers can hijack systems, gaining full control over operations.
  • Data Breaches: Sensitive information can be corrupted, stolen, or erased.
  • Operational Downtime: System instability leads to interruptions in critical services.
  • Compliance Failures: Organizations risk fines for failing to meet cybersecurity regulations.

 

Best Practices for Mitigating Memory Vulnerabilities 

Organizations can address memory safety vulnerabilities by taking proactive measures like:

  • Adopting secure coding practices, implementing protections such as bounds-checking, avoiding unsafe functions, and rigorously managing dynamic memory usage.
  • Using static and dynamic analysis tools and fuzz testing to detect issues during development.
  • Using build-time Software Bill of Materials (SBOMs) to identify vulnerabilities and get transparency into memory safety issues in software.
  • Transitioning select components to memory-safe languages using incremental migration plans where feasible. 
  • Employing runtime protections like runtime application self protection to prevent memory exploitation at runtime. 
  • Consistently apply security patches for all software and firmware components to address known CVEs quickly.

Bringing About a Memory Safe Future 

RunSafe Security is committed to protecting critical infrastructure, and a major key to doing so is eliminating memory-based vulnerabilities in software. Following CISA’s guidance and Secure by Design is an important first step. However, CISA’s guidance to rewrite code into memory safe languages is impractical for companies that produce dozens or hundreds or thousands of embedded software devices, often with 10-30 year lifespans.

This is where RunSafe steps in, offering a far more cost effective and an immediate way to eliminate the exploitation of memory-based attacks. RunSafe Protect mitigates cyber exploits through Load-time Function Randomization (LFR), relocating software functions in memory every time the software is run for a unique memory layout that prevents attackers from exploiting memory-based vulnerabilities. With LFR, RunSafe prevents the exploit of 86 memory safety CWEs.

Rather than waiting years to rewrite code, RunSafe protects embedded systems today, allowing software to defend itself against both known and unknown vulnerabilities.

Interested in understanding your exposure to memory-based CVEs and zero days? You can request a free RunSafe’s Risk Reduction Analysis here.

 

What Is a SBOM? Binary vs Build-Time vs Source Code

What Is a SBOM? Binary vs Build-Time vs Source Code

Software Bills of Materials (SBOMs) are a detailed inventory of all the components—open source, proprietary, and third-party—used within a software application. SBOMs play a key role in ensuring software integrity, managing security risks, and strengthening software...

read more
A Guide to SBOM Requirements Around the Globe

A Guide to SBOM Requirements Around the Globe

Over the past several years, regulators around the globe have begun issuing Software Bill of Materials (SBOM) requirements and standards in an effort to strengthen software security. SBOMs are a detailed inventory of all the components—open source, proprietary, and...

read more