Allocation of Resources Without Limits or Throttling

Summary: The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.

Manual static analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. If denial-of-service is not considered a significant risk, or if there is strong emphasis on consequences such as code execution, then manual analysis may not focus on this weakness at all.

Certain automated dynamic analysis techniques may be effective in producing side effects of uncontrolled resource allocation problems, especially with resources such as processes, memory, and connections. The technique may involve generating a large number of requests to the product within a short time frame. Manual analysis is likely required to interpret the results.

This entry is different from uncontrolled resource consumption (CWE-400) in that there are other weaknesses that are related to inability to control resource consumption, such as holding on to a resource too long after use, or not correctly keeping track of active resources so that they can be managed and released when they are finished (CWE-771).

Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.

When allocating resources without limits, an attacker could prevent other systems, applications, or processes from accessing the same type of resource.


Missing Reference to Active Allocated Resource

Summary: The product does not properly maintain a reference to a resource that has been allocated, which prevents the resource from being reclaimed.

An attacker that can influence the allocation of resources that are not properly maintained could deplete the available resource pool and prevent all other processes from accessing the same type of resource.


Missing Release of Resource after Effective Lifetime

Summary: The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.

"Resource exhaustion" (CWE-400) is currently treated as a weakness, although it is more like a category of weaknesses that all have the same type of consequence. While this entry treats CWE-400 as a parent in view 1000, the relationship is probably more appropriately described as a chain.

An attacker that can influence the allocation of resources that are not properly released could deplete the available resource pool and prevent all other processes from accessing the same type of resource.


Missing Reference to Active File Descriptor or Handle

Summary: The product does not properly maintain references to a file descriptor or handle, which prevents that file descriptor/handle from being reclaimed.


Allocation of File Descriptors or Handles Without Limits or Throttling

Summary: The product allocates file descriptors or handles on behalf of an actor without imposing any restrictions on how many descriptors can be allocated, in violation of the intended security policy for that actor.

When allocating resources without limits, an attacker could prevent all other processes from accessing the same type of resource.


Missing Release of File Descriptor or Handle after Effective Lifetime

Summary: The product does not release a file descriptor or handle after its effective lifetime has ended, i.e., after the file descriptor/handle is no longer needed.


Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')

XEE

XEE is the acronym commonly used for XML Entity Expansion.

XML Bomb

While the "XML Bomb" term was used in the early years of knowledge of this issue, the XEE term seems to be more commonly used.

Summary: The product uses XML documents and allows their structure to be defined with a Document Type Definition (DTD), but it does not properly control the number of recursive definitions of entities.

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

If parsed, recursive entity references allow the attacker to expand data exponentially, quickly consuming all system resources.


Regular Expression without Anchors

Summary: The product uses a regular expression to perform neutralization, but the regular expression is not anchored and may allow malicious or malformed data to slip through.

An unanchored regular expression in the context of an allowlist will possibly result in a protection mechanism failure, allowing malicious or malformed data to enter trusted regions of the program. The specific consequences will depend on what functionality the allowlist was protecting.


Insufficient Logging

Summary: When a security-critical event occurs, the product either does not record the event or omits important details about the event when logging it.

If security critical information is not recorded, there will be no trail for forensic analysis and discovering the cause of problems or the source of attacks may become more difficult or impossible.


Logging of Excessive Data

Summary: The product logs too much information, making log files hard to process and possibly hindering recovery efforts or forensic analysis after an attack.

Log files can become so large that they consume excessive resources, such as disk and CPU, which can hinder the performance of the system.

Logging too much information can make the log files of less use to forensics analysts and developers when trying to diagnose a problem or recover from an attack.

If system administrators are unable to effectively process log files, attempted attacks may go undetected, possibly leading to eventual system compromise.


Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

Summary: The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.

This weakness can be detected using dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Since this weakness does not typically appear frequently within a single software package, manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all potentially-vulnerable operations can be assessed within limited time constraints.

Automated Static Analysis - Binary or Bytecode

Dynamic Analysis with Automated Results Interpretation

Dynamic Analysis with Manual Results Interpretation

The "OS command injection" phrase carries different meanings to different people. For some people, it only refers to cases in which the attacker injects command separators into arguments for an application-controlled program that is being invoked. For some people, it refers to any type of attack that can allow the attacker to execute OS commands of their own choosing. This usage could include untrusted search path weaknesses (CWE-426) that cause the application to find and execute an attacker-controlled program. Further complicating the issue is the case when argument injection (CWE-88) allows alternate command-line switches or options to be inserted into the command line, such as an "-exec" switch whose purpose may be to execute the subsequent argument as a command (this -exec switch exists in the UNIX "find" command, for example). In this latter case, however, CWE-88 could be regarded as the primary weakness in a chain with CWE-78.

More investigation is needed into the distinction between the OS command injection variants, including the role with argument injection (CWE-88). Equivalent distinctions may exist in other injection-related problems such as SQL injection.

