MITRE released the 2025 CWE Top 25 on December 11, 2025, identifying the most dangerous software weaknesses based on 39,080 CVE Records published between June 2024 and June 2025.
The list ranks weaknesses by their frequency as root causes in CVE data and their CVSS severity scores, highlighting persistent threats like XSS and SQL Injection alongside emerging issues such as authorization flaws and memory bugs—key priorities for DevSecOps teams securing modern cloud‑native applications. Explore how the 2025 rankings differ from 2024, the top ten shifts, and what CWE root causes reveal beyond CVE trends.
Understanding the Core: CWE vs CVE
To navigate the landscape of software security, it is crucial to distinguish between two foundational acronyms often used in the industry: CWE and CVE. While they are closely related, they serve different purposes in the vulnerability management lifecycle.
| Feature | CVE (Common Vulnerabilities and Exposures) | CWE (Common Weakness Enumeration) |
|---|---|---|
| Definition | A list of publicly disclosed cybersecurity vulnerabilities in specific software or firmware. | A category system for hardware and software weaknesses and vulnerabilities. |
| Focus | Specific instances of a vulnerability (e.g., Log4Shell). | The underlying root cause or type of mistake (e.g., SQL Injection). |
| Goal | To identify and catalog specific threats in specific products. | To understand, categorize, and prevent broad classes of coding errors. |
| Analogy | “There is a broken lock on the front door of House #123.” | “The design of this lock type is flawed and can be easily picked.” |
Modern vulnerability management needs both:
- CVE to know where you are vulnerable today
- CWE to understand why you keep getting similar vulnerabilities and how to fix them at the root (in patterns, frameworks, and development practice).
Top 10 with 2024 Rank Changes
Note: For readability, this article focuses on the Top 10 most dangerous weaknesses. For the complete list of 25, please refer to the official Mitre page.
| Rank | CWE ID | Name | Score | CVEs in KEV | Rank Change vs. 2024 |
|---|---|---|---|---|---|
| 1 | CWE-79 | Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) | 60.38 | 7 | 0 |
| 2 | CWE-89 | Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) | 28.72 | 4 | +1 |
| 3 | CWE-352 | Cross-Site Request Forgery (CSRF) | 13.64 | 0 | +1 |
| 4 | CWE-862 | Missing Authorization | 13.28 | 0 | +5 |
| 5 | CWE-787 | Out-of-bounds Write | 12.68 | 12 | -3 |
| 6 | CWE-22 | Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) | 8.99 | 10 | -1 |
| 7 | CWE-416 | Use After Free | 8.47 | 14 | +1 |
| 8 | CWE-125 | Out-of-bounds Read | 7.88 | 3 | -2 |
| 9 | CWE-78 | Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) | 7.85 | 20 | -2 |
| 10 | CWE-94 | Improper Control of Generation of Code (‘Code Injection’) | 7.57 | 7 | +1 |
CWE-79 holds the top spot unchanged, while buffer overflows like CWE-120, CWE-121, and CWE-122 enter newly due to refined methodology.
Trends and Insights from 2025 Top 25
The 2025 list reveals critical shifts in the software security landscape, driven by improved mapping methodologies and evolving threat vectors.
Injection and untrusted input are still haunting us
Despite decades of awareness, Cross-Site Scripting (CWE‑79) still sits at #1, and SQL Injection (CWE‑89) has climbed into the #2 position.
This clearly shows that:
- Handling untrusted input correctly remains a fundamental challenge across languages and frameworks.
- Defense-in-depth controls (WAFs, RASP, API gateways) have not fully compensated for insecure patterns at the application layer.
- Legacy code and “just ship it” pressures continue to resurface the same mistakes, especially in high-velocity web and API development.
For cloud-native and DevSecOps teams, this reinforces the need to:
- Treat input validation, encoding, and parameterized queries as non-negotiable defaults.
- Bake security checks into CI/CD (SAST, DAST, IAST) with rules explicitly targeting CWE‑79, CWE‑89, and CWE‑78.
- Enforce secure coding guidelines at the framework level (e.g., safe template engines, query builders, ORM best practices).
Authorization Gaps in Modern Architectures
One of the most notable movements in the list is CWE‑862: Missing Authorization, which has jumped several positions into the Top 5.
This aligns perfectly with how modern architectures are evolving:
- Microservices, APIs, and event-driven systems often spread business logic and authorization decisions across many components.
- Cloud-native environments rely on combinations of identity providers, tokens, RBAC, ABAC, and policy engines (OPA, built-in cloud IAM, etc.).
- It becomes very easy to miss a check, mis-scope a token, or expose an internal endpoint externally.
Typical patterns where Missing Authorization shows up:
- APIs that validate authentication but skip fine-grained authorization for specific operations.
- Internal admin endpoints exposed behind a misconfigured ingress or API gateway.
- Multi-tenant systems that do not correctly enforce tenant isolation.
From a DevSecOps perspective, this suggests investing heavily in:
- Centralized authorization patterns (e.g., policy-as-code with OPA or similar engines).
- Clear, consistent authorization models across microservices.
- Systematic tests for broken access control (both manual and automated) in CI/CD and pre-release security reviews.
- CNAPP adoption for monitoring and posture management is essential
Memory safety issues refuse to die
The 2025 list continues to feature classic memory safety weaknesses, such as:
- CWE‑787: Out‑of‑Bounds Write
- CWE‑125: Out‑of‑Bounds Read
- CWE‑416: Use After Free
These issues are especially visible in foundational components written in C/C++: operating systems, hypervisors, networking stacks, parsers, and performance-critical libraries.
Two key takeaways:
- Even if your application code is mostly in memory-safe languages (Go, Rust, Java, etc.), you are still exposed via dependencies, libraries, and infrastructure components.
- Migration from unsafe to safer languages is a long process; in the meantime, robust fuzzing, sanitizers, and careful code review in critical low-level components are mandatory.
In cloud-native stacks, that often means:
- Paying attention to vulnerabilities in container runtimes, service meshes, proxies, and ingress controllers.
- Treating updates and patching of these components as first-class SRE/DevSecOps work, not an afterthought.
Methodology changes matter: better mapping, more actionable data
Mitre has been improving how the Top 25 is derived, particularly around Root Cause Mapping:
- CVE Numbering Authorities (CNAs) are encouraged to map vulnerabilities to specific, precise CWE entries, rather than vague or “discouraged” buckets.
- Recent methodology changes reduce normalization to certain views and instead consider the actual mappings provided by CNAs.
- This leads to more specific Base/Variant CWEs appearing in the rankings (for example, more granular buffer overflow types), which are more directly actionable for developers and tool vendors.
For practitioners, this means:
- The list is gradually becoming more reflective of how people really report and experience vulnerabilities, not just of how the taxonomy was originally structured.
- Security tools that integrate CWE identifiers (SAST, dependency scanners, etc.) can now give more precise guidance linked to the Top 25.
Where to go next
If you want to dive deeper into the data and methodology, the official resources are the best place to start:
- 2025 CWE Top 25 main page https://cwe.mitre.org/top25/archive/2025/2025_cwe_top25.html
- 2025 Key Insights and methodology https://cwe.mitre.org/top25/archive/2025/2025_key_insights.html
- News announcement and related updates https://cwe.mitre.org/news/archives/news2025.html