Executive Summary
The 2025 CWE Top 25 by MITRE highlights the most prevalent and dangerous software weaknesses, derived from an analysis of 39,080 CVE records published between mid-2024 and mid-2025. These weaknesses – often easy to find and exploit – account for a large share of critical vulnerabilities that enable adversaries to fully compromise systems, steal data, or disrupt services. The 2025 ranking shows persistent dominance of classic web injection flaws (with Cross-Site Scripting remaining #1 for the second year) and a notable rise in access control issues.
Missing or improper authorization checks have climbed significantly, and several memory corruption flaws (buffer overflows on stack/heap) newly appear in the Top 25 this year. Conversely, some historically high-level weaknesses (e.g. improper privilege management, integer overflow) have dropped out, reflecting improvements in the precision of root cause mapping in CVE reports.
This Top 25 serves as a priority guide for CISOs, SOCs, and CERTs: by addressing these common software errors – and investing in developer education to prevent them – organizations can proactively mitigate entire classes of vulnerabilities and significantly strengthen their security posture.
Detailed Analysis of the Top 25 Software Weaknesses in 2025
- CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-Site Scripting) – Rank #1 (no change from 2024).
Cross-Site Scripting (XSS) remains the most widespread software weakness. It occurs when an application fails to neutralize user input before injecting it into a web page. This allows attackers to insert malicious scripts that execute in other users’ browsers.
Impact: XSS attacks often lead to theft of session cookies and user credentials, unauthorized actions performed on behalf of victims, and potential full account takeover (especially if an admin account is affected). XSS carries the highest combined score (60.38) and has 7 known exploited CVEs associated, underlining its severe real-world prevalence.
Context: Very common in web applications (classified as “Often” prevalent for Web contexts) with a High likelihood of exploit according to MITRE.
Mitigations: Utilize vetted templating frameworks or libraries that automatically escape output to prevent injecting scripts. Employ strict input validation (prefer a whitelist of allowed patterns) and output encoding for any content that goes into HTML pages. Web developers should also implement Content Security Policy (CSP) and HttpOnly cookies as defense-in-depth. - CWE-89: SQL Injection – Rank #2 (up 1).
SQL Injection occurs when an application constructs database SQL queries using externally-supplied input without properly quoting or removing SQL metacharacters. Attackers can alter the query’s structure – for example by injecting a ‘ OR ‘1’=’1′ condition or adding an UNION SELECT – leading the database to execute unintended commands.
Consequences: An attacker could retrieve, modify, or delete database data without authorization, and in some cases execute OS commands via SQL (if combined with shell invocation or by abusing database extensibility). SQLi remains extremely dangerous and is tied to 4 CVEs in CISA’s Known Exploited Vulnerabilities (KEV) catalog this year. It is also classified with High exploit likelihood.
Mitigations: Use parameterized queries or prepared statements instead of string concatenation. Employ ORMs or frameworks that abstract database access and automatically handle input sanitization. Additionally, enforce least privilege for database accounts (so injection yields minimal access) and use stored procedures to constrain query logic. - CWE-352: Cross-Site Request Forgery (CSRF) – Rank #3 (up 1).
CSRF (also known as session riding) arises when a web application does not sufficiently verify that a request was intentionally made by the legitimate user. An attacker can exploit the victim’s authenticated session by causing their browser to send a forged request (for instance, by loading an image or iframe that triggers an action on the target site).
Impact: The malicious request executes with the victim’s privileges, allowing actions like changing account details, performing transactions, or other state-changing operations without the victim’s consent. If the victim is an admin, CSRF can compromise the entire application (e.g. creating a new admin user, etc.).
Data: CSRF has a score of 13.64 and 0 known exploited CVEs listed, yet it remains a prominent web weakness.
Mitigations: Implement anti-CSRF tokens – unique, unpredictable values tied to the user’s session and validated on each sensitive request. Additionally, require re-authentication or confirmation for high-risk transactions and ensure the application has no XSS vulnerabilities (since XSS can be used to bypass CSRF tokens by directly initiating requests from within the application’s context). - CWE-862: Missing Authorization – Rank #4 (up 5).
This weakness means the application does not perform any authorization checks when a user attempts to access a resource or perform an action. In other words, functionality that should be restricted to certain roles or users is not enforced on the server side.
Trend: It jumped to #4 from #9, making it one of the biggest upward movers, which highlights growing awareness of access control issues.
Impact: Attackers (including normal authenticated users) can invoke privileged operations or access data they shouldn’t. Examples include viewing or editing someone else’s data (if no check is in place), or performing administrative actions without being an admin. There were no KEV CVEs for missing authorization in 2024-25, but it has a high score (13.28) due to the severity of potential outcomes.
Mitigations: Adhere to the principle of least privilege in design – partition the system into clearly defined user roles (e.g. normal user vs admin) and enforce role-based access control for every sensitive request. Never assume a client will hide or disable UI for unauthorized actions; the server must verify permissions on every request. Comprehensive authorization testing (including horizontal and vertical access control tests) should be part of QA. - CWE-787: Out-of-Bounds Write – Rank #5 (down 3 from #2 in 2024).
An out-of-bounds write occurs when software writes data past the end or before the beginning of the intended memory buffer. This typically results from buffer overflow bugs in languages like C/C++ where memory is manually managed.
Consequences: Out-of-bounds writes lead to memory corruption – which can crash the program (denial of service) or, if attackers overwrite control data (like return addresses or function pointers), allow them to execute arbitrary code. It remains highly relevant in exploits (e.g. for remote code execution vulnerabilities). This weakness is linked to 12 known exploited CVEs – the highest count among Top 25 entries. The slight drop in rank reflects other issues rising, not that OOB writes are less dangerous.
Mitigations: Where possible, use languages that prevent buffer overflows (Java, C#, Rust, etc.) or utilize safer libraries for buffer operations. Enable compiler-level protections (stack canaries, _FORTIFY_SOURCE, etc.) and perform rigorous bounds checking on all memory accesses. Fuzz testing can also help uncover these vulnerabilities before deployment. - CWE-22: Improper Limitation of a Pathname to a Restricted Directory (Path Traversal) – Rank #6 (down 1).
A path traversal flaw occurs when an application constructs file or directory paths using user input without preventing navigation outside a restricted directory. Attackers can include sequences like ../ to climb up directories and access files that should be off-limits.
Impact: Depending on context, an attacker might read sensitive files (configuration, passwords), modify critical files (if the app has write permissions – possibly enabling code execution or bypassing auth as in adding an admin to a config), or even cause crashes by overwriting files. The CWE score is 8.99, and 10 exploited CVEs fell under path traversal, illustrating active attacker interest.
Mitigations: Validate and sanitize all user inputs that are used in file paths. This includes removing problematic characters/sequences (like .., /, \) or using whitelist patterns for allowed file names. Use high-level file APIs that can enforce directory restrictions (e.g., chroot jail or libraries that resolve and canonicalize paths). Also, run the server with minimal privileges so even if traversal occurs, accessible files are limited. - CWE-416: Use After Free – Rank #7 (up 1).
A use-after-free bug happens when the program continues to use a pointer to memory after that memory has been freed. After freeing, the same memory region might be reallocated for other objects. If the stale pointer is used, it can corrupt whatever new data is there.
Impact: Use-after-free often leads to process crashes or unpredictable behavior. More critically, it can be exploitable for arbitrary code execution if an attacker can influence what gets placed at the freed memory (creating a so-called “write-what-where” scenario). This weakness is prevalent in C/C++ and is present in 14 CVEs on the KEV list, underscoring that attackers actively leverage UAF vulnerabilities (especially in browsers and operating systems).
Mitigations: Choose memory-safe languages (which automatically handle memory) whenever feasible. If using C/C++, strategies include setting pointers to NULL immediately after freeing (so further use triggers a null-pointer crash instead – a less dangerous failure), though this is not foolproof especially in complex data structures. Employ robust runtime testing tools (AddressSanitizer, etc.) to catch use-after-free during development. - CWE-125: Out-of-Bounds Read – Rank #8 (down 2).
This weakness involves reading data past an array’s bounds – either before the start or beyond the end of a buffer.
Impact: Out-of-bounds reads can expose sensitive information from memory (often called an information leak). For example, an out-of-bounds read might return stack or heap data that includes passwords, keys, or memory addresses. It can also cause a crash (reading unmapped memory triggers an exception). Attackers can sometimes exploit OOB reads to bypass memory protection measures (like ASLR) by leaking pointers, making it easier to exploit other bugs.
Data: Score 7.88; 3 KEV CVEs mapped to CWE-125.
Mitigations: Validate all array indices, offsets, and length arguments before memory reads. Be cautious with functions that read until a terminator (like strcpy expecting \0 – if missing, it will read out-of-bounds). Use safe functions or classes that track buffer sizes. Employ memory safety features of compilers/platforms (e.g., bounds checking in debug builds, memory tagging hardware if available) to catch these issues early. - CWE-78: OS Command Injection – Rank #9 (down 2).
OS command injection is when software generates an operating system command using user input without proper neutralization of special characters. Attackers can inject shell metacharacters (such as ;, &&, |) to execute additional commands.
Impact: Full system compromise – the attacker can run arbitrary OS commands with the same privileges as the vulnerable application. This can lead to data exfiltration, installing malware, or pivoting deeper into a network.
Prevalence: CWE-78 has a score of 7.85 and is tied to 20 known exploited CVEs (one of the highest KEV counts), demonstrating it’s a favorite target in the wild.
Mitigations: Avoid constructing shell commands from external input. When possible, use APIs (e.g., library calls or language functions) that perform the needed action without invoking a shell. If you must call an OS command, use safe functions that accept an array of arguments (bypassing the shell) or thoroughly escape/validate the input to remove any command separators. Employ the principle of least privilege: the service should run with minimal OS rights to limit damage if command injection occurs. - CWE-94: Improper Control of Generation of Code (Code Injection) – Rank #10 (up 1).
This weakness refers to cases where an application generates or injects executable code (source code, scripts, bytecode) using external input without proper neutralization. Examples include eval() in scripting languages, dynamic code generation in templates, or writing to files that will later be executed.
Impact: Arbitrary code execution within the application’s context. Code injection often leads to complete compromise of the application, similar to OS command injection but at the application code level. Prevalence: Score 7.57; 7 exploited CVEs fell under CWE-94.
Mitigations: The primary mitigation is not to dynamically generate or execute code from user inputs unless absolutely necessary. If dynamic execution is needed (for example, a plugin architecture), implement strict allow-lists for permissible operations or run the code in a sandbox with limited privileges. Input used in code generation should be rigorously validated or confined to non-executable contexts. Use established scripting safe engines or disable dangerous capabilities (e.g., in template languages, avoid raw expression evaluation). - CWE-120: Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’) – Rank #11 (new entry).
This classic CWE, now explicitly in the 2025 list, occurs when data is copied into a buffer without ensuring the destination can hold it. This is the archetypal buffer overflow (e.g., using gets() or strcpy() in C without length checks).
Impact: Typically, a stack-based buffer overflow, since many unchecked copies involve local buffers – leading to potential remote code execution by overwriting return addresses or function pointers. It can also cause crashes or data corruption.
Note: In prior years, these were counted under CWE-119 (a more general class). The methodology change in 2025 now lists them separately. It has no KEV CVEs directly (score 6.96), but that’s more about classification than lack of exploits – many RCEs are of this variety.
Mitigations: Use safer alternatives for buffer operations (e.g., strncpy, memmove with explicit length, or safer string libraries). Enable memory safety features like stack canaries and ASLR to make exploitation harder. Fundamentally, always track and respect buffer lengths – if reading user input, limit it to the buffer size minus one (for null terminator), etc. - CWE-434: Unrestricted Upload of File with Dangerous Type – Rank #12 (down 2).
This weakness means the system allows upload or transfer of files of dangerous types without sufficient checking, and then automatically processes them. A common scenario is a web app accepting file uploads but not verifying the file type, allowing an attacker to upload a web shell (e.g., a .php file in an uploads directory) and then execute it via a browser.
Impact: Remote code execution (if the server executes the file) or malware delivery to other users who download a Trojan file. Prevalence: Score 6.87; 4 exploited CVEs in 2024-25.
Mitigations: Implement strict file type validation. Allow only expected file formats (by checking MIME type and extension). Rename uploaded files to neutral names (to prevent retaining attacker-supplied extension) and store them outside the web root or in a segregated file system area. If possible, scan files for malware or potentially dangerous content. Also configure the server such that uploaded files (especially if binary or script) are not directly executable. - CWE-476: NULL Pointer Dereference – Rank #13 (up 8).
This weakness happens when the application dereferences a pointer that it expects to be valid, but is NULL. In many cases, a null-pointer dereference just causes a crash (denial of service). It’s usually considered a reliability bug more than a security bug.
However, in some rare scenarios (especially in kernel or driver code), a null pointer might be mapped to a controllable memory page, leading to potential read/write of memory address 0 and exploitation. The big jump in ranking might be due to changes in mapping practices (as high-level “improper error handling” issues are phased out, their instances may now show as CWE-476). It has 0 KEV CVEs and a moderate score (6.41).
Mitigations: The best practice is to always check if a pointer is NULL before dereferencing when there’s any chance it could be uninitialized or come from a function that can fail. Many platforms won’t allow mapping of address 0 in user mode, so risk is mostly DoS. Using languages with automatic null checks or exception handling (Java, etc.) can eliminate this class of crash. - CWE-121: Stack-based Buffer Overflow – Rank #14 (new).
This variant of buffer overflow refers specifically to overflows in stack-allocated buffers (local variables). It is one of the most notorious vulnerability types historically (e.g., the Morris worm, Code Red, etc.).
Impact: A stack overflow allows an attacker to overwrite critical stack data such as return addresses, often leading to execution of attacker-controlled code when the function returns. It can also crash the program if canaries or other protections detect it.
Context: Newly listed due to using raw CVE data (previously these might have been aggregated under general CWE-119). It has a score of 5.75 and 4 known exploited CVEs.
Mitigations: Similar to other buffer overflows – avoid unsafe library functions and perform explicit bounds checking. On the defensive side, modern systems use stack canaries and non-executable stacks to make exploitation harder, but these are not foolproof. Compiling with stack protection and address randomization is essential. From a development standpoint, use safer string functions or switch to languages that automatically check array bounds. - CWE-502: Deserialization of Untrusted Data – Rank #15 (up 1).
This weakness means the application deserializes (reconstructs) an object or data structure from untrusted input without sufficient validation. Many languages support serialization of complex objects (Java’s ObjectInputStream, Python pickle, PHP unserialize(), etc.). Attackers can manipulate the serialized data to make the system create unintended objects or invoke methods in unexpected ways.
Impact: Possibly remote code execution or logic manipulation. For instance, an attacker might include a serialized payload that triggers the instantiation of a gadget chain leading to execution of a system command. Other impacts include data tampering or DoS (crafting data that, when deserialized, cause resource exhaustion or exceptions). This weakness has a score of 5.23 and 11 exploited CVEs (in recent years, several high-profile deserialization RCEs in products like WebLogic, Jenkins, etc.).
Mitigations: Do not accept serialized objects from untrusted sources if possible. If you must, implement integrity checks like a digital signature or HMAC on serialized data to ensure it hasn’t been modified. Use deserialization libraries that allow defining an allow-list of classes that can be deserialized, to prevent unexpected object types. Frequently update and review any serialization frameworks for known gadget chains, and disable or remove unused object classes that could be abused. - CWE-122: Heap-based Buffer Overflow – Rank #16 (new).
This is the heap counterpart to CWE-121: a buffer overflow in heap-allocated memory. Heap overflows can corrupt dynamic memory management metadata or adjacent allocations.
Impact: Similar to other overflows – crashes or possible arbitrary code execution. A classic exploitation is to overwrite function pointers or object vtables on the heap, hijacking the program flow. Or manipulate allocator metadata to eventually overwrite critical memory. This CWE’s appearance is due to the methodology no longer consolidating to CWE-119, giving us more granular entries for heap vs stack. Score 5.21; 6 exploited CVEs.
Mitigations: Many of the same measures as for other memory corruptions: prefer safe languages or libraries to handle memory. When using C/C++, carefully manage dynamic memory – check lengths on allocation and copying, use bounds-checking memory functions, and consider adding heap integrity checks. Modern OS/compilers provide heap protection (like glibc’s memory allocation hardening, guard pages, etc.) – keep those enabled. Memory error detectors (Valgrind, etc.) can help catch heap overflows during testing. - CWE-863: Incorrect Authorization – Rank #17 (up 1).
This CWE is related to CWE-862 but distinct: here an authorization mechanism exists but is implemented incorrectly, allowing unauthorized access. For example, an application might intend to check if a user owns a record but uses the wrong user identifier or fails open on an error.
Impact: Essentially the same spectrum as missing authorization – sensitive data exposure, unauthorized modification, or privilege escalation – except it might be more subtle because the check is present but flawed. It scores 4.14 with 4 exploited CVEs. Often, these bugs are found in complex permission logic or multi-tenant systems.
Mitigations: Thoroughly review and test authorization logic. MITRE recommends clearly segregating roles and applying business logic checks as well as lower-level access checks. For instance, even if a database enforces row-level permissions, the application should also enforce context-specific rules (like “users can only access their own records”). Use frameworks or centralized authorization modules to reduce implementation mistakes, and ensure that any introduced check actually validates the correct conditions (no bypass on malformed input or error conditions). - CWE-20: Improper Input Validation – Rank #18 (down 6).
This is a broad category for cases where software receives input and does not validate that it meets the expected format, type, length, or range. It’s an extremely common root cause underpinning many other vulnerability types – buffer overflows, injections, XSS, etc., all involve some form of input not being validated or sanitized. Trend: It dropped from #12 to #18, likely because specific issues are now mapped more precisely (rather than lumping into CWE-20). Score 4.09; 2 exploited CVEs under the generic CWE-20. However, the concept remains critical.
Impacts: Vary widely – from crashes (if an app doesn’t handle unexpected input and fails) to full compromise (if that input triggers an injection or overflow).
Mitigations: Adopt a disciplined input validation strategy: “accept known good”. For each input, define what is valid (e.g., numeric range, allowed characters, max length) and reject anything that doesn’t conform. This includes validating metadata (like content length headers) and not just content. Use centralized validation routines when possible. Also, be aware of implicit inputs (like environment variables, cookies, etc.) and validate those as well. While it’s impossible to enumerate all improper validation issues, having a strong secure coding standard for input handling is key. - CWE-284: Improper Access Control – Rank #19 (new entry).
This CWE is very broad (a Pillar category) representing cases where the product does not properly restrict access to resources. It can mean either the access control mechanisms are missing (which overlaps with CWE-862) or that settings (permissions, ACLs) are misconfigured. MITRE listing it (with “DISCOURAGED” mapping) indicates these are scenarios not covered by more specific child CWEs.
Impact: Highly context-dependent – could lead to privilege escalation, data leaks, or any number of security violations. For example, an application might inadvertently allow anyone to perform admin tasks due to a misapplied ACL. It has a score of 4.07 and 1 known exploited CVE. Mitigations: Carefully manage and enforce permissions.
At design time, identify all sensitive resources and ensure they have proper access controls. Use secure defaults (deny by default, least privilege). Consider employing standardized frameworks for access control to avoid custom errors. Conduct configuration reviews and penetration tests focusing on potential access control lapses (like trying to access admin functionality as a normal user, or manipulating resource identifiers). - CWE-200: Exposure of Sensitive Information to an Unauthorized Actor – Rank #20 (down 3).
This weakness covers a range of info-leak issues where sensitive info is not properly protected and can be accessed by someone without permission. Examples include verbose error messages exposing system details, directory listings left enabled, stack traces or dumps returned in API responses, or lack of encryption allowing eavesdropping.
Impact: Loss of confidentiality. Depending on what’s exposed, this could greatly aid attackers (e.g., leaking credentials, personal data, or system configuration info that could be leveraged in an attack). Score 4.01; 1 exploited CVE known (likely because many info leaks are not individually reported, or considered lower severity unless combined with another issue).
Mitigations: Minimize information disclosure. Don’t reveal system internals in responses – for instance, replace stack traces or debug info with generic errors. Remove any default/test pages and ensure sensitive files aren’t web-accessible. Apply proper authentication and encryption for data in transit and at rest to prevent intercepting sensitive info. Basically, consider any data that the system handles and make sure it’s only accessible to the intended parties (principle of least knowledge). Regular audits can help spot unintentional data exposures. - CWE-306: Missing Authentication for Critical Function – Rank #21 (up 4).
This means a critical functionality is exposed without requiring user authentication. Examples: administrative or sensitive API endpoints that don’t enforce login, or a device that has critical controls accessible over a network without credentials.
Impact: An attacker can directly invoke these critical functions. This often leads to a complete compromise – e.g., shutting down a service, reading or modifying sensitive data, or even getting a shell if the function allows it. There are 11 exploited CVEs in this category, showing that misconfigurations or oversights in requiring auth are not uncommon.
Mitigations: Require authentication (and authorization) for all non-public functions. Map out which parts of your system should only be used by authenticated users and enforce it consistently. Avoid “hidden” URLs or unlinked pages as a security measure – if something must be restricted, it must have proper auth checks. Also be wary of secondary channels: sometimes a system authenticates on one interface but trusts requests on another port as internal – which can be exploited. So ensure authentication is applied across all channels and interfaces. Use standard frameworks for authentication sessions/tokens to avoid mistakes, and consider multi-factor auth for highly critical actions. - CWE-918: Server-Side Request Forgery (SSRF) – Rank #22 (down 3).
SSRF occurs when a server-side application receives a URL or resource request from the client and fetches it, but fails to ensure the request is to an allowed, safe destination. Attackers can abuse this by tricking the server into making HTTP/HTTPS requests to internal services (which the attacker themselves might not directly reach).
Impact: SSRF can be used to bypass network controls – for example, scanning internal networks, accessing cloud instance metadata endpoints, or posting data to external attacker-controlled servers using the server’s privileges. In some cases, SSRF can even be escalated to remote code execution if internal endpoints like Redis or Docker APIs without auth are accessible. Score 3.36; 0 known KEV CVEs (but there have been notable SSRF exploits, e.g., in cloud management platforms).
Mitigations: Whitelist allowed URLs or destinations for server-fetching functionality. For instance, if the server should only fetch images from an allowed list of domains, enforce that. Disallow or carefully validate URLs that point to localhost or private IP ranges. Also consider scheme restrictions – e.g., block file:// or gopher:// schemes which can be abused. Implement network-layer controls (firewall rules) such that the web server cannot freely connect to internal-only services. Additionally, if using HTTP libraries, set connection timeouts and response size limits to reduce potential impact of SSRF (like infinite wait or huge downloads). - CWE-77: Improper Neutralization of Special Elements used in a Command (Command Injection) – Rank #23 (down 10). CWE-77 is a more general form of command injection (Class level), whereas CWE-78 is specifically about OS commands (Base level). CWE-77 might cover injection into various command contexts or subsystems. The significant drop (-10) suggests many issues got mapped to more specific entries (like CWE-78) rather than this general one. It has a score of 3.15 and 2 exploited CVEs.
Impact: Essentially the same as CWE-78 – if exploited, an attacker can execute unintended commands. The difference is mostly classification.
Mitigations: The advice mirrors that for CWE-78: whenever constructing any sort of command (whether OS, SQL, mail server commands, etc.) from user input, ensure to use safe APIs or heavily sanitize inputs. For example, if an application builds a command string for an internal interpreter, treat user input as data only and escape any delimiter characters. Use allow-lists for expected values. Given CWE-77’s broad nature, the specific mitigation depends on the command context (some protocols or services might have their own injection syntaxes to guard against). - CWE-639: Authorization Bypass Through User-Controlled Key – Rank #24 (up 6).
This is essentially the Insecure Direct Object Reference (IDOR) vulnerability. The application uses a user-supplied key or identifier to access an object (like a database record) and does not verify the user’s authorization for that object. For example, a URL like /getProfile?userId=123 returns user #123’s profile to whoever makes the request, without confirming that requestor is user 123.
Impact: Horizontal privilege escalation – one user can access or modify another user’s data by changing a key (user IDs, record IDs, file names, etc.). This is one of the most common web API flaws. Score 2.62; 0 KEV CVEs (actually [47] shows rank 24 has 0 KEV, likely referencing this), but plenty of IDOR issues have been found in bug bounties and pentests.
Mitigations: Never rely solely on user-provided IDs or keys for access control. Even if the user is authenticated, the server must enforce that the requested resource or action corresponds to that user’s privileges. Use indirect references or mappings where feasible (e.g., map user IDs to session-specific tokens so they can’t simply guess another’s ID). Implement thorough checks: if user 101 requests data item 202 belonging to user 102, the service should deny it. Frameworks can provide object-level security features or you can implement your own check systematically in the data access layer. - CWE-770: Allocation of Resources Without Limits or Throttling – Rank #25 (up 1).
This weakness refers to situations where a system allows unlimited allocation or usage of a resource (memory, CPU, threads, file handles, etc.) without enforcing quotas or limits. Attackers can exploit this by simply consuming a resource to exhaustion – a form of Denial of Service attack.
Impact: DoS (Resource Exhaustion). For example, an API that lets a user upload data endlessly could fill up disk space, or an endpoint with no rate limit could be spammed to saturate CPU or memory. It might not allow code execution or data theft, but it can make the service unavailable and potentially crash. CWE-770 being in Top 25 indicates recognition of application-layer DoS as a notable security concern. Score 2.54 (lowest on list), no specific KEV CVEs (because these issues are sometimes not reported as CVEs unless affecting critical infrastructure).
Mitigations: Impose sane limits on all resource allocations and client requests. This means implementing rate limiting (e.g., max requests per minute per user or IP), size limiting (max file upload size, max number of items in a batch, etc.), and concurrent usage limits (max sessions per user, max threads used, etc.). Also ensure that error conditions free resources properly (to avoid inadvertent resource leaks). In design, identify potential abuse vectors – anything that can be invoked repeatedly or consume significant work – and put controls in place (e.g., CAPTCHA or authentication requirements to deter automated abuse, back-off algorithms, and monitoring to detect spikes in usage).
Key Trends in the 2025 CWE Top 25
Rising Issues: The largest rank increases in 2025 are in the area of access control and memory safety. Missing Authorization (CWE-862) jumped 5 spots, now at #4, reflecting increased attention to authorization flaws (likely due to more CVEs reporting them separately). Null Pointer Dereference (CWE-476) rose 8 places to #13, and Missing Authentication for Critical Function (CWE-306) climbed 4 to #21 – indicating that authentication/authorization weaknesses are being recognized and reported more frequently.
Moreover, new entries in the Top 25 include three buffer overflow variants – CWE-120, 121, 122 (classic, stack, and heap buffer overflows) – and Improper Access Control (CWE-284). These appeared because the 2025 methodology stopped “rolling up” data to broader categories (View-1003 normalization), allowing lower-level weaknesses to rank. Their inclusion provides a more accurate picture of real-world vulnerabilities, highlighting that memory corruption remains a significant problem (with six memory-related CWEs in the Top 25) and that organizations must still invest in memory-safe practices and languages.
Declining/Removed: Conversely, overly broad weakness categories have dropped significantly. Improper Input Validation (CWE-20) fell 6 spots to #18, as many issues formerly lumped under it are now mapped to specific causes. Several CWEs that were in 2024’s Top 25 fell off the list entirely in 2025: e.g., Improper Privilege Management (CWE-269), Integer Overflow or Wraparound (CWE-190), Improper Authentication (CWE-287), Uncontrolled Resource Consumption (CWE-400), and Hard-coded Credentials (CWE-798). Most of these are now ranked 29 or lower.
MITRE notes that many were abstract “Discouraged” CWEs that previously received aggregated mappings – with normalization removed, their children now take their place. For example, Integer Overflow (CWE-190) moved down from #23 to #30, and its absence in the Top 25 is largely due to better mapping of specific integer issues or use of more precise CWEs. This shift indicates improvement in CVE mapping precision by CNAs: instead of tagging an issue as a general class, analysts are finding the closest specific weakness, which leads to more actionable data for defenders.
Persistence of Web and Memory Flaws: The 2025 list continues to be dominated by web-related vulnerabilities and low-level memory issues. Cross-Site Scripting, SQL Injection, and CSRF remain in the top three, underlining that injection flaws are still rampant and dangerous (and often trivially exploitable). These are staple issues behind many breaches, emphasizing that secure coding practices for input handling and query parameterization are still not universally applied. On the memory side, vulnerabilities like out-of-bounds write (#5), use-after-free (#7), and others are heavily represented, accounting for a substantial portion of the KEV vulnerabilities. Attackers frequently exploit these in browsers, OS kernels, and IoT devices, often chaining them with other bugs (like info leaks) to achieve full exploits.
Impact of Methodology Changes:
The changes in methodology – particularly using raw CNA-provided CWE mappings rather than normalizing to a simplified view – have provided deeper insight into vulnerability trends. It exposed that many issues previously categorized as a single abstract weakness were in fact multiple distinct weaknesses.
As a result, this year’s Top 25 is more granular. For defenders, this means more specific guidance: e.g., instead of just “do input validation” (CWE-20), the list pinpoints the exact failures like path traversal, missing auth, etc. This helps in creating targeted mitigation plans. The methodology also highlighted the need for CNAs to avoid mapping to high-level CWEs when a specific one is applicable – a practice which seems to be improving (the proportion of mappings to “Discouraged” CWEs dropped in 2025).
In summary, the Top 25 weaknesses of 2025 underscore the importance of secure coding fundamentals – from validating inputs and outputs to enforcing proper authentication/authorization and writing memory-safe code. The list’s evolution also signals an industry shift towards better vulnerability classification.
Security teams should use these insights to prioritize remediation efforts on the most impactful weakness types, invest in developer training for those areas (e.g., preventing injections and memory errors), and update their security testing to cover these common issues. Addressing these Top 25 weaknesses can significantly reduce an organization’s exposure to both opportunistic attacks and sophisticated exploits
Enjoy !