Attackers could execute unauthorized operating system commands, which could then be used to disable the product, or read and modify data for which the attacker does not have permissions to access directly. Since the targeted application is directly executing the commands instead of the attacker, any malicious activities may appear to come from the application or the application's owner.


Use of RSA Algorithm without OAEP

Summary: The product uses the RSA algorithm but does not incorporate Optimal Asymmetric Encryption Padding (OAEP), which might weaken the encryption.

This entry could probably have a new parent related to improper padding, however the role of padding in cryptographic algorithms can vary, such as hiding the length of the plaintext and providing additional random bits for the cipher. In general, cryptographic problems in CWE are not well organized and further research is needed.

Without OAEP in RSA encryption, it will take less work for an attacker to decrypt the data or to infer patterns from the ciphertext.


Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code

Summary: The product defines an IOCTL that uses METHOD_NEITHER for I/O, but it does not validate or incorrectly validates the addresses that are provided.

An attacker may be able to access memory that belongs to another process or user. If the attacker can control the contents that the IOCTL writes, it may lead to code execution at high privilege levels. At the least, a crash can occur.


Exposed IOCTL with Insufficient Access Control

Summary: The product implements an IOCTL with functionality that should be restricted, but it does not properly enforce access control for the IOCTL.

This can be primary to many other weaknesses when the programmer assumes that the IOCTL can only be accessed by trusted parties. For example, a program or driver might not validate incoming addresses in METHOD_NEITHER IOCTLs in Windows environments (CWE-781), which could allow buffer overflow and similar attacks to take place, even when the attacker never should have been able to access the IOCTL at all.

Attackers can invoke any functionality that the IOCTL offers. Depending on the functionality, the consequences may include code execution, denial-of-service, and theft of data.


Operator Precedence Logic Error

Summary: The product uses an expression in which operator precedence causes incorrect logic to be used.

The consequences will vary based on the context surrounding the incorrect precedence. In a security decision, integrity or confidentiality are the most likely results. Otherwise, a crash may occur due to the software reaching an unexpected state.


Reliance on Cookies without Validation and Integrity Checking in a Security Decision

Summary: The product uses a protection mechanism that relies on the existence or values of a cookie, but it does not properly ensure that the cookie is valid for the associated user.

A new parent might need to be defined for this entry. This entry is specific to cookies, which reflects the significant number of vulnerabilities being reported for cookie-based authentication in CVE during 2008 and 2009. However, other types of inputs - such as parameters or headers - could also be used for similar authentication or authorization. Similar issues (under the Research view) include CWE-247 and CWE-472.

It is dangerous to use cookies to set a user's privileges. The cookie can be manipulated to claim a high level of authorization, or to claim that successful authentication has occurred.


Use of Path Manipulation Function without Maximum-sized Buffer

Summary: The product invokes a function for normalizing paths or file names, but it provides an output buffer that is smaller than the maximum possible size, such as PATH_MAX.

This entry is at a much lower level of abstraction than most entries because it is function-specific. It also has significant overlap with other entries that can vary depending on the perspective. For example, incorrect usage could trigger either a stack-based overflow (CWE-121) or a heap-based overflow (CWE-122). The CWE team has not decided how to handle such entries.


Access of Memory Location Before Start of Buffer

Summary: The product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

For an out-of-bounds read, the attacker may have access to sensitive information. If the sensitive information contains system details, such as the current buffer's position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences.

Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash.

If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code. If the corrupted memory is data rather than instructions, the system will continue to function with improper changes, possibly in violation of an implicit or explicit policy.


Out-of-bounds Write

Memory Corruption

Often used to describe the consequences of writing to memory outside the bounds of a buffer, or to memory that is otherwise invalid.

Summary: The product writes data past the end, or before the beginning, of the intended buffer.

This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Write operations could cause memory corruption. In some cases, an adversary can modify control data such as return addresses in order to execute unexpected code.

Attempting to access out-of-range, invalid, or unauthorized memory could cause the product to crash.

Subsequent write operations can produce undefined or unexpected results.


Access of Memory Location After End of Buffer

Summary: The product reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer.

Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), they can redirect a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator.


Memory Allocation with Excessive Size Value

Stack Exhaustion

When a weakness allocates excessive memory on the stack, it is often described as "stack exhaustion," which is a technical impact of the weakness. This technical impact is often encountered as a consequence of CWE-789 and/or CWE-1325.

Summary: The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

This weakness can be closely associated with integer overflows (CWE-190). Integer overflow attacks would concentrate on providing an extremely large number that triggers an overflow that causes less memory to be allocated than expected. By providing a large value that does not trigger an integer overflow, the attacker could still cause excessive amounts of memory to be allocated.

Not controlling memory allocation can result in a request for too much system memory, possibly leading to a crash of the application due to out-of-memory conditions, or the consumption of a large amount of memory on the system.


Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

XSS

A common abbreviation for Cross-Site Scripting.

HTML Injection

Used as a synonym of stored (Type 2) XSS.

CSS

