In September 2023, a single memory corruption bug in an open-source image library forced Chrome, Firefox, Edge, Signal, 1Password, and dozens of other applications to ship emergency patches within days of each other. The flaw, tracked as CVE-2023-4863, was a heap buffer overflow in libwebp that let attackers write attacker-controlled data past the end of an allocated buffer while decoding a malicious WebP image. It was already being exploited in the wild as part of a zero-click spyware chain against journalists and activists. The root cause behind that incident, and behind thousands of other CVEs every year, has a name: CWE-787, Out-of-Bounds Write. It has topped MITRE's list of the most dangerous software weaknesses for four years running. This post breaks down what out-of-bounds write vulnerabilities actually are, why they keep surfacing in the software supply chain, and how Safeguard helps teams catch them before they ship.
What Is an Out-of-Bounds Write Vulnerability?
An out-of-bounds write vulnerability occurs when a program writes data past the boundary of a memory buffer it was allocated, corrupting adjacent memory it was never supposed to touch. CWE-787 is the formal Common Weakness Enumeration entry for this class of bug, defined by MITRE as software that "writes data past the end, or before the beginning, of the intended buffer." In practice this happens when code fails to validate that an index, offset, or length value stays within the bounds of an array, string, or heap allocation before writing to it. A classic example is a fixed-size stack buffer, say char buffer[64], that receives user-supplied input via a function like strcpy() without checking the input length. If the input is 200 bytes, the extra 136 bytes spill into whatever memory sits next to that buffer: a saved return address, a function pointer, a heap chunk header, or another variable entirely. The corrupted memory doesn't announce itself immediately; the program may keep running for milliseconds or minutes before the tampered data is read or executed, which is part of what makes these bugs so hard to trace back to their root cause.
Why Has CWE-787 Topped MITRE's Most Dangerous Weaknesses List?
CWE-787 has ranked #1 on the MITRE/CISA CWE Top 25 Most Dangerous Software Weaknesses every year since 2021, and it held the top spot again in the 2023 and 2024 editions with a danger score of 63.72 out of a normalized 100-point scale. That score is calculated from two factors: how frequently a weakness appears in real-world CVEs mapped from the NVD, and how severe those CVEs tend to be, measured by average CVSS score. Out-of-bounds write earns the top rank on both axes. It is the single most common root cause tag applied to critical and high-severity vulnerabilities disclosed each year, and NVD data shows several thousand CVEs mapped to CWE-787 in the years covered by MITRE's analysis window. Compare that to CWE-79 (Cross-Site Scripting), which ranks second most years but tends to produce lower-severity findings on average. The combination of high frequency and high severity is why security teams treat any out-of-bounds write finding as a priority-one item rather than routine backlog cleanup.
How Do Attackers Exploit Out-of-Bounds Writes?
Attackers exploit out-of-bounds writes by aiming the corrupted memory at something the program will trust and later execute, most commonly a stack return address, a heap allocator's metadata, or a function pointer or vtable entry. In a stack-based overflow, overwriting the saved return address lets an attacker redirect execution to shellcode or to existing code in the binary, a technique known as return-oriented programming (ROP) that bypasses simple non-executable-stack protections. In a heap-based overflow, like the pattern behind CVE-2021-3156 (the "Baron Samedit" sudo vulnerability), the attacker overwrites adjacent heap chunk headers or object fields to trigger a type confusion or to hijack a function pointer that later gets called with attacker-chosen arguments. Even when full code execution isn't achievable, out-of-bounds writes reliably crash the target process, which is enough to cause denial-of-service in critical infrastructure, and CVE-2020-1350 ("SIGRed"), a 17-year-old out-of-bounds write in the Windows DNS Server role, carried a maximum CVSS score of 10.0 because it was both wormable and remotely triggerable with no authentication.
What Are Real-World Examples of Out-of-Bounds Write Vulnerabilities?
Real-world CWE-787 incidents span operating systems, browsers, and everyday open-source libraries, and they share a pattern of cascading downstream impact. CVE-2023-4863 in libwebp, mentioned above, is instructive precisely because libwebp is vendored inside so many applications: patching Chrome didn't fix Firefox, and patching Firefox didn't fix Signal or Telegram, because each project had bundled its own copy of the vulnerable decoding code. CVE-2021-3156, the Baron Samedit sudo bug, sat undiscovered in default sudo installations for roughly ten years before a Qualys researcher found it in January 2021, and it granted local privilege escalation to root on nearly every major Linux distribution. CVE-2022-3602 and CVE-2022-3786 were buffer overflows in OpenSSL's punycode decoding for X.509 certificate name constraints, disclosed in November 2022 and initially feared to be as impactful as Heartbleed before analysis showed the overflow was harder to weaponize than first thought. Further back, the 2015 "Stagefright" bugs in Android's media framework showed how a single MMS message could trigger an out-of-bounds write during video processing, putting roughly 950 million Android devices at theoretical risk without the user ever opening the malicious file.
Why Are Out-of-Bounds Writes Especially Dangerous in the Software Supply Chain?
Out-of-bounds writes are especially dangerous in the software supply chain because a single vulnerable C or C++ library gets compiled into hundreds of downstream products, each of which must be identified and patched independently. Memory-unsafe languages like C and C++ still power the vast majority of operating system kernels, image and video codecs, compression libraries, and network protocol parsers precisely the components that sit deep in dependency trees and get pulled in transitively without direct developer awareness. When libwebp shipped CVE-2023-4863, security teams had to answer a question that traditional vulnerability scanning struggles with: "does any application in our environment statically link or vendor this specific version of this specific library, even several layers deep?" Many organizations only discovered their exposure weeks later, after incident responders manually traced binary dependencies. This is the structural reason CWE-787 findings tend to linger in production far longer than their CVSS scores would suggest is acceptable: the vulnerable code isn't in anyone's first-party repository, it's baked into a build artifact or container image inherited from an upstream dependency.
How Can Organizations Detect and Prevent Out-of-Bounds Write Vulnerabilities?
Organizations detect and prevent out-of-bounds write vulnerabilities through a layered combination of memory-safe language adoption, continuous fuzzing, compiler-level mitigations, and supply chain visibility, because no single control catches every case. Google's OSS-Fuzz project, which has continuously fuzzed libwebp and hundreds of other open-source C/C++ projects since 2016, has surfaced thousands of memory-safety bugs before public disclosure, and it was fuzzing infrastructure like AddressSanitizer (ASan) that made rapid triage of CVE-2023-4863 possible once it surfaced. Compiler and OS mitigations, stack canaries, Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP/NX bit), and Control Flow Integrity (CFI), don't prevent the underlying write but make exploitation significantly harder and less reliable. CISA's 2023 joint guidance with the NSA and international partners explicitly urged software manufacturers to migrate new development to memory-safe languages such as Rust, Go, or Java, arguing that the majority of severe CWE-787 and related memory-safety CVEs are structurally impossible in those languages. For code that must stay in C or C++, static analysis tools that flag unchecked buffer writes, combined with strict CI gates that reject builds with unresolved memory-safety warnings, catch a meaningful share of these bugs before merge. None of that works, though, without first knowing which dependencies, and which versions of them, are actually running in production.
How Safeguard Helps
Safeguard gives security and engineering teams the visibility that manual dependency tracing can't provide at scale. Our platform continuously builds and maintains a software bill of materials (SBOM) across your codebases and build artifacts, so when a CWE-787 vulnerability like a future libwebp-style disclosure hits the NVD, Safeguard can immediately answer whether, and where, the vulnerable version is present, including in transitively bundled or statically linked dependencies that traditional scanners miss. Safeguard correlates CVE feeds against your actual dependency graph in real time, prioritizes findings using both CVSS severity and reachability analysis so your team fixes exploitable out-of-bounds write bugs first rather than chasing every low-risk match, and tracks remediation status across every repository and pipeline from a single dashboard. For organizations building on C/C++ components or ingesting third-party binaries, Safeguard also flags newly introduced memory-unsafe dependencies during pull request review, giving teams a chance to catch risky additions before they ever reach production. The result is fewer surprise "which of our hundred applications actually uses this library" scrambles, and a much shorter window between disclosure and remediation the metric that ultimately determines whether an out-of-bounds write vulnerability becomes a footnote or a breach.