{
	"id": "4749b540-9d8a-4b87-9219-c5f4737fad87",
	"created_at": "2026-04-06T01:32:22.500306Z",
	"updated_at": "2026-04-10T03:24:29.281581Z",
	"deleted_at": null,
	"sha1_hash": "534fd5a95f37fbee7d71c70a535b0af45c845ac8",
	"title": "CWE-400: Uncontrolled Resource Consumption (4.19.1)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 399163,
	"plain_text": "CWE-400: Uncontrolled Resource Consumption (4.19.1)\r\nArchived: 2026-04-06 01:16:47 UTC\r\nWeakness ID: 400\r\nVulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities\r\nAbstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific\r\nlanguage or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level\r\nweaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.\r\n Description\r\nThe product does not properly control\r\nthe allocation and maintenance of a\r\nlimited resource.\r\n Alternate Terms\r\nResource Exhaustion\r\n Common Consequences\r\nThis table specifies different individual consequences associated with the weakness. The Scope identifies the application\r\nsecurity area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in\r\nexploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be\r\nseen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be\r\nexploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.\r\nImpact Details\r\nDoS: Crash, Exit, or Restart;\r\nDoS: Resource Consumption\r\n(CPU); DoS: Resource\r\nConsumption (Memory); DoS:\r\nResource Consumption (Other)\r\nScope: Availability\r\nIf an attacker can trigger the allocation of the limited resources, but the number or\r\nsize of the resources is not controlled, then the most common result is denial of\r\nservice. This would prevent valid users from accessing the product, and it could\r\npotentially have an impact on the surrounding environment, i.e., the product may\r\nslow down, crash due to unhandled errors, or lock out legitimate users. For example,\r\na memory exhaustion attack against an application could slow down the application\r\nas well as its host operating system.\r\nBypass Protection Mechanism;\r\nOther\r\nScope: Access Control, Other\r\nIn some cases it may be possible to force the product to \"fail open\" in the event of\r\nresource exhaustion. The state of the product -- and possibly the security\r\nfunctionality - may then be compromised.\r\n Potential Mitigations\r\nPhase(s) Mitigation\r\nArchitecture and\r\nDesign\r\nDesign throttling mechanisms into the system architecture. The best protection is to limit the\r\namount of resources that an unauthorized user can cause to be expended. A strong authentication\r\nand access control model will help prevent such attacks from occurring in the first place. The login\r\napplication should be protected against DoS attacks as much as possible. Limiting the database\r\naccess, perhaps by caching result sets, can help minimize the resources expended. To further limit\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 1 of 15\n\nthe potential for a DoS attack, consider tracking the rate of requests received from users and\r\nblocking requests that exceed a defined rate threshold.\r\nArchitecture and\r\nDesign\r\nMitigation of resource exhaustion attacks requires that the target system either:\r\nrecognizes the attack and denies that user further access for a given amount of time, or\r\nuniformly throttles all requests in order to make it more difficult to consume resources more\r\nquickly than they can again be freed.\r\nThe first of these solutions is an issue in itself though, since it may allow attackers to prevent the\r\nuse of the system by a particular valid user. If the attacker impersonates the valid user, they may be\r\nable to prevent the user from accessing the server in question.\r\nThe second solution is simply difficult to effectively institute -- and even when properly done, it\r\ndoes not provide a full solution. It simply makes the attack require more resources on the part of the\r\nattacker.\r\nArchitecture and\r\nDesign\r\nEnsure that protocols have specific limits of scale placed on them.\r\nImplementation Ensure that all failures in resource allocation place the system into a safe posture.\r\n Relationships\r\n This table shows the weaknesses and high level categories that are related to this weakness. These relationships are\r\ndefined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of\r\nabstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user\r\nmay want to explore.\r\n Relevant to the view \"Research Concepts\" (View-1000)\r\nNature Type\r\nChildOf Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it\r\nParentOf Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More spe\r\nParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods f\r\nParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods f\r\nParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods f\r\nParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods f\r\nParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods f\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 2 of 15\n\nParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods f\r\nCanFollow Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More spe\r\n Relevant to the view \"Weaknesses for Simplified Mapping of Published Vulnerabilities\" (View-1003)\r\nNature Type\r\nMemberOf View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) an\r\nParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods f\r\nParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods f\r\n Modes Of Introduction\r\nThe different Modes of Introduction provide information about how and when this weakness may be introduced. The\r\nPhase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related\r\nto introduction during the given phase.\r\nPhase Note\r\nOperation\r\nThe product could be operated in a system or environment with lower resource limits than\r\nexpected, which might make it easier for attackers to consume all available resources.\r\nSystem Configuration\r\nThe product could be configured with lower resource limits than expected, which might\r\nmake it easier for attackers to consume all available resources.\r\nArchitecture and Design\r\nThe designer might not consider how to handle and throttle excessive resource requests,\r\nwhich typically requires careful planning to handle more gracefully than a crash or exit.\r\nImplementation\r\nThere are at least three distinct scenarios that can commonly lead to resource exhaustion:\r\nLack of throttling for the number of allocated resources.\r\nLosing all references to a resource before reaching the shutdown stage.\r\nNot closing/returning a resource after processing.\r\nResource exhaustion problems often occur due to an incorrect implementation of the\r\nfollowing situations:\r\nError conditions and other exceptional circumstances.\r\nConfusion over which part of the program is responsible for releasing the resource.\r\n Applicable Platforms\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 3 of 15\n\nThis listing shows possible areas for which the given weakness could appear. These may be for specific named\r\nLanguages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed\r\nalong with how frequently the given weakness appears for that instance.\r\nLanguages Class: Not Language-Specific (Undetermined Prevalence)\r\nTechnologies Class: Not Technology-Specific (Undetermined Prevalence)\r\n Likelihood Of Exploit\r\nHigh\r\n Demonstrative Examples\r\nExample 1\r\nThe following example demonstrates the weakness.\r\n(bad code)\r\nExample Language: Java \r\nclass Worker implements Executor {\r\n...\r\npublic void execute(Runnable r) {\r\ntry {\r\n...\r\n}\r\ncatch (InterruptedException ie) {\r\n// postpone response\r\nThread.currentThread().interrupt();\r\n}\r\n}\r\npublic Worker(Channel ch, int nworkers) {\r\n...\r\n}\r\nprotected void activate() {\r\nRunnable loop = new Runnable() {\r\npublic void run() {\r\ntry {\r\nfor (;;) {\r\nRunnable r = ...;\r\nr.run();\r\n}\r\n}\r\ncatch (InterruptedException ie) {\r\n...\r\n}\r\n}\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 4 of 15\n\n};\r\nnew Thread(loop).start();\r\n}\r\n}\r\nThere are no limits to runnables. Potentially an attacker could cause resource problems very quickly.\r\nExample 2\r\nThis code allocates a socket and forks each time it receives a new connection.\r\n(bad code)\r\nExample Language: C \r\nsock=socket(AF_INET, SOCK_STREAM, 0);\r\nwhile (1) {\r\nnewsock=accept(sock, ...);\r\nprintf(\"A connection has been accepted\\n\");\r\npid = fork();\r\n}\r\nThe program does not track how many connections have been made, and it does not limit the number of connections.\r\nBecause forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU,\r\nprocesses, or memory by making a large number of connections. Alternatively, an attacker could consume all available\r\nconnections, preventing others from accessing the system remotely.\r\nExample 3\r\nIn the following example a server socket connection is used to accept a request to store data on the local file system using a\r\nspecified filename. The method openSocketConnection establishes a server socket to accept requests from a client. When a\r\nclient establishes a connection to this service the getNextMessage method is first used to retrieve from the socket the name\r\nof the file to store the data, the openFileToWrite method will validate the filename and open a file to write to on the local file\r\nsystem. The getNextMessage is then used within a while loop to continuously read data from the socket and output the data\r\nto the file until there is no longer any data from the socket.\r\n(bad code)\r\nExample Language: C \r\nint writeDataFromSocketToFile(char *host, int port)\r\n{\r\nchar filename[FILENAME_SIZE];\r\nchar buffer[BUFFER_SIZE];\r\nint socket = openSocketConnection(host, port);\r\nif (socket \u003c 0) {\r\nprintf(\"Unable to open socket connection\");\r\nreturn(FAIL);\r\n}\r\nif (getNextMessage(socket, filename, FILENAME_SIZE) \u003e 0) {\r\nif (openFileToWrite(filename) \u003e 0) {\r\nwhile (getNextMessage(socket, buffer, BUFFER_SIZE) \u003e 0){\r\nif (!(writeToFile(buffer) \u003e 0))\r\nbreak;\r\n}\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 5 of 15\n\n}\r\ncloseFile();\r\n}\r\ncloseSocket(socket);\r\n}\r\nThis example creates a situation where data can be dumped to a file on the local file system without any limits on the size of\r\nthe file. This could potentially exhaust file or disk resources and/or limit other clients' ability to access the service.\r\nExample 4\r\nIn the following example, the processMessage method receives a two dimensional character array containing the message to\r\nbe processed. The two-dimensional character array contains the length of the message in the first character array and the\r\nmessage body in the second character array. The getMessageLength method retrieves the integer value of the length from the\r\nfirst character array. After validating that the message length is greater than zero, the body character array pointer points to\r\nthe start of the second character array of the two-dimensional character array and memory is allocated for the new body\r\ncharacter array.\r\n(bad code)\r\nExample Language: C \r\n/* process message accepts a two-dimensional character array of the form [length][body] containing the message to be\r\nprocessed */\r\nint processMessage(char **message)\r\n{\r\nchar *body;\r\nint length = getMessageLength(message[0]);\r\nif (length \u003e 0) {\r\nbody = \u0026message[1][0];\r\nprocessMessageBody(body);\r\nreturn(SUCCESS);\r\n}\r\nelse {\r\nprintf(\"Unable to process message; invalid message length\");\r\nreturn(FAIL);\r\n}\r\n}\r\nThis example creates a situation where the length of the body character array can be very large and will consume excessive\r\nmemory, exhausting system resources. This can be avoided by restricting the length of the second character array with a\r\nmaximum length check\r\nAlso, consider changing the type from 'int' to 'unsigned int', so that you are always guaranteed that the number is positive.\r\nThis might not be possible if the protocol specifically requires allowing negative values, or if you cannot control the return\r\nvalue from getMessageLength(), but it could simplify the check to ensure the input is positive, and eliminate other errors\r\nsuch as signed-to-unsigned conversion errors (CWE-195) that may occur elsewhere in the code.\r\n(good code)\r\nExample Language: C \r\nunsigned int length = getMessageLength(message[0]);\r\nif ((length \u003e 0) \u0026\u0026 (length \u003c MAX_LENGTH)) {...}\r\nExample 5\r\nIn the following example, a server object creates a server socket and accepts client connections to the socket. For every\r\nclient connection to the socket a separate thread object is generated using the ClientSocketThread class that handles request\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 6 of 15\n\nmade by the client through the socket.\r\n(bad code)\r\nExample Language: Java \r\npublic void acceptConnections() {\r\ntry {\r\nServerSocket serverSocket = new ServerSocket(SERVER_PORT);\r\nint counter = 0;\r\nboolean hasConnections = true;\r\nwhile (hasConnections) {\r\nSocket client = serverSocket.accept();\r\nThread t = new Thread(new ClientSocketThread(client));\r\nt.setName(client.getInetAddress().getHostName() + \":\" + counter++);\r\nt.start();\r\n}\r\nserverSocket.close();\r\n} catch (IOException ex) {...}\r\n}\r\nIn this example there is no limit to the number of client connections and client threads that are created. Allowing an\r\nunlimited number of client connections and threads could potentially overwhelm the system and system resources.\r\nThe server should limit the number of client connections and the client threads that are created. This can be easily done by\r\ncreating a thread pool object that limits the number of threads that are generated.\r\n(good code)\r\nExample Language: Java \r\npublic static final int SERVER_PORT = 4444;\r\npublic static final int MAX_CONNECTIONS = 10;\r\n...\r\npublic void acceptConnections() {\r\ntry {\r\nServerSocket serverSocket = new ServerSocket(SERVER_PORT);\r\nint counter = 0;\r\nboolean hasConnections = true;\r\nwhile (hasConnections) {\r\nhasConnections = checkForMoreConnections();\r\nSocket client = serverSocket.accept();\r\nThread t = new Thread(new ClientSocketThread(client));\r\nt.setName(client.getInetAddress().getHostName() + \":\" + counter++);\r\nExecutorService pool = Executors.newFixedThreadPool(MAX_CONNECTIONS);\r\npool.execute(t);\r\n}\r\nserverSocket.close();\r\n} catch (IOException ex) {...}\r\n}\r\nExample 6\r\nIn the following example, the serve function receives an http request and an http response writer. It reads the entire request\r\nbody.\r\n(bad code)\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 7 of 15\n\nExample Language: Go \r\nfunc serve(w http.ResponseWriter, r *http.Request) {\r\nvar body []byte\r\nif r.Body != nil {\r\nif data, err := io.ReadAll(r.Body); err == nil {\r\nbody = data\r\n}\r\n}\r\n}\r\nBecause ReadAll is defined to read from src until EOF, it does not treat an EOF from Read as an error to be reported. This\r\nexample creates a situation where the length of the body supplied can be very large and will consume excessive memory,\r\nexhausting system resources. This can be avoided by ensuring the body does not exceed a predetermined length of bytes.\r\nMaxBytesReader prevents clients from accidentally or maliciously sending a large request and wasting server resources. If\r\npossible, the code could be changed to tell ResponseWriter to close the connection after the limit has been reached.\r\n(good code)\r\nExample Language: Go \r\nfunc serve(w http.ResponseWriter, r *http.Request) {\r\nvar body []byte\r\nconst MaxRespBodyLength = 1e6\r\nif r.Body != nil {\r\nr.Body = http.MaxBytesReader(w, r.Body, MaxRespBodyLength)\r\nif data, err := io.ReadAll(r.Body); err == nil {\r\nbody = data\r\n}\r\n}\r\n}\r\n Selected Observed Examples\r\nNote: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced.\r\nIt is not a complete list of all CVEs that are related to this CWE entry.\r\nReference Description\r\nCVE-2019-\r\n19911\r\nChain: Python library does not limit the resources used to process images that specify a very large\r\nnumber of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer\r\noverflow (CWE-190).\r\nCVE-2020-\r\n7218\r\nGo-based workload orchestrator does not limit resource usage with unauthenticated connections,\r\nallowing a DoS by flooding the service\r\nCVE-2020-\r\n3566\r\nResource exhaustion in distributed OS because of \"insufficient\" IGMP queue management, as\r\nexploited in the wild per CISA KEV.\r\nCVE-2009-\r\n2874\r\nProduct allows attackers to cause a crash via a large number of connections.\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 8 of 15\n\nCVE-2009-\r\n1928 Malformed request triggers uncontrolled recursion, leading to stack exhaustion.\r\nCVE-2009-\r\n2858\r\nChain: memory leak (CWE-404) leads to resource exhaustion.\r\nCVE-2009-\r\n2726\r\nDriver does not use a maximum width when invoking sscanf style functions, causing stack\r\nconsumption.\r\nCVE-2009-\r\n2540\r\nLarge integer value for a length property in an object causes a large amount of memory allocation.\r\nCVE-2009-\r\n2299\r\nWeb application firewall consumes excessive memory when an HTTP request contains a large Content-Length value but no POST data.\r\nCVE-2009-\r\n2054\r\nProduct allows exhaustion of file descriptors when processing a large number of TCP packets.\r\nCVE-2008-\r\n5180\r\nCommunication product allows memory consumption with a large number of SIP requests, which\r\ncause many sessions to be created.\r\nCVE-2008-\r\n2121\r\nTCP implementation allows attackers to consume CPU and prevent new connections using a TCP SYN\r\nflood attack.\r\nCVE-2008-\r\n2122\r\nPort scan triggers CPU consumption with processes that attempt to read data from closed sockets.\r\nCVE-2008-\r\n1700\r\nProduct allows attackers to cause a denial of service via a large number of directives, each of which\r\nopens a separate window.\r\nCVE-2007-\r\n4103\r\nProduct allows resource exhaustion via a large number of calls that do not complete a 3-way\r\nhandshake.\r\nCVE-2006-\r\n1173\r\nMail server does not properly handle deeply nested multipart MIME messages, leading to stack\r\nexhaustion.\r\nCVE-2007-\r\n0897\r\nChain: anti-virus product encounters a malformed file but returns from a function without closing a file\r\ndescriptor (CWE-775) leading to file descriptor consumption (CWE-400) and failed scans.\r\n Weakness Ordinalities\r\nOrdinality Description\r\nPrimary (where the weakness exists independent of other weaknesses)\r\nResultant (where the weakness is typically related to the presence of some other weaknesses)\r\n Detection Methods\r\nMethod Details\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 9 of 15\n\nAutomated\r\nStatic Analysis\r\nAutomated static analysis typically has limited utility in recognizing resource exhaustion problems,\r\nexcept for program-independent system resources such as files, sockets, and processes. For system\r\nresources, automated static analysis may be able to detect circumstances in which resources are not\r\nreleased after they have expired. Automated analysis of configuration files may be able to detect\r\nsettings that do not specify a maximum value.\r\nAutomated static analysis tools will not be appropriate for detecting exhaustion of custom resources,\r\nsuch as an intended security policy in which a bulletin board user is only allowed to make a limited\r\nnumber of posts per day.\r\nEffectiveness: Limited\r\nAutomated\r\nDynamic\r\nAnalysis\r\nCertain automated dynamic analysis techniques may be effective in spotting resource exhaustion\r\nproblems, especially with resources such as processes, memory, and connections. The technique may\r\ninvolve generating a large number of requests to the product within a short time frame.\r\nEffectiveness: Moderate\r\nFuzzing\r\nWhile fuzzing is typically geared toward finding low-level implementation bugs, it can inadvertently\r\nfind resource exhaustion problems. This can occur when the fuzzer generates a large number of test\r\ncases but does not restart the targeted product in between test cases. If an individual test case\r\nproduces a crash, but it does not do so reliably, then an inability to handle resource exhaustion may be\r\nthe cause.\r\nEffectiveness: Opportunistic\r\n Memberships\r\nThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a\r\nmember. This information is often useful in understanding where a weakness fits within the context of external information\r\nsources.\r\nNature Type\r\nMemberOf Category - a CWE entry that contains a set of other entries that share a common characteristic.\r\nMemberOf Category - a CWE entry that contains a set of other entries that share a common characteristic.\r\nMemberOf Category - a CWE entry that contains a set of other entries that share a common characteristic.\r\nMemberOf View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and\r\nMemberOf Category - a CWE entry that contains a set of other entries that share a common characteristic.\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 10 of 15\n\nMemberOf Category - a CWE entry that contains a set of other entries that share a common characteristic.\r\nMemberOf Category - a CWE entry that contains a set of other entries that share a common characteristic.\r\nMemberOf View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and\r\nMemberOf View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and\r\nMemberOf View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and\r\nMemberOf Category - a CWE entry that contains a set of other entries that share a common characteristic.\r\nMemberOf View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and\r\n Vulnerability Mapping Notes\r\nUsage\r\nDISCOURAGED\r\n(this CWE ID should not be used to map to real-world vulnerabilities)\r\nReason Frequent Misuse\r\nRationale\r\nCWE-400 is intended for incorrect behaviors in which the product is expected to track and restrict how\r\nmany resources it consumes, but CWE-400 is often misused because it is conflated with the \"technical\r\nimpact\" of vulnerabilities in which resource consumption occurs. It is sometimes used for low-information vulnerability reports. It is a level-1 Class (i.e., a child of a Pillar).\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 11 of 15\n\nComments\r\nClosely analyze the specific mistake that is causing resource consumption, and perform a CWE mapping\r\nfor that mistake. Consider children/descendants such as CWE-770: Allocation of Resources Without\r\nLimits or Throttling, CWE-771: Missing Reference to Active Allocated Resource, CWE-410: Insufficient\r\nResource Pool, CWE-772: Missing Release of Resource after Effective Lifetime, CWE-834: Excessive\r\nIteration, CWE-405: Asymmetric Resource Consumption (Amplification), and others.\r\n Notes\r\nTheoretical\r\nVulnerability theory is largely about how behaviors and resources interact. \"Resource exhaustion\" can be regarded as either\r\na consequence or an attack, depending on the perspective. This entry is an attempt to reflect the underlying weaknesses that\r\nenable these attacks (or consequences) to take place.\r\nOther\r\nDatabase queries that take a long time to process are good DoS targets. An attacker would have to write a few lines of Perl\r\ncode to generate enough traffic to exceed the site's ability to keep up. This would effectively prevent authorized users from\r\nusing the site at all. Resources can be exploited simply by ensuring that the target machine must do much more work and\r\nconsume more resources in order to service a request than the attacker must do to initiate a request.\r\nA prime example of this can be found in old switches that were vulnerable to \"macof\" attacks (so named for a tool\r\ndeveloped by Dugsong). These attacks flooded a switch with random IP and MAC address combinations, therefore\r\nexhausting the switch's cache, which held the information of which port corresponded to which MAC addresses. Once this\r\ncache was exhausted, the switch would fail in an insecure way and would begin to act simply as a hub, broadcasting all\r\ntraffic on all ports and allowing for basic sniffing attacks.\r\nLimited resources include memory, file system storage, database connection pool entries, CPU, and others.\r\nMaintenance\r\n\"Resource consumption\" could be interpreted as a consequence instead of an insecure behavior, so this entry is being\r\nconsidered for modification. It appears to be referenced too frequently when more precise mappings are available. Some of\r\nits children, such as CWE-771, might be better considered as a chain.\r\n Taxonomy Mappings\r\nMapped Taxonomy Name Node ID Fit Mapped Node Name\r\nCLASP\r\nResource exhaustion (file descriptor,\r\ndisk space, sockets, ...)\r\nOWASP Top Ten 2004 A9\r\nCWE More\r\nSpecific\r\nDenial of Service\r\nWASC 10 Denial of Service\r\nWASC 41 XML Attribute Blowup\r\nThe CERT Oracle Secure Coding Standard\r\nfor Java (2011)\r\nSER12-J\r\nAvoid memory and resource leaks\r\nduring serialization\r\nThe CERT Oracle Secure Coding Standard\r\nfor Java (2011)\r\nMSC05-\r\nJ\r\nDo not exhaust heap space\r\nSoftware Fault Patterns SFP13 Unrestricted Consumption\r\nISA/IEC 62443 Part 3-3 Req SR 7.1\r\nISA/IEC 62443 Part 3-3 Req SR 7.2\r\nISA/IEC 62443 Part 4-1 Req SI-1\r\nISA/IEC 62443 Part 4-1 Req SVV-3\r\nISA/IEC 62443 Part 4-2 Req CR 7.1\r\nISA/IEC 62443 Part 4-2 Req CR 7.2\r\n References\r\n Content History\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 12 of 15\n\nSubmissions\r\nSubmission Date Submitter Organization\r\n2006-07-19\r\n(CWE Draft 3, 2006-07-19)\r\nCLASP\r\n Contributions\r\nContribution Date Contributor Organization\r\n2023-01-24\r\n(CWE 4.10, 2023-01-31)\r\n\"Mapping CWE to 62443\" Sub-Working Group CWE-CAPEC ICS/OT SIG\r\nSuggested mappings to ISA/IEC 62443.\r\n2023-04-25\r\n\"Mapping CWE to 62443\" Sub-Working Group CWE-CAPEC ICS/OT SIG\r\nSuggested mappings to ISA/IEC 62443.\r\n2025-02-25\r\n(CWE 4.17, 2025-04-03)\r\nAbhi Balakrishnan\r\nProvided diagram to improve CWE usability.\r\n Modifications\r\nModification Date Modifier Organization\r\n2025-12-11\r\n(CWE 4.19, 2025-12-11)\r\nCWE Content Team MITRE\r\nupdated Applicable_Platforms, Maintenance_Notes, Weakness_Ordinalities\r\n2025-09-09\r\n(CWE 4.18, 2025-09-09)\r\nCWE Content Team MITRE\r\nupdated Observed_Examples, References\r\n2025-04-03\r\n(CWE 4.17, 2025-04-03)\r\nCWE Content Team MITRE\r\nupdated Common_Consequences, Description, Diagram, Modes_of_Introduction,\r\nOther_Notes, Time_of_Introduction\r\n2024-11-19\r\n(CWE 4.16, 2024-11-19)\r\nCWE Content Team MITRE\r\nupdated Relationships\r\n2023-06-29\r\nCWE Content Team MITRE\r\nupdated Mapping_Notes, Relationships\r\n2023-04-27\r\nCWE Content Team MITRE\r\nupdated Demonstrative_Examples, Relationships, Taxonomy_Mappings\r\n2023-01-31\r\nCWE Content Team MITRE\r\nupdated Common_Consequences, Description, Detection_Factors, Maintenance_Notes,\r\nRelated_Attack_Patterns, Taxonomy_Mappings\r\n2022-10-13\r\nCWE Content Team MITRE\r\nupdated Observed_Examples, Relationships\r\n2022-06-28\r\nCWE Content Team MITRE\r\nupdated Observed_Examples, Relationships\r\n2022-04-28\r\nCWE Content Team MITRE\r\nupdated Related_Attack_Patterns\r\n2020-08-20\r\nCWE Content Team MITRE\r\nupdated Relationships\r\n2020-06-25\r\nCWE Content Team MITRE\r\nupdated Description, Maintenance_Notes\r\n2020-02-24 CWE Content Team MITRE\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 13 of 15\n\nSubmissions\r\nupdated Description, References, Related_Attack_Patterns, Relationships\r\n2019-09-19\r\nCWE Content Team MITRE\r\nupdated Description, Relationships\r\n2019-06-20\r\nCWE Content Team MITRE\r\nupdated Related_Attack_Patterns, Relationships\r\n2019-01-03\r\nCWE Content Team MITRE\r\nupdated Alternate_Terms, Description, Name, Relationships, Taxonomy_Mappings,\r\nTheoretical_Notes\r\n2018-03-27\r\nCWE Content Team MITRE\r\nupdated References, Type\r\n2017-11-08\r\nCWE Content Team MITRE\r\nupdated Applicable_Platforms, Demonstrative_Examples, Likelihood_of_Exploit,\r\nPotential_Mitigations, References, Relationships\r\n2017-01-19\r\nCWE Content Team MITRE\r\nupdated Relationships\r\n2015-12-07\r\nCWE Content Team MITRE\r\nupdated Related_Attack_Patterns, Relationships\r\n2014-07-30\r\nCWE Content Team MITRE\r\nupdated Relationships, Taxonomy_Mappings\r\n2013-07-17\r\nCWE Content Team MITRE\r\nupdated Relationships\r\n2012-05-11\r\nCWE Content Team MITRE\r\nupdated Demonstrative_Examples, Related_Attack_Patterns, Relationships,\r\nTaxonomy_Mappings\r\n2011-06-01\r\nCWE Content Team MITRE\r\nupdated Common_Consequences, Relationships, Taxonomy_Mappings\r\n2010-09-27\r\nCWE Content Team MITRE\r\nupdated Demonstrative_Examples\r\n2010-06-21\r\nCWE Content Team MITRE\r\nupdated Description\r\n2010-04-05\r\nCWE Content Team MITRE\r\nupdated Related_Attack_Patterns\r\n2010-02-16\r\nCWE Content Team MITRE\r\nupdated Detection_Factors, Potential_Mitigations, References, Taxonomy_Mappings\r\n2009-12-28\r\nCWE Content Team MITRE\r\nupdated Common_Consequences, Demonstrative_Examples, Detection_Factors,\r\nLikelihood_of_Exploit, Observed_Examples, Other_Notes, Potential_Mitigations,\r\nReferences\r\n2009-10-29\r\nCWE Content Team MITRE\r\nupdated Relationships\r\n2009-07-27 CWE Content Team MITRE\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 14 of 15\n\nSubmissions\r\nupdated Description, Relationships\r\n2009-05-27\r\nCWE Content Team MITRE\r\nupdated Name, Relationships\r\n2009-01-12\r\nCWE Content Team MITRE\r\nupdated Description\r\n2008-10-14\r\nCWE Content Team MITRE\r\nupdated Description, Name, Relationships\r\n2008-09-08\r\nCWE Content Team MITRE\r\nupdated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings\r\n2008-08-15\r\nVeracode\r\nSuggested OWASP Top Ten 2004 mapping\r\n2008-07-01\r\nEric Dalci Cigital\r\nupdated Time_of_Introduction\r\n Previous Entry Names\r\nChange Date Previous Entry Name\r\n2008-10-14 Resource Exhaustion\r\n2009-05-27 Uncontrolled Resource Consumption (aka 'Resource Exhaustion')\r\n2019-01-03 Uncontrolled Resource Consumption ('Resource Exhaustion')\r\nSource: http://cwe.mitre.org/data/definitions/400.html\r\nhttp://cwe.mitre.org/data/definitions/400.html\r\nPage 15 of 15\n\nfor Java (2011) Software Fault Patterns J SFP13 Unrestricted Consumption\nISA/IEC 62443 Part 3-3 Req SR 7.1\nISA/IEC 62443 Part 3-3 Req SR 7.2\nISA/IEC 62443 Part 4-1 Req SI-1\nISA/IEC 62443 Part 4-1 Req SVV-3\nISA/IEC 62443 Part 4-2 Req CR 7.1\nISA/IEC 62443 Part 4-2 Req CR 7.2\nReferences   \nContent History   \n Page 12 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"http://cwe.mitre.org/data/definitions/400.html"
	],
	"report_names": [
		"400.html"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775439142,
	"ts_updated_at": 1775791469,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/534fd5a95f37fbee7d71c70a535b0af45c845ac8.pdf",
		"text": "https://archive.orkl.eu/534fd5a95f37fbee7d71c70a535b0af45c845ac8.txt",
		"img": "https://archive.orkl.eu/534fd5a95f37fbee7d71c70a535b0af45c845ac8.jpg"
	}
}