In the early years after initial discovery of XSS, "CSS" was a commonly-used acronym.  However, this would cause confusion with "Cascading Style Sheets," so usage of this acronym has declined significantly.

Summary: The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible, especially when multiple components are involved.

Use the XSS Cheat Sheet [REF-714] or automated test-generation tools to help launch a wide variety of attacks against your web application. The Cheat Sheet contains many subtle XSS variations that are specifically targeted against weak XSS defenses.

The most common attack performed with cross-site scripting involves the disclosure of information stored in user cookies. Typically, a malicious user will craft a client-side script, which -- when parsed by a web browser -- performs some activity (such as sending all site cookies to a given E-mail address). This script will be loaded and run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in question, the malicious script does also.

In some circumstances it may be possible to run arbitrary code on a victim's computer when cross-site scripting is combined with other flaws.

The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. Some cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running "Active X" controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.


Improper Filtering of Special Elements

Summary: The product receives data from an upstream component, but does not filter or incorrectly filters special elements before sending it to a downstream component.


Incomplete Filtering of Special Elements

Summary: The product receives data from an upstream component, but does not completely filter special elements before sending it to a downstream component.


Incomplete Filtering of One or More Instances of Special Elements

Summary: The product receives data from an upstream component, but does not completely filter one or more instances of special elements before sending it to a downstream component.


Only Filtering One Instance of a Special Element

Summary: The product receives data from an upstream component, but only filters a single instance of a special element before sending it to a downstream component.


Incomplete Filtering of Multiple Instances of Special Elements

Summary: The product receives data from an upstream component, but does not filter all instances of a special element before sending it to a downstream component.


Only Filtering Special Elements at a Specified Location

Summary: The product receives data from an upstream component, but only accounts for special elements at a specified location, thereby missing remaining special elements that may exist before sending it to a downstream component.


Only Filtering Special Elements Relative to a Marker

Summary: The product receives data from an upstream component, but only accounts for special elements positioned relative to a marker (e.g. "at the beginning/end of a string; the second argument"), thereby missing remaining special elements that may exist before sending it to a downstream component.


Only Filtering Special Elements at an Absolute Position

Summary: The product receives data from an upstream component, but only accounts for special elements at an absolute position (e.g. "byte number 10"), thereby missing remaining special elements that may exist before sending it to a downstream component.


Use of Hard-coded Credentials

Summary: The product contains hard-coded credentials, such as a password or cryptographic key.

Credential storage in configuration files is findable using black box methods, but the use of hard-coded credentials for an incoming authentication routine typically involves an account that is not visible outside of the code.

Automated white box techniques have been published for detecting hard-coded credentials for incoming authentication, but there is some expert disagreement regarding their effectiveness and applicability to a broad range of methods.

This weakness may be detectable using manual code analysis. Unless authentication is decentralized and applied throughout the product, there can be sufficient time for the analyst to find incoming authentication routines and examine the program logic looking for usage of hard-coded credentials. Configuration files could also be analyzed.

Manual Static Analysis - Binary or Bytecode

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.


Improper Control of Interaction Frequency

Insufficient anti-automation

The term "insufficient anti-automation" focuses primarly on non-human actors such as viruses or bots, but the scope of this CWE entry is broader.

Brute force

Vulnerabilities that can be targeted using brute force attacks are often symptomatic of this weakness.

Summary: The product does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests.


J2EE Misconfiguration: Entity Bean Declared Remote

Summary: When an application exposes a remote interface for an entity bean, it might also expose methods that get or set the bean's data. These methods could be leveraged to read sensitive information, or to change data in ways that violate the application's expectations, potentially leading to other vulnerabilities.

Entity beans that expose a remote interface become part of an application's attack surface. For performance reasons, an application should rarely use remote entity beans, so there is a good chance that a remote entity bean declaration is an error.


Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters such as "<", ">", and "&" that could be interpreted as web-scripting elements when they are sent to a downstream component that processes web pages.

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)


Guessable CAPTCHA

Summary: The product uses a CAPTCHA challenge, but the challenge can be guessed or automatically recognized by a non-human actor.

When authorization, authentication, or another protection mechanism relies on CAPTCHA entities to ensure that only human actors can access certain functionality, then an automated attacker such as a bot may access the restricted functionality by guessing the CAPTCHA.


Buffer Access with Incorrect Length Value

Summary: The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.

This weakness can be detected using dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. This can often be used to subvert any other security service.

Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.


Buffer Access Using Size of Source Buffer

Summary: The product uses the size of a source buffer when reading from or writing to a destination buffer, which may cause it to access memory that is outside of the bounds of the buffer.

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy.

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.


Reliance on Untrusted Inputs in a Security Decision

Summary: The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.

Since this weakness does not typically appear frequently within a single software package, manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all potentially-vulnerable operations can be assessed within limited time constraints.

Attackers can bypass the security decision to access whatever is being protected. The consequences will depend on the associated functionality, but they can range from granting additional privileges to untrusted users to bypassing important security checks. Ultimately, this weakness may lead to exposure or modification of sensitive data, system crash, or execution of arbitrary code.


