CWE Top 25 for 2025: every weakness type ranked and explained

MITRE's 2025 CWE Top 25 ranks cross-site scripting (CWE-79) first with a score of 60.38, then SQL injection (CWE-89) at 28.72 and cross-site request forgery (CWE-352) at 13.64. The list ranks weakness types, not single bugs. Use it to decide what to test for and which classes of flaw your code reviews should look for.

What is the full 2025 list?

The table below copies rank, identifier, name and score from MITRE's page for the 2025 list.

MITRE's page also shows, for each weakness, how many of its CVEs appear in CISA's Known Exploited Vulnerabilities catalog. The page links to a separate methodology document, which we did not read, so we do not restate how the score is calculated. Read it before you cite the scores as frequencies.

What do the groups mean in plain words?

Injection and web flaws (79, 89, 352, 78, 94, 77, 22, 434, 918). Untrusted input reaches an interpreter, a file path, a browser page or an internal request. The fixes are consistent: parameterized queries, output encoding, allow lists for paths and uploads, and tokens against forged requests.

Access control (862, 863, 284, 639, 306). Five entries are about who is allowed to do what. Missing authorization, incorrect authorization, weak access control, user-controlled keys and missing authentication together show that the question "is this caller allowed?" gets skipped more often than most teams expect. Check authorization on the server for every object, every time.

Memory safety (787, 416, 125, 120, 121, 122, 476). Seven entries concern reading or writing memory the program should not touch. They matter most in C and C++ code and in libraries written in them. Memory safe languages remove much of this class. Where you cannot switch, rely on bounds checking, sanitizers and fuzzing.

Data handling (502, 20, 200). Untrusted data is deserialized into live objects, input is not validated, or sensitive information leaks to people who should not see it.

Resource limits (770). Without caps, one caller can use all the memory, connections or money.

How should I use this list?

Treat it as a map of what attackers and researchers keep finding, not as a checklist of everything. Your own incident history and your language mix should change the order. A Python web team will care more about the first ten entries than about heap overflows. A team shipping firmware will care about the opposite.

What to do

1. Map your static analysis and test rules to the CWE identifiers above and note which are not covered.
2. Add authorization tests that call each endpoint as the wrong user. Five list entries depend on it.
3. Search your dependencies for native code written in C or C++ and track their memory safety fixes.
4. Put resource limits on every public endpoint and every job queue.
5. Review the list yearly, because the ranking moves.

Quick check

Sources

• MITRE: 2025 CWE Top 25 Most Dangerous Software Weaknesses

Last reviewed: 18 October 2026.