Three memory safety weaknesses are in the top ten of the 2025 CWE Top 25: CWE-787 out-of-bounds write at rank 5, CWE-416 use after free at rank 7 and CWE-125 out-of-bounds read at rank 8. The list is sponsored by CISA and managed by MITRE.
About the list
The page for the 2025 list was last updated on 15 December 2025. It ranks weaknesses by danger, not by how many of your findings carry the tag. The rest of the top ten is mostly web and injection issues: cross-site scripting, SQL injection, CSRF, missing authorization, path traversal, command injection and code injection.
CWE-787, out-of-bounds write
The program writes past the end or before the start of a buffer. Typical sources are unchecked copy lengths, off by one loops and wrongly computed sizes. Fixes: use containers and spans that carry length, compile with hardening flags, and run tests under a sanitizer.
CWE-416, use after free
An object is used after it is released. Fixes: clear ownership, so one component frees and the others hold non owning views with a known lifetime, plus tools that detect it, such as sanitizers in test and hardware tagging where available. In a language with ownership rules enforced at compile time, this pattern fails to compile.
CWE-125, out-of-bounds read
The program reads outside a buffer, which can leak data or crash. Fixes mirror CWE-787: length carrying types, checks before every index, and bounds checks from a hardened library.
Why the three often appear together
A single root cause can produce more than one of these tags. A wrongly computed length leads to an out-of-bounds write, and a stale pointer can lead to either a use after free read or a write. When you triage, expect related findings to share a fix, such as moving a buffer into a container that tracks its own size or changing who owns an object.
That has a planning consequence. Counting three separate weakness types may overstate the number of independent problems, so look for the underlying ownership or length handling pattern before you size the work.
Tagging matters
The list is only as useful as your own labeling. If your tracker does not store the weakness identifier, add the field, and backfill from advisories where you can. With the field in place you can answer the question that this list prompts: how often does each class appear in our own fixes, and is it going down after we adopted a safer language or a hardening flag?
How to use the list well
- Search your own record of fixed bugs for these three IDs and count them.
- Compare the count against the web injection entries, so you can see where your risk really is.
- For native code, make these three the first rows in your secure coding checklist.
- For managed language code, note that these weaknesses mostly arrive through native dependencies.
A caution
A weakness tag describes a pattern, not an exploit. An out-of-bounds read in a rarely used tool is a different priority from one in a network parser. Rank by exposure and reachability as well as by the tag.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how reachability separates findings in code you call from findings you never reach.
Quick check
Is the CWE Top 25 a count of vulnerabilities?
It is a ranking of the most dangerous weaknesses published by MITRE with CISA sponsorship. Use it as a prompt for your own data, not as a replacement for it.
Safeguard's reachability analysis can help you separate an out-of-bounds finding in code you call from one in code you never reach.
Sources
Last reviewed: 19 October 2026.