Improper Neutralization of Script in an Error Message Web Page

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters that could be interpreted as web-scripting elements when they are sent to an error page.


Improper Neutralization of Script in Attributes of IMG Tags in a Web Page

Summary: The web application does not neutralize or incorrectly neutralizes scripting elements within attributes of HTML IMG tags, such as the src attribute.


Missing Synchronization

Summary: The product utilizes a shared resource in a concurrent manner but does not attempt to synchronize access to the resource.

Deeper research is necessary for synchronization and related mechanisms, including locks, mutexes, semaphores, and other mechanisms. Multiple entries are dependent on this research, which includes relationships to concurrency, race conditions, reentrant functions, etc.  CWE-662 and its children - including CWE-667, CWE-820, CWE-821, and others - may need to be modified significantly, along with their relationships.


Incorrect Synchronization

Summary: The product utilizes a shared resource in a concurrent manner, but it does not correctly synchronize access to the resource.


Untrusted Pointer Dereference

Summary: The product obtains a value from an untrusted source, converts this value to a pointer, and dereferences the resulting pointer.

There are close relationships between incorrect pointer dereferences and other weaknesses related to buffer operations. There may not be sufficient community agreement regarding these relationships. Further study is needed to determine when these relationships are chains, composites, perspective/layering, or other types of relationships. As of September 2010, most of the relationships are being captured as chains.

Many weaknesses related to pointer dereferences fall under the general term of "memory corruption" or "memory safety." As of September 2010, there is no commonly-used terminology that covers the lower-level variants.

If the untrusted pointer is used in a read operation, an attacker might be able to read sensitive portions of memory.

If the untrusted pointer references a memory location that is not accessible to the product, or points to a location that is "malformed" or larger than expected by a read or write operation, the application may terminate unexpectedly.

If the untrusted pointer is used in a function call, or points to unexpected data in a write operation, then code execution may be possible.


Use of Out-of-range Pointer Offset

Untrusted pointer offset

This term is narrower than the concept of "out-of-range" offset, since the offset might be the result of a calculation or other error that does not depend on any externally-supplied values.

Summary: The product performs pointer arithmetic on a valid pointer, but it uses an offset that can point outside of the intended range of valid memory locations for the resulting pointer.

If the untrusted pointer references a memory location that is not accessible to the program, or points to a location that is "malformed" or larger than expected by a read or write operation, the application may terminate unexpectedly.


Access of Uninitialized Pointer

Summary: The product accesses or uses a pointer that has not been initialized.

If the uninitialized pointer is used in a read operation, an attacker might be able to read sensitive portions of memory.

If the uninitialized pointer references a memory location that is not accessible to the product, or points to a location that is "malformed" (such as NULL) or larger than expected by a read or write operation, then a crash may occur.

If the uninitialized pointer is used in a function call, or points to unexpected data in a write operation, then code execution may be possible.


Expired Pointer Dereference

Summary: The product dereferences a pointer that contains a location for memory that was previously valid, but is no longer valid.

If the expired pointer is used in a read operation, an attacker might be able to control data read in by the application.

If the expired pointer references a memory location that is not accessible to the product, or points to a location that is "malformed" (such as NULL) or larger than expected by a read or write operation, then a crash may occur.

If the expired pointer is used in a function call, or points to unexpected data in a write operation, then code execution may be possible.


Premature Release of Resource During Expected Lifetime

Summary: The product releases a resource that is still intended to be used by itself or another actor.

Under-studied and under-reported as of September 2010. This weakness has been reported in high-visibility software, although the focus has been primarily on memory allocation and de-allocation. There are very few examples of this weakness that are not directly related to memory management, although such weaknesses are likely to occur in real-world software for other types of resources.

If the released resource is subsequently reused or reallocated, then a read operation on the original resource might access sensitive data that is associated with a different user or entity.

When the resource is released, the software might modify some of its structure, or close associated channels (such as a file descriptor). When the software later accesses the resource as if it is valid, the resource might not be in an expected state, leading to resultant errors that may lead to a crash.

When the resource is released, the software might modify some of its structure. This might affect logic in the sections of code that still assume the resource is active. If the released resource is related to memory and is used in a function call, or points to unexpected data in a write operation, then code execution may be possible upon subsequent accesses.


Improper Control of Document Type Definition

Summary: The product does not restrict a reference to a Document Type Definition (DTD) to the intended control sphere. This might allow attackers to reference arbitrary DTDs, possibly causing the product to expose files, consume excessive system resources, or execute arbitrary http requests on behalf of the attacker.

If the attacker is able to include a crafted DTD and a default entity resolver is enabled, the attacker may be able to access arbitrary files on the system.

The DTD may cause the parser to consume excessive CPU cycles or memory using techniques such as nested or recursive entity references (CWE-776).

The DTD may include arbitrary HTTP requests that the server may execute. This could lead to other attacks leveraging the server's trust relationship with other entities.


