The global cybersecurity landscape never stands still. This week, the 2025 list of the “Top 25 Most Dangerous Software Weaknesses” was released. While this extensive data is compiled by MITRE in partnership with the U.S. Homeland Security Systems Engineering and Development Institute (HSSEDI) and CISA, the findings are universal.
As a European open-source community, OSSMalta with affiliation to Open Regulatory Compliance Working Group (ORC WG) , we’re analyzing these findings through the lens of EU Citizens following EU regulation. This list is not just a set of statistics; it is a roadmap for compliance, resilience, and digital sovereignty.
What is the CWE Top 25?
The 2025 list draws on an analysis of 39,080 Common Vulnerabilities and Exposures (CVE) records reported between June 2024 and June 2025. It categorizes the underlying causes of software vulnerabilities using the Common Weakness Enumeration (CWE) program.
For European developers and SMEs, this list offers an accurate view into the structural defects most often exploited by attackers. Understanding these is the first step toward building “Secure by Design” products.
The CRA Context: Why This Matters in the EU
Under the European Cyber Resilience Act (CRA), the rules of the game have changed. Manufacturers and developers of products with digital elements (PDEs) are now legally required to ensure their products are released without “known exploitable vulnerabilities.”
The MITRE Top 25 list effectively serves as a baseline for what constitutes a “known vulnerability” in 2025. Failure to address these systemic flaws during the design phase could lead to non-compliance with Annex I (Essential Cybersecurity Requirements) of the CRA.
Implications for the Open Source Community:
- Essential Requirements: You must demonstrate that you have designed your software to mitigate these specific high-risk weakness classes.
- Due Diligence: If you integrate third-party libraries, you are responsible for ensuring they are free of these top-tier flaws.
- Documentation: Technical documentation must verify that you have tested against these common weakness types.
For a detailed breakdown of these regulations and how to prepare, visit the Cyber Resilience Act (CRA) Compliance Guide.
The Complete 2025 Top 25 List
Below is the consolidated list of the most dangerous software weaknesses for 2025. We have linked each to its official definition to help you identify and patch them.
| Rank | CWE ID | Name & Description | Trend |
| 1 | CWE-79 | Cross-Site Scripting (XSS) Improper neutralization of input during web page generation. | ↔️ Same |
| 2 | CWE-89 | SQL Injection Improper neutralization of special elements in an SQL command. | ⬆️ Up 1 |
| 3 | CWE-78 | OS Command Injection Improper neutralization of special elements in an OS command. | ↔️ Same |
| 4 | CWE-862 | Missing Authorization The software does not perform an authorization check when an actor attempts to access a resource or perform an action. | ⬆️ Up 5 |
| 5 | CWE-787 | Out-of-bounds Write Writing data past the end, or before the beginning, of the intended buffer. | ⬇️ Down 3 |
| 6 | CWE-416 | Use After Free Referencing memory after it has been freed. | ↔️ Same |
| 7 | CWE-22 | Path Traversal Improper limitation of a pathname to a restricted directory. | ↔️ Same |
| 8 | CWE-352 | Cross-Site Request Forgery (CSRF) Forcing an end user to execute unwanted actions on a web application. | ⬆️ Up |
| 9 | CWE-434 | Unrestricted Upload of File with Dangerous Type Allows attackers to upload files that can be executed. | ↔️ Same |
| 10 | CWE-502 | Deserialization of Untrusted Data Untrusted data is used to abuse the logic of an application. | ↔️ Same |
| 11 | CWE-120 | Classic Buffer Overflow Buffer copy without checking the size of input. | 🆕 New |
| 12 | CWE-476 | NULL Pointer Dereference A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL. | ⬆️ Up 8 |
| 13 | CWE-287 | Improper Authentication Actor claims to have a given identity but the software does not prove it. | ⬇️ Down |
| 14 | CWE-121 | Stack-based Buffer Overflow A buffer overflow that occurs on the stack. | 🆕 New |
| 15 | CWE-798 | Use of Hard-coded Credentials The software contains hard-coded credentials, such as a password or cryptographic key. | ↔️ Same |
| 16 | CWE-122 | Heap-based Buffer Overflow A buffer overflow that occurs in the heap. | 🆕 New |
| 17 | CWE-522 | Insufficiently Protected Credentials The software transmits or stores authentication credentials in a way that is susceptible to unauthorized access. | ↔️ Same |
| 18 | CWE-20 | Improper Input Validation The product does not validate or incorrectly validates input. | ⬇️ Down 6 |
| 19 | CWE-284 | Improper Access Control The software does not restrict or incorrectly restricts access to a resource. | 🆕 New |
| 20 | CWE-200 | Exposure of Sensitive Information The product exposes sensitive information to an unauthorized actor. | ⬇️ Down 3 |
| 21 | CWE-306 | Missing Authentication for Critical Function The software does not perform any authentication for functionality that requires a verifyable user identity. | ⬆️ Up 4 |
| 22 | CWE-918 | Server-Side Request Forgery (SSRF) The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. | ⬇️ Down 3 |
| 23 | CWE-77 | Command Injection The software constructs all or part of a command using externally-influenced input from an upstream component. | ⬇️ Down 10 |
| 24 | CWE-639 | Authorization Bypass Through User-Controlled Key The user can modify a key (like an ID) to access another user’s data. | ⬆️ Up 6 |
| 25 | CWE-770 | Allocation of Resources Without Limits The software allocates a reusable resource or component based on an untrusted input without limiting the size or amount. | ⬆️ Up 1 |
Best Practices: Mitigating Exploitation
To align with EU standards (like NIS2 and CRA) and protect against these flaws, organizations should implement the following:
- Shift Left with Automation: Integrate SAST/DAST scanning into your CI/CD pipeline to flag CWE-79 and CWE-89 early.
- Memory Safe Languages: Migrate legacy code from C/C++ to memory-safe languages like Rust. This eliminates buffer overflows (CWE-120) by design.
- Strict Identity Management: Implement Multi-Factor Authentication (MFA) and zero-trust architecture to mitigate authorization bypasses (CWE-862).
- Maintain an SBOM: Under the CRA, you must maintain a Software Bill of Materials. Use this to track third-party dependencies that may contain known vulnerabilities.
- Community Intelligence: Check resources like the OSS Malta Blacklists to stay aware of bad actors, insecure vendors, or software that consistently fails to meet these security standards.
Local Resources & Funding for Maltese Entities
Securing your infrastructure is a requirement, but you do not have to do it alone. There are specific grants and schemes available in Malta and the EU to help you fund these improvements.
Funding & Support Schemes:
- CYBER+ALT Grant Scheme: Managed by the National Cybersecurity Coordination Centre (NCC-MT) within MITA. This scheme helps SMEs finance up to 80% of eligible costs (max €60,000) for cybersecurity solutions, including vulnerability management and threat detection.
- Cyber Assess Scheme: Also under MITA/NCC-MT, this scheme provides some free cybersecurity services, such as vulnerability assessments and penetration testing, to eligible businesses.
- Digitalise Your Business: Offered via Measures and Support Division, this grant supports digital transformation, including investments in cybersecurity hardware and software.12
Key Agencies:
- MITA (NCC-MT): The National Cybersecurity Coordination Centre offers guidance, funding, and community building.
- MDIA: The Malta Digital Innovation Authority is the authority on certification and standards (including AI and CRA compliance).
- Tech.mt: Promotes the national strategy for technology and innovation, offering assistance to tech companies in Malta.
Disclaimer: OSSMalta is an independent community and is not affiliated with these government entities at the current time. While we believe these schemes are valuable, we cannot verify if the listed grants/government schemes are currently valid or accepting applications. Entities should verify the status and availability directly with the relevant agencies. We understand that government agencies monitor our activities, and we extend a friendly invitation for them to join the open-source community to foster greater collaboration on cyber resilience.
Further Reading for those that want to know more:
Open Regulatory Compliance Working Group (CRA Guide) – FAQ and guide on the Cyber Resilience Act
ENISA Threat Landscape 2025 – European Cyber Securities 2025 landscape report
EU Vulnerability Database – More on EU Vulnerability reporting and database