Signal Handler with Functionality that is not Asynchronous-Safe

Summary: The product defines a signal handler that contains code sequences that are not asynchronous-safe, i.e., the functionality is not reentrant, or it can be interrupted.

The most common consequence will be a corruption of the state of the product, possibly leading to a crash or exit. However, if the signal handler is operating on state variables for security relevant libraries or protection mechanisms, the consequences can be far more severe, including protection mechanism bypass, privilege escalation, or information exposure.


Inclusion of Functionality from Untrusted Control Sphere

Summary: The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.

An attacker could insert malicious functionality into the program by causing the program to download code that the attacker has placed into the untrusted control sphere, such as a malicious web site.


Improper Neutralization of Script in Attributes in a Web Page

Summary: The product does not neutralize or incorrectly neutralizes "javascript:" or other URIs from dangerous attributes within tags, such as onmouseover, onload, onerror, or style.


Inclusion of Web Functionality from an Untrusted Source

Summary: The product includes web functionality (such as a web widget) from another domain, which causes it to operate within the domain of the product, potentially granting total access and control of the product to the untrusted source.


Signal Handler Function Associated with Multiple Signals

Summary: The product defines a function that is used as a handler for more than one signal.


Unlock of a Resource that is not Locked

Summary: The product attempts to unlock a resource that is not locked.

Depending on the locking being used, an unlock operation might not have any adverse effects. When effects exist, the most common consequence will be a corruption of the state of the product, possibly leading to a crash or exit; depending on the implementation of the unlocking, memory corruption or code execution could occur.


Deadlock

Summary: The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.

Each thread of execution will "hang" and prevent tasks from completing. In some cases, CPU consumption may occur if a lock check occurs in a tight loop.


Excessive Iteration

Summary: The product performs an iteration or loop without sufficiently limiting the number of times that the loop is executed.

Excessive looping will cause unexpected consumption of resources, such as CPU cycles or memory. The product's operation may slow down, or cause a long time to respond. If limited resources such as memory are consumed for each iteration, the loop may eventually cause a crash or program exit due to exhaustion of resources, such as an out-of-memory error.


Loop with Unreachable Exit Condition ('Infinite Loop')

Summary: The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.

An infinite loop will cause unexpected consumption of resources, such as CPU cycles or memory. The software's operation may slow down, or cause a long time to respond.


Use of Password Hash Instead of Password for Authentication

Summary: The product records password hashes in a data store, receives a hash of a password from a client, and compares the supplied hash to the hash obtained from the data store.

An attacker could bypass the authentication routine without knowing the original password.


Improper Enforcement of a Single, Unique Action

Summary: The product requires that an actor should only be able to perform an action once, or to have only one unique action, but the product does not enforce or improperly enforces this restriction.

An attacker might be able to gain advantage over other users by performing the action multiple times, or affect the correctness of the product.


Inappropriate Encoding for Output Context

Summary: The product uses or specifies an encoding when generating output to a downstream component, but the specified encoding is not the same as the encoding that is expected by the downstream component.

An attacker could modify the structure of the message or data being sent to the downstream component, possibly injecting commands.


Numeric Range Comparison Without Minimum Check

Signed comparison

The "signed comparison" term is often used to describe when the product uses a signed variable and checks it to ensure that it is less than a maximum value (typically a maximum buffer size), but does not verify that it is greater than 0.

Summary: The product checks a value to ensure that it is less than or equal to a maximum, but it does not also verify that the value is greater than or equal to the minimum.

in some contexts, a negative value could lead to resource consumption.

If a negative value is used to access memory, buffers, or other indexable structures, it could access memory outside the bounds of the buffer.


Improper Neutralization of Encoded URI Schemes in a Web Page

Summary: The web application improperly neutralizes user-controlled input for executable script disguised with URI encodings.


Improper Enforcement of Behavioral Workflow

Summary: The product supports a session in which more than one behavior must be performed by an actor, but it does not properly ensure that the actor performs the behaviors in the required sequence.

An attacker could cause the product to skip critical steps or perform them in the wrong order, bypassing its intended business logic. This can sometimes have security implications.


Placement of User into Incorrect Group

Summary: The product or the administrator places a user into an incorrect group.


Access of Resource Using Incompatible Type ('Type Confusion')

Summary: The product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.

When a memory buffer is accessed using the wrong type, it could read or write memory out of the bounds of the buffer, if the allocated buffer is smaller than the type that the code is attempting to access, leading to a crash and possibly code execution.


Doubled Character XSS Manipulations

Summary: The web application does not filter user-controlled input for executable script disguised using doubling of the involved characters.


Improper Neutralization of Invalid Characters in Identifiers in Web Pages

Summary: The product does not neutralize or incorrectly neutralizes invalid characters or byte sequences in the middle of tag names, URI schemes, and other identifiers.


Missing Authorization

AuthZ

"AuthZ" is typically used as an abbreviation of "authorization" within the web application security community. It is distinct from "AuthN" (or, sometimes, "AuthC") which is an abbreviation of "authentication." The use of "Auth" as an abbreviation is discouraged, since it could be used for either authentication or authorization.

Summary: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic.

Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.

An attacker could read sensitive data, either by reading the data directly from a data store that is not restricted, or by accessing insufficiently-protected, privileged functionality to read the data.

An attacker could modify sensitive data, either by writing the data directly to a data store that is not restricted, or by accessing insufficiently-protected, privileged functionality to write the data.

An attacker could gain privileges by modifying or reading critical data directly, or by accessing privileged functionality.

An attacker could gain unauthorized access to resources on the system and excessively consume those resources, leading to a denial of service.


Incorrect Authorization

Summary: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

Automated dynamic analysis may not be able to find interfaces that are protected by authorization checks, even if those checks contain weaknesses.

An attacker could bypass intended access restrictions to read sensitive data, either by reading the data directly from a data store that is not correctly restricted, or by accessing insufficiently-protected, privileged functionality to read the data.

An attacker could bypass intended access restrictions to modify sensitive data, either by writing the data directly to a data store that is not correctly restricted, or by accessing insufficiently-protected, privileged functionality to write the data.

An attacker could bypass intended access restrictions to gain privileges by modifying or reading critical data directly, or by accessing privileged functionality.

An attacker could use elevated privileges to execute unauthorized commands or code.


Improper Neutralization of Alternate XSS Syntax

Summary: The product does not neutralize or incorrectly neutralizes user-controlled input for alternate script syntax.


Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')

Summary:
The product constructs a string for a command to be executed by a separate component
in another control sphere, but it does not properly delimit the
intended arguments, options, or switches within that command string.

At one layer of abstraction, this can overlap other weaknesses that have whitespace problems, e.g. injection of javascript into attributes of HTML tags.

An attacker could include arguments that allow unintended commands or code to be executed, allow sensitive data to be read or modified or could cause other unintended behavior.


Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

SQL injection

a common attack-oriented phrase

SQLi

a common abbreviation for "SQL injection"

Summary: The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

SQL injection can be resultant from special character mismanagement, MAID, or denylist/allowlist problems. It can be primary to authentication errors.

Adversaries could execute system commands, typically by changing the SQL statement to redirect output to a file that can then be executed.

Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.

If poor SQL commands are used to check user names and passwords or perform other kinds of authentication, it may be possible to connect to the product as another user with no previous knowledge of the password.

If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability.

Just as it may be possible to read sensitive information, it is also possible to modify or even delete this information with a SQL injection attack.


J2EE Misconfiguration: Weak Access Permissions for EJB Methods

Summary: If elevated access rights are assigned to EJB methods, then an attacker can take advantage of the permissions to exploit the product.


Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')

Summary: The product constructs all or part of an LDAP query using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended LDAP query when it is sent to a downstream component.

Factors: resultant to special character mismanagement, MAID, or denylist/allowlist problems. Can be primary to authentication and verification errors.

An attacker could include input that changes the LDAP query which allows unintended commands or code to be executed, allows sensitive data to be read or modified or causes other unintended behavior.


Use of Uninitialized Resource

Summary: The product uses or accesses a resource that has not been initialized.

When reusing a resource such as memory or a program variable, the original contents of that resource may not be cleared before it is sent to an untrusted party.

The uninitialized resource may contain values that cause program flow to change in ways that the programmer did not intend.


Missing Initialization of Resource

Summary: The product does not initialize a critical resource.


XML Injection (aka Blind XPath Injection)

Summary: The product does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.

The description for this entry is generally applicable to XML, but the name includes "blind XPath injection" which is more closely associated with CWE-643. Therefore this entry might need to be deprecated or converted to a general category - although injection into raw XML is not covered by CWE-643 or CWE-652.

In vulnerability theory terms, this is a representation-specific case of a Data/Directive Boundary Error.

Under-reported. This is likely found regularly by third party code auditors, but there are very few publicly reported examples.


Use of Expired File Descriptor

Summary: The product uses or accesses a file descriptor after it has been closed.

The program could read data from the wrong file.

Accessing a file descriptor that has been closed can cause a crash.


Improper Update of Reference Count

Summary: The product uses a reference count to manage a resource, but it does not update or incorrectly updates the reference count.


Hidden Functionality

Summary: The product contains functionality that is not documented, not part of the specification, and not accessible through an interface or command sequence that is obvious to the product's users or administrators.


Improper Control of Dynamically-Managed Code Resources

Summary: The product does not properly restrict reading from or writing to dynamically-managed code resources such as variables, objects, classes, attributes, functions, or executable instructions or statements.

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.


Improper Control of Dynamically-Identified Variables

Summary: The product does not properly restrict reading from or writing to dynamically-identified variables.

An attacker could modify sensitive data or program variables.


Improperly Controlled Modification of Dynamically-Determined Object Attributes

Mass Assignment

"Mass assignment" is the name of a feature in Ruby on Rails that allows simultaneous modification of multiple object attributes.

AutoBinding

The "Autobinding" term is used in frameworks such as Spring MVC and ASP.NET MVC.

PHP Object Injection

Some PHP application researchers use this term for attacking unsafe use of the unserialize() function, but it is also used for CWE-502.

Summary: The product receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified.

The relationships between CWE-502 and CWE-915 need further exploration. CWE-915 is more narrowly scoped to object modification, and is not necessarily used for deserialization.


Use of Password Hash With Insufficient Computational Effort

Summary: The product generates a hash for a password, but it uses a scheme that does not provide a sufficient level of computational effort that would make password cracking attacks infeasible or expensive.

If an attacker can gain access to the hashes, then the lack of sufficient computational effort will make it easier to conduct brute force attacks using techniques such as rainbow tables, or specialized hardware such as GPUs, which can be much faster than general-purpose CPUs for computing hashes.


Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')

Summary: The product constructs all or part of an expression language (EL) statement in a framework such as a Java Server Page (JSP) using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended EL statement before it is executed.

The interrelationships and differences between CWE-917 and CWE-1336 need to be further clarified.

In certain versions of Spring 3.0.5 and earlier, there was a vulnerability (CVE-2011-2730) in which Expression Language tags would be evaluated twice, which effectively exposed any application to EL injection. However, even for later versions, this weakness is still possible depending on configuration.


Server-Side Request Forgery (SSRF)

XSPA

Cross Site Port Attack

SSRF

Server-Side Request Forgery

Summary: 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.

CWE-918 (SSRF) and CWE-611 (XXE) are closely related, because they both involve web-related technologies and can launch outbound requests to unexpected destinations. However, XXE can be performed client-side, or in other contexts in which the software is not acting directly as a server, so the "Server" portion of the SSRF acronym does not necessarily apply.

By providing URLs to unexpected hosts or ports, attackers can make it appear that the server is sending the request, possibly bypassing access controls such as firewalls that prevent the attackers from accessing the URLs directly. The server can be used as a proxy to conduct port scanning of hosts in internal networks, use other URLs such as that can access documents on the system (using file://), or use other protocols such as gopher:// or tftp://, which may provide greater control over the contents of requests.


DEPRECATED: Improper Sanitization of Custom Special Characters

Summary: This entry has been deprecated. It originally came from PLOVER, which sometimes defined "other" and "miscellaneous" categories in order to satisfy exhaustiveness requirements for taxonomies. Within the context of CWE, the use of a more abstract entry is preferred in mapping situations. CWE-75 is a more appropriate mapping.


Improper Restriction of Power Consumption

Summary: The product operates in an environment in which power is a limited resource that cannot be automatically replenished, but the product does not properly restrict the amount of power that its operation consumes.

The power source could be drained, causing the application - and the entire device - to cease functioning.


Storage of Sensitive Data in a Mechanism without Access Control

Summary: The product stores sensitive information in a file system or device that does not have built-in access control.

Attackers can read sensitive information by accessing the unrestricted storage mechanism.

Attackers can modify or delete sensitive information by accessing the unrestricted storage mechanism.


Insecure Storage of Sensitive Information

Summary: The product stores sensitive information without properly limiting read or write access by unauthorized actors.

There is an overlapping relationship between insecure storage of sensitive information (CWE-922) and missing encryption of sensitive information (CWE-311). Encryption is often used to prevent an attacker from reading the sensitive data. However, encryption does not prevent the attacker from erasing or overwriting the data. While data tampering would be visible upon inspection, the integrity and availability of the data is compromised prior to the audit.

This is a high-level entry that includes children from various parts of the CWE research view (CWE-1000). Currently, most of the information is in these child entries. This entry will be made more comprehensive in later CWE versions.

Attackers can overwrite sensitive information by accessing the unrestricted storage mechanism.


Improper Restriction of Communication Channel to Intended Endpoints

Summary: The product establishes a communication channel to (or from) an endpoint for privileged or protected operations, but it does not properly ensure that it is communicating with the correct endpoint.

If an attacker can spoof the endpoint, the attacker gains all the privileges that were intended for the original endpoint.


Improper Enforcement of Message Integrity During Transmission in a Communication Channel

Summary: The product establishes a communication channel with an endpoint and receives a message from that endpoint, but it does not sufficiently ensure that the message was not modified during transmission.

This entry should be made more comprehensive in later CWE versions, as it is likely an important design flaw that underlies (or chains to) other weaknesses.

If an attackers can spoof the endpoint, the attacker gains all the privileges that were intended for the original endpoint.


Improper Verification of Intent by Broadcast Receiver

Summary: The Android application uses a Broadcast Receiver that receives an Intent but does not properly verify that the Intent came from an authorized source.

This entry will be made more comprehensive in later CWE versions.

Another application can impersonate the operating system and cause the software to perform an unintended action.


Improper Export of Android Application Components

Summary: The Android application exports a component for use by other applications, but does not properly restrict which applications can launch the component or access the data it contains.

Other applications, possibly untrusted, can launch the Activity.

Other applications, possibly untrusted, can bind to the Service.

Other applications, possibly untrusted, can read or modify the data that is offered by the Content Provider.


Use of Implicit Intent for Sensitive Communication

Summary: The Android application uses an implicit intent for transmitting sensitive data to other applications.

Other applications, possibly untrusted, can read the data that is offered through the Intent.

The application may handle responses from untrusted applications on the device, which could cause it to perform unexpected or unauthorized actions.


Improper Neutralization of CRLF Sequences ('CRLF Injection')

Summary: The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.


Improper Authorization in Handler for Custom URL Scheme

Summary: The product uses a handler for a custom URL scheme, but it does not properly restrict which actors can invoke the handler using the scheme.


Improper Control of Generation of Code ('Code Injection')

Summary: The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

In some cases, injectable code controls authentication; this may lead to a remote vulnerability.

Injected code can access resources that the attacker is directly prevented from accessing.

Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.

Often the actions performed by injected control code are unlogged.


Improper Verification of Source of a Communication Channel

Summary: The product establishes a communication channel to handle an incoming request that has been initiated by an actor, but it does not properly verify that the request is coming from the expected origin.

While many access control issues involve authenticating the user, this weakness is more about authenticating the actual source of the communication channel itself; there might not be any "user" in such cases.

An attacker can access any functionality that is inadvertently accessible to the source.


Incorrectly Specified Destination in a Communication Channel

Summary: The product creates a communication channel to initiate an outgoing request to an actor, but it does not correctly specify the intended destination for that actor.


Permissive Cross-domain Policy with Untrusted Domains

Summary: The product uses a cross-domain policy file that includes domains that should not be trusted.

An attacker may be able to bypass the web browser's same-origin policy. An attacker can exploit the weakness to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running ActiveX controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.


Improper Neutralization of Special Elements in Data Query Logic

Summary: The product generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the intended logic of the query.

It could be argued that data query languages are effectively a command language - albeit with a limited set of commands - and thus any query-language injection issue could be treated as a child of CWE-74. However, CWE-943 is intended to better organize query-oriented issues to separate them from fully-functioning programming languages, and also to provide a more precise identifier for the many query languages that do not have their own CWE identifier.


Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").

Factors: special character errors can play a role in increasing the variety of code that can be injected, although some vulnerabilities do not require special characters at all, e.g. when a single function without arguments can be referenced and a terminator character is not necessary.

The injected code could access restricted data / files.


Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before inserting the input into an executable resource, such as a library, configuration file, or template.

"HTML injection" (see CWE-79: XSS) could be thought of as an example of this, but the code is injected and executed on the client side, not the server side. Server-Side Includes (SSI) are an example of direct static code injection.


Improper Neutralization of Server-Side Includes (SSI) Within a Web Page

Summary: The product generates a web page, but does not neutralize or incorrectly neutralizes user-controllable input that could be interpreted as a server-side include (SSI) directive.

This can be resultant from XSS/HTML injection because the same special characters can be involved. However, this is server-side code execution, not client-side.


Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')

RFI

The Remote File Inclusion (RFI) acronym is often used by vulnerability researchers.

Local file inclusion

This term is frequently used in cases in which remote download is disabled, or when the first part of the filename is not under the attacker's control, which forces use of relative path traversal (CWE-23) attack techniques to access files that may contain previously-injected PHP code, such as web access logs.

Summary: The PHP application receives input from an upstream component, but it does not restrict or incorrectly restricts the input before its usage in "require," "include," or similar functions.

Manual white-box analysis can be very effective for finding this issue, since there is typically a relatively small number of include or require statements in each program.

The attacker may be able to specify arbitrary code to be executed from a remote location. Alternatively, it may be possible to use normal program behavior to insert php code into files on the local machine which can then be included and force the code to execute since php ignores everything in the file except for the content between php specifiers.


Improper Control of Resource Identifiers ('Resource Injection')

Insecure Direct Object Reference

OWASP uses this term, although it is effectively the same as resource injection.

Summary: The product receives input from an upstream component, but it does not restrict or incorrectly restricts the input before it is used as an identifier for a resource that may be outside the intended sphere of control.

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Resource injection that involves resources stored on the filesystem goes by the name path manipulation (CWE-73).

The relationship between CWE-99 and CWE-610 needs further investigation and clarification. They might be duplicates. CWE-99 "Resource Injection," as originally defined in Seven Pernicious Kingdoms taxonomy, emphasizes the "identifier used to access a system resource" such as a file name or port number, yet it explicitly states that the "resource injection" term does not apply to "path manipulation," which effectively identifies the path at which a resource can be found and could be considered to be one aspect of a resource identifier. Also, CWE-610 effectively covers any type of resource, whether that resource is at the system layer, the application layer, or the code layer.

An attacker could gain access to or modify sensitive data or system resources. This could allow access to protected files or directories including configuration files and files containing sensitive information.