Improperly Controlled Sequential Memory Allocation

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 manages a group of objects or resources and performs a separate memory allocation for each object, but it does not properly limit the total amount of memory that is consumed by all of the combined objects.

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.


Missing Immutable Root of Trust in Hardware

Summary: A missing immutable root of trust in the hardware results in the ability to bypass secure boot or execute untrusted or adversarial boot code.

Automated testing can verify that RoT components are immutable.

Root of trust elements and memory should be part of architecture and design reviews.


Binding to an Unrestricted IP Address

Summary: The product assigns the address 0.0.0.0 for a database server, a cloud service/instance, or any computing resource that communicates remotely.


Security Version Number Mutable to Older Versions

Summary: Security-version number in hardware is mutable, resulting in the ability to downgrade (roll-back) the boot firmware to vulnerable code versions.

Mutability of stored security version numbers and programming with older firmware images should be part of automated testing.

Anti-roll-back features should be reviewed as part of Architecture or Design review.

Impact includes roll-back or downgrade to a vulnerable version of the firmware or DoS (prevent upgrades).


Reliance on Component That is Not Updateable

Summary: The product contains a component that cannot be updated or patched in order to remove vulnerabilities or significant bugs.

Check the consumer or maintainer documentation, the architecture/design documentation, or the original requirements to ensure that the documentation includes details for how to update the firmware.

If an attacker can identify an exploitable vulnerability in one product that has no means of patching, the attack may be used against all affected versions of that product.


Remanent Data Readable after Memory Erase

Summary: Confidential information stored in memory circuits is readable or recoverable after being cleared or erased.

Dynamic Analysis with Manual Results Interpretation

Confidential data are readable to untrusted agent.


Improper Isolation of Shared Resources in Network On Chip (NoC)

Summary: The Network On Chip (NoC) does not isolate or incorrectly isolates its on-chip-fabric and internal resources such that they are shared between trusted and untrusted agents, creating timing channels.

Providing marker flags to send through the interfaces coupled with examination of which users are able to read or manipulate the flags will help verify that the proper isolation has been achieved and is effective.

Attackers may infer data that belongs to a trusted agent. The methods used to perform this attack may result in noticeably increased resource consumption.


Improper Handling of Faults that Lead to Instruction Skips

Summary: The device is missing or incorrectly implements circuitry or sensors that detect and mitigate the skipping of security-critical CPU instructions when they occur.

This weakness can be found using automated static analysis once a developer has indicated which code paths are critical to protect.

This weakness can be found using automated dynamic analysis. Both emulation of a CPU with instruction skips, as well as RTL simulation of a CPU IP, can indicate parts of the code that are sensitive to faults due to instruction skips.

This weakness can be found using manual (static) analysis. The analyst has security objectives that are matched against the high-level code. This method is less precise than emulation, especially if the analysis is done at the higher level language rather than at assembly level.

Depending on the context, instruction skipping can
                        have a broad range of consequences related to the
                        generic bypassing of security critical code.


Inefficient Regular Expression Complexity

ReDoS

ReDoS is an abbreviation of "Regular expression Denial of Service".

Regular Expression Denial of Service

While this term is attack-focused, this is commonly used to describe the weakness.

Catastrophic backtracking

This term is used to describe the behavior of the regular expression as a negative technical impact.

Summary: The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles.


Unauthorized Error Injection Can Degrade Hardware Redundancy

Summary: An unauthorized agent can inject errors into a redundant block to deprive the system of redundancy or put the system in a degraded operating mode.


Incorrect Bitwise Shift of Integer

Summary: An integer value is specified to be shifted by a negative amount or an amount greater than or equal to the number of bits contained in the value causing an unexpected or indeterminate result.


Improper Neutralization of Special Elements Used in a Template Engine

Server-Side Template Injection / SSTI

This term is used for injection into template engines being used by a server.

Client-Side Template Injection / CSTI

This term is used for injection into template engines being used by a client.

Summary: The product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine.

Since expression languages are often used in templating languages, there may be some overlap with CWE-917 (Expression Language Injection). XSS (CWE-79) is also co-located with template injection.

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


Improper Protections Against Hardware Overheating

Summary: A hardware device is missing or has inadequate protection features to prevent overheating.

Dynamic tests should be performed to stress-test temperature controls.

Power management controls should be part of Architecture and Design reviews.


Insufficient Precision or Accuracy of a Real Number

Summary: The product processes a real number with an implementation in which the number's representation does not preserve required accuracy and precision in its fractional part, causing an incorrect result.

This weakness will generally lead to undefined results and therefore crashes. In some implementations the program will halt if the weakness causes an overflow during a calculation.

The results of the math are not as expected. This could cause issues where a value would not be properly calculated and provide an incorrect answer.

This weakness can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a product's implicit security policy.


Use of Externally-Controlled Format String

Summary: The product uses a function that accepts a format string as an argument, but the format string originates from an external source.

This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

Since format strings often occur in rarely-occurring erroneous conditions (e.g. for error message logging), they can be difficult to detect using black box methods. It is highly likely that many latent issues exist in executables that do not have associated source code (or equivalent source.

Automated Static Analysis - Binary or Bytecode

Manual Static Analysis - Binary or Bytecode

Dynamic Analysis with Automated Results Interpretation

Format string issues are under-studied for languages other than C. Memory or disk consumption, control flow or variable alteration, and data corruption may result from format string exploitation in applications written in other languages such as Perl, PHP, Python, etc.

Format string problems allow for information disclosure which can severely simplify exploitation of the program.

Format string problems can result in the execution of arbitrary code.


Multiple Releases of Same Resource or Handle

Summary: The product attempts to close or release a resource or handle more than once, without any successful open between the close operations.

For commonly-used APIs and resource types, automated tools often have signatures that can spot this issue.

Some compiler instrumentation tools such as AddressSanitizer (ASan) can indirectly detect some instances of this weakness.

The terms related to "release"  may vary depending on the type of resource, programming language, specification, or framework. "Close" has been used synonymously for the release of resources like file descriptors and file handles. "Return" is sometimes used instead of Release. "Free" is typically used when releasing memory or buffers back into the system for reuse.


Information Exposure through Microarchitectural State after Transient Execution

Summary: The processor does not properly clear microarchitectural state after incorrect microcode assists or speculative execution, resulting in transient execution.

CWE-1342 differs from CWE-1303, which is related to misprediction and biasing microarchitectural components, while CWE-1342 addresses illegal data flows and retention. For example, Spectre is an instance of CWE-1303 biasing branch prediction to steer the transient execution indirectly.

As of CWE 4.9, members of the CWE Hardware SIG are closely analyzing this entry and others to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks. Additional investigation may include other weaknesses related to microarchitectural state. As a result, this entry might change significantly in CWE 4.10.


Incorrect Calculation of Multi-Byte String Length

Summary: The product does not correctly calculate the length of strings that can contain wide or multi-byte characters.

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.)

This weakness may lead to a buffer overflow. 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.

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.

In the case of 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.


Improper Handling of Hardware Behavior in Exceptionally Cold Environments

Summary:
A hardware device, or the firmware running on it, is
                missing or has incorrect protection features to maintain
                goals of security primitives when the device is cooled below
                standard operating temperatures.

Consequences of this weakness are highly contextual.


Reliance on Insufficiently Trustworthy Component

Summary: The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.

As of CWE 4.10, the name and description for this entry has undergone significant change and is still under public discussion, especially by members of the HW SIG.


Improper Neutralization of Special Elements

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as control elements or syntactic markers when they are sent to a downstream component.

This weakness can be related to interpretation conflicts or interaction errors in intermediaries (such as proxies or application firewalls) when the intermediary's model of an endpoint does not account for protocol-specific special elements.

See this entry's children for different types of special elements that have been observed at one point or another. However, it can be difficult to find suitable CVE examples. In an attempt to be complete, CWE includes some types that do not have any associated observed example.

This weakness is probably under-studied for proprietary or custom formats. It is likely that these issues are fairly common in applications that use their own custom format for configuration files, logs, meta-data, messaging, etc. They would only be found by accident or with a focused effort based on an understanding of the format.


Improper Handling of Physical or Environmental Conditions

Summary: The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.

Consequences of this weakness are highly dependent on the role of affected components within the larger product.


Missing Origin Validation in WebSockets

Cross-Site WebSocket hijacking (CSWSH)

this term is used for attacks that exploit this weakness

Summary: The product uses a WebSocket, but it does not properly verify that the source of data or communication is valid.

The consequences will vary depending on the nature of the functionality that is vulnerable to CSRF. An attacker could effectively perform any operations as the victim. If the victim is an administrator or privileged user, the consequences may include obtaining complete control over the web application - deleting or stealing data, uninstalling the product, or using it to launch other attacks against all of the product's users. Because the attacker has the identity of the victim, the scope of the CSRF is limited only by the victim's privileges.


Insecure Operation on Windows Junction / Mount Point

Summary: The product opens a file or directory, but it does not properly prevent the name from being associated with a junction or mount point to a destination that is outside of the intended control sphere.

Symbolic links, hard links, junctions, and mount points can be confusing terminology, as there are differences in how they operate between UNIX-based systems and Windows, and there are interactions between them.

This entry is still under development and will continue to see updates and content improvements.

Read arbitrary files by replacing a user-controlled folder with a mount point and additional hard links.

Modify an arbitrary file by replacing the rollback files in installer directories, as they can have the installer execute those rollbacks.

Even if there is no control of contents, an arbitrary file delete or overwrite (when running as SYSTEM or admin) can be used for a permanent system denial-of-service, e.g. by deleting a startup configuration file that prevents the service from starting.


Incorrect Parsing of Numbers with Different Radices

Summary: The product parses numeric input assuming base 10 (decimal) values, but it does not account for inputs that use a different base number (radix).

An attacker may use an unexpected numerical base to access private application resources.

An attacker may use an unexpected numerical base to bypass or manipulate access control mechanisms.


Weak Authentication

Summary: The product uses an authentication mechanism to restrict access to specific users or identities, but the mechanism does not sufficiently prove that the claimed identity is correct.

This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.


Use of Weak Credentials

Summary: The product uses weak credentials (such as a default key or hard-coded password) that can be calculated, derived, reused, or guessed by an attacker.


Use of Default Credentials

Summary: The product uses default credentials (such as passwords or cryptographic keys) for potentially critical functionality.


Use of Default Password

Summary: The product uses default passwords for potentially critical functionality.


Use of Default Cryptographic Key

Summary: The product uses a default cryptographic key for potentially critical functionality.


Dependency on Vulnerable Third-Party Component

Summary: The product has a dependency on a third-party component that contains one or more known vulnerabilities.

For software, use Software Composition Analysis (SCA) tools, which automatically analyze products to identify third-party dependencies. Often, SCA tools can be used to link with known vulnerabilities in the dependencies that they detect. There are commercial and open-source alternatives, such as OWASP Dependency-Check [REF-1312]. Many languages or frameworks have package managers with similar capabilities, such as npm audit for JavaScript, pip-audit for Python, govulncheck for Go, and many others. Dynamic methods can detect loading of third-party components.

The consequences vary widely, depending on the vulnerabilities that exist in the component; how those vulnerabilities can be "reached" by adversaries, as the exploitation paths and attack surface will vary depending on how the component is used; and the criticality of the privilege levels and features for which the product relies on the component.


Compiler Removal of Code to Clear Buffers

Summary: Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."

This specific weakness is impossible to detect using black box methods. While an analyst could examine memory to see that it has not been scrubbed, an analysis of the executable would not be successful. This is because the compiler has already removed the relevant code. Only the source code shows whether the programmer intended to clear the memory or not, so this weakness is indistinguishable from others.

This weakness is only detectable using white box methods (see black box detection factor). Careful analysis is required to determine if the code is likely to be removed by the compiler.

This weakness will allow data that has not been cleared from memory to be read. If this data contains sensitive password information, then an attacker can read the password and use the information to bypass protection mechanisms.


Improper Neutralization of Delimiters

Summary: The product does not neutralize or incorrectly neutralizes delimiters.


Improper Neutralization of Parameter/Argument Delimiters

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as parameter or argument delimiters when they are sent to a downstream component.


Incorrect Initialization of Resource

Summary: The product attempts to initialize a resource but does not correctly do so, which might leave the resource in an unexpected, incorrect, or insecure state when it is accessed.

The technical impact can vary widely based on how the resource is used in the product, and whether its contents affect security decisions.


Improper Neutralization of Value Delimiters

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as value delimiters when they are sent to a downstream component.


Exposure of Sensitive Information during Transient Execution

Summary: A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.


Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution

Summary:
			A processor event may allow transient operations to access
			architecturally restricted data (for example, in another address
			space) in a shared microarchitectural structure (for example, a CPU
			cache), potentially exposing the data over a covert channel.

Academic researchers have demonstrated that this
				weakness can be detected in hardware using software fuzzing
				tools that treat the underlying hardware as a black box
				([REF-1406], [REF-1430])


Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution

Summary:
A processor event or prediction may allow incorrect or stale data to
		  be forwarded to transient operations, potentially exposing data over a
		  covert channel.


Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution

Summary:
Shared microarchitectural predictor state may allow code to influence
				transient execution across a hardware boundary, potentially exposing
				data that is accessible beyond the boundary over a covert channel.


Improper Validation of Generative AI Output

Summary:
The product invokes a generative AI/ML
			component whose behaviors and outputs cannot be directly
			controlled, but the product does not validate or
			insufficiently validates the outputs to ensure that they
			align with the intended security, content, or privacy
			policy.

Use known techniques for prompt injection
			 and other attacks, and adjust the attacks to be more
			 specific to the model or system.

Review of the product design can be
			 effective, but it works best in conjunction with dynamic
			 analysis.

This entry is related to AI/ML, which is not well
			 understood from a weakness perspective. Typically, for
			 new/emerging technologies including AI/ML, early
			 vulnerability discovery and research does not focus on
			 root cause analysis (i.e., weakness identification). For
			 AI/ML, the recent focus has been on attacks and
			 exploitation methods, technical impacts, and mitigations.
			 As a result, closer research or focused efforts by SMEs
			 is necessary to understand the underlying weaknesses.
			 Diverse and dynamic terminology and rapidly-evolving
			 technology further complicate understanding. Finally,
			 there might not be enough real-world examples with
			 sufficient details from which weakness patterns may be
			 discovered. For example, many real-world vulnerabilities
			 related to "prompt injection" appear to be related to
			 typical injection-style attacks in which the only
			 difference is that the "input" to the vulnerable
			 component comes from model output instead of direct
			 adversary input, similar to "second-order SQL injection"
			 attacks.

This entry was created by members
           of the CWE AI Working Group during June and July 2024. The
           CWE Project Lead, CWE Technical Lead, AI WG co-chairs, and
           many WG members decided that for purposes of timeliness, it
           would be more helpful to the CWE community to publish the
           new entry in CWE 4.15 quickly and add to it in subsequent
           versions.


Improper Neutralization of Input Used for LLM Prompting

prompt injection

attack-oriented term for modifying prompts, whether due to this weakness or other weaknesses

Summary:
The product uses externally-provided data to build prompts provided to
large language models (LLMs), but the way these prompts are constructed
causes the LLM to fail to distinguish between user-supplied inputs and
developer provided system directives.


Improper Neutralization of Record Delimiters

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as record delimiters when they are sent to a downstream component.


Improper Neutralization of Line Delimiters

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as line delimiters when they are sent to a downstream component.

Depending on the language and syntax being used, this could be the same as the record delimiter (CWE-143).


Improper Neutralization of Section Delimiters

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as section delimiters when they are sent to a downstream component.


Improper Neutralization of Expression/Command Delimiters

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as expression or command delimiters when they are sent to a downstream component.

A shell metacharacter (covered in CWE-150) is one example of a potential delimiter that may need to be neutralized.


Improper Neutralization of Input Terminators

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as input terminators when they are sent to a downstream component.


Improper Neutralization of Input Leaders

Summary: The product does not properly handle when a leading character or sequence ("leader") is missing or malformed, or if multiple leaders are used when only one should be allowed.


Improper Neutralization of Quoting Syntax

Summary: Quotes injected into a product can be used to compromise a system. As data are parsed, an injected/absent/duplicate/malformed use of quotes may cause the process to take unexpected actions.


External Control of System or Configuration Setting

Summary: One or more system settings or configuration elements can be externally controlled by a user.


Improper Neutralization of Escape, Meta, or Control Sequences

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.


Improper Neutralization of Comment Delimiters

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as comment delimiters when they are sent to a downstream component.


Improper Neutralization of Macro Symbols

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as macro symbols when they are sent to a downstream component.


Improper Neutralization of Substitution Characters

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


Improper Neutralization of Variable Name Delimiters

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as variable name delimiters when they are sent to a downstream component.


Improper Neutralization of Wildcards or Matching Symbols

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as wildcards or matching symbols when they are sent to a downstream component.


Improper Neutralization of Whitespace

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as whitespace when they are sent to a downstream component.

Can overlap other separator characters or delimiters.


Failure to Sanitize Paired Delimiters

Summary: The product does not properly handle the characters that are used to mark the beginning and ending of a group of entities, such as parentheses, brackets, and braces.


Improper Neutralization of Null Byte or NUL Character

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes NUL characters or null bytes when they are sent to a downstream component.

This can be a factor in multiple interpretation errors, other interaction errors, filename equivalence, etc.


Improper Handling of Invalid Use of Special Elements

Summary: The product does not properly filter, remove, quote, or otherwise manage the invalid use of special elements in user-controlled input, which could cause adverse effect on its behavior and integrity.

The list of children for this entry is far from complete. However, the types of special elements might be too precise for use within CWE.

Precise terminology for the underlying weaknesses does not exist. Therefore, these weaknesses use the terminology associated with the manipulation.

Customized languages and grammars, even those that are specific to a particular product, are potential sources of weaknesses that are related to special elements. However, most researchers concentrate on the most commonly used representations for data transmission, such as HTML and SQL. Any representation that is commonly used is likely to be a rich source of weaknesses; researchers are encouraged to investigate previously unexplored representations.


Improper Neutralization of Leading Special Elements

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes leading special elements that could be interpreted in unexpected ways when they are sent to a downstream component.


Improper Neutralization of Multiple Leading Special Elements

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes multiple leading special elements that could be interpreted in unexpected ways when they are sent to a downstream component.


Improper Neutralization of Trailing Special Elements

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes trailing special elements that could be interpreted in unexpected ways when they are sent to a downstream component.


Improper Neutralization of Multiple Trailing Special Elements

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes multiple trailing special elements that could be interpreted in unexpected ways when they are sent to a downstream component.


Improper Neutralization of Internal Special Elements

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes internal special elements that could be interpreted in unexpected ways when they are sent to a downstream component.


Improper Neutralization of Multiple Internal Special Elements

Summary: The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes multiple internal special elements that could be interpreted in unexpected ways when they are sent to a downstream component.


Improper Handling of Missing Special Element

Summary: The product receives input from an upstream component, but it does not handle or incorrectly handles when an expected special element is missing.


Improper Handling of Additional Special Element

Summary: The product receives input from an upstream component, but it does not handle or incorrectly handles when an additional unexpected special element is provided.


Improper Handling of Inconsistent Special Elements

Summary: The product does not properly handle input in which an inconsistency exists between two or more special characters or reserved words.


Improper Null Termination

Summary: The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.

Factors: this is usually resultant from other weaknesses such as off-by-one errors, but it can be primary to boundary condition violations such as buffer overflows. In buffer overflows, it can act as an expander for assumed-immutable data.

As currently described, this entry is more like a category than a weakness.

The case of an omitted null character is the most dangerous of the possible issues. This will almost certainly result in information disclosure, and possibly a buffer overflow condition, which may be exploited to execute arbitrary code.

If a null character is omitted from a string, then most string-copying functions will read data until they locate a null character, even outside of the intended boundaries of the string. This could: cause a crash due to a segmentation fault cause sensitive adjacent memory to be copied and sent to an outsider trigger a buffer overflow when the copy is being written to a fixed-size buffer.

Misplaced null characters may result in any number of security problems. The biggest issue is a subset of buffer overflow, and write-what-where conditions, where data corruption occurs from the writing of a null character over valid data, or even instructions. A randomly placed null character may put the system into an undefined state, and therefore make it prone to crashing. A misplaced null character may corrupt other data in memory.

Should the null character corrupt the process flow, or affect a flag controlling access, it may lead to logical errors which allow for the execution of arbitrary code.


Encoding Error

Summary: The product does not properly encode or decode the data, resulting in unexpected values.

Partially overlaps path traversal and equivalence weaknesses.

This is more like a category than a weakness.

Many other types of encodings should be listed in this category.


Improper Handling of Alternate Encoding

Summary: The product does not properly handle when an input uses an alternate encoding that is valid for the control sphere to which the input is being sent.


Double Decoding of the Same Data

Summary: The product decodes the same input twice, which can limit the effectiveness of any protection mechanism that occurs in between the decoding operations.


Improper Handling of Mixed Encoding

Summary: The product does not properly handle when the same input uses several different (mixed) encodings.


Improper Handling of Unicode Encoding

Summary: The product does not properly handle when an input contains Unicode encoding.


Improper Handling of URL Encoding (Hex Encoding)

Summary: The product does not properly handle when all or part of an input has been URL encoded.


Improper Handling of Case Sensitivity

Summary: The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.

These are probably under-studied in Windows and Mac environments, where file names are case-insensitive and thus are subject to equivalence manipulations involving case.


Incorrect Behavior Order: Early Validation

Summary: The product validates input before applying protection mechanisms that modify the input, which could allow an attacker to bypass the validation via dangerous inputs that only arise after the modification.

These errors are mostly reported in path traversal vulnerabilities, but the concept applies whenever validation occurs.

An attacker could include dangerous input that bypasses validation protection mechanisms which can be used to launch various attacks including injection attacks, execute arbitrary code or cause other unintended behavior.


Incorrect Behavior Order: Validate Before Canonicalize

Summary: The product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step.


Incorrect Behavior Order: Validate Before Filter

Summary: The product validates data before it has been filtered, which prevents the product from detecting data that becomes invalid after the filtering step.

This category is probably under-studied.


Collapse of Data into Unsafe Value

Summary: The product filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.

Overlaps regular expressions, although an implementation might not necessarily use regexp's.


Permissive List of Allowed Inputs

Allowlist / Allow List

This is used by CWE and CAPEC instead of other commonly-used terms.  Its counterpart is denylist.

Safelist / Safe List

This is often used by security tools such as firewalls, email or web gateways, proxies, etc.

Whitelist / White List

This term is frequently used, but usage has been declining as organizations have started to adopt other terms.

Summary: The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive - that is, it allows an input that is unsafe, leading to resultant weaknesses.


Incomplete List of Disallowed Inputs

Denylist / Deny List

This is used by CWE and CAPEC instead of other commonly-used terms.  Its counterpart is allowlist.

Summary: The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete.

Exploitation of a vulnerability with commonly-used manipulations might fail, but minor variations might succeed.

Attackers may be able to find other malicious inputs that were not expected by the developer, allowing them to bypass the intended protection mechanism.


Incorrect Regular Expression

Summary: The product specifies a regular expression in a way that causes data to be improperly matched or compared.

While there is some overlap with allowlist/denylist problems, this entry is intended to deal with incorrectly written regular expressions, regardless of their intended use. Not every regular expression is intended for use as an allowlist or denylist. In addition, allowlists and denylists can be implemented using other mechanisms besides regular expressions.

Regexp errors are likely a primary factor in many MFVs, especially those that require multiple manipulations to exploit. However, they are rarely diagnosed at this level of detail.

When the regular expression is not correctly specified, data might have a different format or type than the rest of the program expects, producing resultant weaknesses or errors.

In PHP, regular expression checks can sometimes be bypassed with a null byte, leading to any number of weaknesses.


Overly Restrictive Regular Expression

Summary: A regular expression is overly restrictive, which prevents dangerous values from being detected.

Can overlap allowlist/denylist errors (CWE-183/CWE-184)


Partial String Comparison

Summary: The product performs a comparison that only examines a portion of a factor before determining whether there is a match, such as a substring, leading to resultant weaknesses.

This is conceptually similar to other weaknesses, such as insufficient verification and regular expression errors. It is primary to some weaknesses.


Reliance on Data/Memory Layout

Summary: The product makes invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior.

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.

Can result in unintended modifications or exposure of sensitive memory.


Integer Overflow or Wraparound

Overflow

The terms "overflow" and "wraparound" are
               used interchangeably by some people, but they can have
               more precise distinctions by others. See Terminology
               Notes.

wrap, wrap-around, wrap around

Alternate spellings of "wraparound"

Summary:
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.

This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

Sometimes, evidence of 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.

Integer overflows can be primary to buffer overflows when they cause less memory to be allocated than expected.

While there may be circumstances in
            which the logic intentionally relies on wrapping - such as
            with modular arithmetic in timers or counters - it can
            have security consequences if the wrap is unexpected.
            This is especially the case if the integer overflow can be
            triggered using user-supplied inputs.

This weakness can generally lead to undefined behavior and therefore crashes. When the calculated result is used for resource allocation, this weakness can cause too many (or too few) resources to be allocated, possibly enabling crashes if the product requests more resources than can be provided.

If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the overflow/wraparound results in other conditions such as buffer overflows, further memory corruption may occur.

This weakness can sometimes trigger buffer overflows, which can be used to execute arbitrary code. This is usually outside the scope of the product's implicit security policy.

If the overflow/wraparound occurs in a loop index variable, this could cause the loop to terminate at the wrong time - too early, too late, or not at all (i.e., infinite loops). With too many iterations, some loops could consume too many resources such as memory, file handles, etc., possibly leading to a crash or other DoS.

If integer values are used in security-critical decisions, such as calculating quotas or allocation limits, integer overflows can be used to cause an incorrect security decision.


Integer Underflow (Wrap or Wraparound)

Summary: The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result.

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.)

This weakness will generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high.

If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the wrap around results in other conditions such as buffer overflows, further memory corruption may occur.

This weakness can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy.


Integer Coercion Error

Summary: Integer coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types.

Within C, it might be that "coercion" is semantically different than "casting", possibly depending on whether the programmer directly specifies the conversion, or if the compiler does it implicitly. This has implications for the presentation of this entry and others, such as CWE-681, and whether there is enough of a difference for these entries to be split.

Integer coercion often leads to undefined states of execution resulting in infinite loops or crashes.

In some cases, integer coercion errors can lead to exploitable buffer overflow conditions, resulting in the execution of arbitrary code.

Integer coercion errors result in an incorrect value being stored for the variable in question.


Off-by-one Error

off-by-five

An "off-by-five" error was reported for sudo in 2002 (CVE-2002-0184), but that is more like a "length calculation" error.

Summary: A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value.

This is not always a buffer overflow. For example, an off-by-one error could be a factor in a partial comparison, a read from the wrong memory location, an incorrect conditional, etc.


Unexpected Sign Extension

Summary: The product performs an operation on a number that causes it to be sign extended when it is transformed into a larger data type. When the original number is negative, this can produce unexpected values that lead to resultant weaknesses.

Sign extension errors can lead to buffer overflows and other memory-based problems. They are also likely to be factors in other weaknesses that are not based on memory operations, but rely on numeric calculation.

This entry is closely associated with signed-to-unsigned conversion errors (CWE-195) and other numeric errors. These relationships need to be more closely examined within CWE.

When an unexpected sign extension occurs in code that operates directly on memory buffers, such as a size value or a memory index, then it could cause the program to write or read outside the boundaries of the intended buffer. If the numeric value is associated with an application-level resource, such as a quantity or price for a product in an e-commerce site, then the sign extension could produce a value that is much higher (or lower) than the application's allowable range.


Signed to Unsigned Conversion Error

Summary: The product uses a signed primitive and performs a cast to an unsigned primitive, which can produce an unexpected value if the value of the signed primitive can not be represented using an unsigned primitive.

Conversion between signed and unsigned values can lead to a variety of errors, but from a security standpoint is most commonly associated with integer overflow and buffer overflow vulnerabilities.


Unsigned to Signed Conversion Error

Summary: The product uses an unsigned primitive and performs a cast to a signed primitive, which can produce an unexpected value if the value of the unsigned primitive can not be represented using a signed primitive.

Incorrect sign conversions generally lead to undefined behavior, and therefore crashes.

If a poor cast lead to a buffer overflow or similar condition, data integrity may be affected.

Improper signed-to-unsigned conversions without proper checking can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy.


Numeric Truncation Error

Summary: Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.

This weakness has traditionally been under-studied and under-reported, although vulnerabilities in popular software have been published in 2008 and 2009.

The true value of the data is lost and corrupted data is used.


Use of Incorrect Byte Ordering

Summary: The product receives input from an upstream component, but it does not account for byte ordering (e.g. big-endian and little-endian) when processing the input, causing an incorrect number or value to be used.

Because byte ordering bugs are usually very noticeable even with normal inputs, this bug is more likely to occur in rarely triggered error conditions, making them difficult to detect using black box methods.


Improper Input Validation

Summary:
The product receives input or data, but it does
        not validate or incorrectly validates that the input has the
        properties that are required to process the data safely and
        correctly.

When custom input validation is required, such as when enforcing business rules, manual analysis is necessary to ensure that the validation is properly implemented.

Fuzzing techniques can be useful for detecting input validation errors. When unexpected inputs are provided to the software, the software should not crash or otherwise become unstable, and it should generate application-controlled error messages. If exceptions or interpreter-generated error messages occur, this indicates that the input was not detected and handled within the application logic itself.

As of 2020, this entry is used more often than preferred, and it is a source of frequent confusion. It is being actively modified for CWE 4.1 and subsequent versions.

Concepts such as validation, data transformation, and neutralization are being refined, so relationships between CWE-20 and other entries such as CWE-707 may change in future versions, along with an update to the Vulnerability Theory document.

Input validation - whether missing or incorrect - is such an essential and widespread part of secure development that it is implicit in many different weaknesses. Traditionally, problems such as buffer overflows and XSS have been classified as input validation problems by many security professionals. However, input validation is not necessarily the only protection mechanism available for avoiding such problems, and in some cases it is not even sufficient. The CWE team has begun capturing these subtleties in chains within the Research Concepts view (CWE-1000), but more work is needed.

An attacker could provide unexpected values and cause a program crash or excessive consumption of resources, such as memory and CPU.

An attacker could read confidential data if they are able to control resource references.

An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.


Exposure of Sensitive Information to an Unauthorized Actor

Information Disclosure

This term is frequently used in vulnerability advisories to describe a consequence or technical impact, for any vulnerability that has a loss of confidentiality. Often, CWE-200 can be misused to represent the loss of confidentiality, even when the mistake - i.e., the weakness - is not directly related to the mishandling of the information itself, such as an out-of-bounds read that accesses sensitive memory contents; here, the out-of-bounds read is the primary weakness, not the disclosure of the memory.  In addition, this phrase is also used frequently in policies and legal documents, but it does not refer to any disclosure of security-relevant information.

Information Leak

This is a frequently used term, however the "leak" term has multiple uses within security. In some cases it deals with the accidental exposure of information from a different weakness, but in other cases (such as "memory leak"), this deals with improper tracking of resources, which can lead to exhaustion. As a result, CWE is actively avoiding usage of the "leak" term.

Summary: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

As a result of mapping analysis in the 2020 Top 25 and more recent versions, this weakness is under review, since it is frequently misused in mapping to cover many problems that lead to loss of confidentiality. See Mapping Notes, Extended Description, and Alternate Terms.


Insertion of Sensitive Information Into Sent Data

Summary: The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.

Sensitive information could include data that is sensitive in and of itself (such as credentials or private messages), or otherwise useful in the further exploitation of the system (such as internal file system structure).

Sensitive data may be exposed to attackers.


Exposure of Sensitive Information Through Data Queries

Summary: When trying to keep information confidential, an attacker can often infer some of the information by using statistics.

Sensitive information may possibly be leaked through data queries accidentally.


Observable Discrepancy

Side Channel Attack

Observable Discrepancies are at the root of side channel attacks.

Summary: The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not.

An attacker can gain access to sensitive information about the system, including authentication information that may allow an attacker to gain access to the system.

When cryptographic primitives are vulnerable to side-channel-attacks, this could be used to reveal unencrypted plaintext in the worst case.


Observable Response Discrepancy

Summary: The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere.

can overlap errors related to escalated privileges


Observable Behavioral Discrepancy

Summary: The product's behaviors indicate important differences that may be observed by unauthorized actors in a way that reveals (1) its internal state or decision process, or (2) differences from other products with equivalent functionality.


Observable Internal Behavioral Discrepancy

Summary: The product performs multiple behaviors that are combined to produce a single result, but the individual behaviors are observable separately in a way that allows attackers to reveal internal state or internal decision points.


Observable Behavioral Discrepancy With Equivalent Products

Summary: The product operates in an environment in which its existence or specific identity should not be known, but it behaves differently than other products with equivalent functionality, in a way that is observable to an attacker.


Observable Timing Discrepancy

Summary: Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.

Often primary in cryptographic applications and algorithms.

CWE 4.16 removed a demonstrative example for a hardware module because it was inaccurate and unable to be adapted. The CWE team is developing an alternative.


Generation of Error Message Containing Sensitive Information

Summary: The product generates an error message that includes sensitive information about its environment, users, or associated data.

This weakness generally requires domain-specific interpretation using manual analysis. However, the number of potential error conditions may be too large to cover completely within limited time constraints.

Automated methods may be able to detect certain idioms automatically, such as exposed stack traces or pathnames, but violation of business rules or privacy requirements is not typically feasible.

Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.

Often this will either reveal sensitive information which may be used for a later attack or private information stored in the server.


Self-generated Error Message Containing Sensitive Information

Summary: The product identifies an error condition and creates its own diagnostic or error messages that contain sensitive information.


Externally-Generated Error Message Containing Sensitive Information

Summary: The product performs an operation that triggers an external diagnostic or error message that is not directly generated or controlled by the product, such as an error generated by the programming language interpreter that a software application uses. The error can contain sensitive system information.

This is inherently a resultant vulnerability from a weakness within the product or an interaction error.


Improper Removal of Sensitive Information Before Storage or Transfer

Summary: The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.

This entry is intended to be different from resultant information leaks, including those that occur from improper buffer initialization and reuse, improper encryption, interaction errors, and multiple interpretation errors. This entry could be regarded as a privacy leak, depending on the type of information that is leaked.

There is a close association between CWE-226 and CWE-212. The difference is partially that of perspective. CWE-226 is geared towards the final stage of the resource lifecycle, in which the resource is deleted, eliminated, expired, or otherwise released for reuse. Technically, this involves a transfer to a different control sphere, in which the original contents of the resource are no longer relevant. CWE-212, however, is intended for sensitive data in resources that are intentionally shared with others, so they are still active. This distinction is useful from the perspective of the CWE research view (CWE-1000).

The terms "cleansing" and "scrubbing" have multiple uses within computing. In information security, these are used for the removal of sensitive data, but they are also used for the modification of incoming/outgoing data so that it conforms to specifications.

Sensitive data may be exposed to an unauthorized actor in another control sphere. This may have a wide range of secondary consequences which will depend on what data is exposed. One possibility is the exposure of system data allowing an attacker to craft a specific, more effective attack.


Exposure of Sensitive Information Due to Incompatible Policies

Summary: The product's intended functionality exposes information to certain actors in accordance with the developer's security policy, but this information is regarded as sensitive according to the intended security policies of other stakeholders such as the product's administrator, users, or others whose information is being processed.

This entry is being considered for deprecation.  It overlaps many other entries related to information exposures.  It might not be essential to preserve this entry, since other key stakeholder policies are covered elsewhere, e.g. personal privacy leaks (CWE-359) and system-level exposures that are important to system administrators (CWE-497).

In vulnerability theory terms, this covers cases in which the developer's Intended Policy allows the information to be made available, but the information might be in violation of a Universal Policy in which the product's administrator should have control over which information is considered sensitive and therefore should not be exposed.


Invocation of Process Using Visible Sensitive Information

Summary: A process is invoked with sensitive command-line arguments, environment variables, or other elements that can be seen by other processes on the operating system.

Under-studied, especially environment variables.


Insertion of Sensitive Information Into Debugging Code

Summary: The product inserts sensitive information into debugging code, which could expose this information if the debugging code is not disabled in production.


DEPRECATED: Containment Errors (Container Errors)

Summary: This entry has been deprecated, as it was not effective as a weakness and was structured more like a category. In addition, the name is inappropriate, since the "container" term is widely understood by developers in different ways than originally intended by PLOVER, the original source for this entry.


DEPRECATED: Failure to Protect Stored Data from Modification

Summary: This entry has been deprecated because it incorporated and confused multiple weaknesses. The issues formerly covered in this entry can be found at CWE-766 and CWE-767.


DEPRECATED: Failure to provide confidentiality for stored data

Summary: This weakness has been deprecated because it was a duplicate of CWE-493. All content has been transferred to CWE-493.


Storage of File with Sensitive Data Under Web Root

Summary: The product stores sensitive data under the web document root with insufficient access control, which might make it accessible to untrusted parties.


Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Path traversal

"Path traversal" is preferred over "directory traversal," but both terms are attack-focused.

Summary: The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

Automated techniques can find areas where path traversal weaknesses exist. However, tuning or customization may be required to remove or de-prioritize path-traversal problems that are only exploitable by the product's administrator - or other privileged users - and thus potentially valid behavior or, at worst, a bug instead of a vulnerability.

Manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all file access operations can be assessed within limited time constraints.

In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to apply to a wider range of files. For example, the product may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.

Pathname equivalence can be regarded as a type of canonicalization error.

Some pathname equivalence issues are not directly related to directory traversal, rather are used to bypass security-relevant checks for whether a file/directory can be accessed by the attacker (e.g. a trailing "/" on a filename could bypass access rules that don't expect a trailing /, causing a server to provide the file when it normally would not).

Many variants of path traversal attacks are probably under-studied with respect to root cause. CWE-790 and CWE-182 begin to cover part of this gap.

The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.

The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication.

The attacker may be able read the contents of unexpected files and expose sensitive data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.

The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the product from working at all and in the case of protection mechanisms such as authentication, it has the potential to lock out product users.


Storage of File With Sensitive Data Under FTP Root

Summary: The product stores sensitive data under the FTP server root with insufficient access control, which might make it accessible to untrusted parties.


Information Loss or Omission

Summary: The product does not record, or improperly records, security-relevant information that leads to an incorrect decision or hampers later analysis.


Truncation of Security-relevant Information

Summary: The product truncates the display, recording, or processing of security-relevant information in a way that can obscure the source or nature of an attack.

The source of an attack will be difficult or impossible to determine. This can allow attacks to the system to continue without notice.


Omission of Security-relevant Information

Summary: The product does not record or display information that would be important for identifying the source or nature of an attack, or determining if an action is safe.


Obscured Security-relevant Information by Alternate Name

Summary: The product records security-relevant information according to an alternate name of the affected entity, instead of the canonical name.


DEPRECATED: General Information Management Problems

Summary: This weakness can be found at CWE-199.


Sensitive Information in Resource Not Removed Before Reuse

Summary: The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.

Write a known pattern into each sensitive location. Trigger the release of the resource or cause the desired state transition to occur. Read data back from the sensitive locations. If the reads are successful, and the data is the same as the pattern that was originally written, the test fails and the product needs to be fixed. Note that this test can likely be automated.

This entry needs modification to clarify the differences with CWE-212. The description also combines two problems that are distinct from the CWE research perspective: the inadvertent transfer of information to another sphere, and improper initialization/shutdown. Some of the associated taxonomy mappings reflect these different uses.

This is frequently found for network packets, but it can also exist in local memory allocation, files, etc.


Improper Handling of Syntactically Invalid Structure

Summary: The product does not handle or incorrectly handles input that is not syntactically well-formed with respect to the associated specification.

This entry needs more investigation. Public vulnerability research generally focuses on the manipulations that generate invalid structure, instead of the weaknesses that are exploited by those manipulations. For example, a common attack involves making a request that omits a required field, which can trigger a crash in some cases. The crash could be due to a named chain such as CWE-690 (Unchecked Return Value to NULL Pointer Dereference), but public reports rarely cover this aspect of a vulnerability.

The validity of input could be roughly classified along "syntactic", "semantic", and "lexical" dimensions. If the specification requires that an input value should be delimited with the "[" and "]" square brackets, then any input that does not follow this specification would be syntactically invalid. If the input between the brackets is expected to be a number, but the letters "aaa" are provided, then the input is syntactically invalid. If the input is a number and enclosed in brackets, but the number is outside of the allowable range, then it is semantically invalid. The inter-relationships between these properties - and their associated weaknesses- need further exploration.

If an input is syntactically invalid, then processing the input could place the system in an unexpected state that could lead to a crash, consume available system resources or other unintended behaviors.


Improper Handling of Values

Summary: The product does not properly handle when the expected number of values for parameters, fields, or arguments is not provided in input, or if those values are undefined.


Relative Path Traversal

Zip Slip

"Zip slip" is an attack that uses file archives (e.g., ZIP, tar, rar, etc.) that contain filenames with path traversal sequences that cause the files to be written outside of the directory under which the archive is expected to be extracted [REF-1282]. It is most commonly used for relative path traversal (CWE-23) and link following (CWE-59).

Summary: The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.

The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the product from working at all and in the case of a protection mechanisms such as authentication, it has the potential to lockout every user of the product.


Improper Handling of Missing Values

Summary: The product does not handle or incorrectly handles when a parameter, field, or argument name is specified, but the associated value is missing, i.e. it is empty, blank, or null.

Some "crash by port scan" bugs are probably due to this, but lack of diagnosis makes it difficult to be certain.


Improper Handling of Extra Values

Summary: The product does not handle or incorrectly handles when more values are provided than expected.


Improper Handling of Undefined Values

Summary: The product does not handle or incorrectly handles when a value is not defined or supported for the associated parameter, field, or argument name.


Improper Handling of Parameters

Summary: The product does not properly handle when the expected number of parameters, fields, or arguments is not provided in input, or if those parameters are undefined.

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.

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.)


Failure to Handle Missing Parameter

Summary: If too few arguments are sent to a function, the function will still pop the expected number of arguments from the stack. Potentially, a variable number of arguments could be exhausted in a function as well.

This entry will be deprecated in a future version of CWE. The term "missing parameter" was used in both PLOVER and CLASP, with completely different meanings. However, data from both taxonomies was merged into this entry. In PLOVER, it was meant to cover malformed inputs that do not contain required parameters, such as a missing parameter in a CGI request. This entry's observed examples and classification came from PLOVER. However, the description, demonstrative example, and other information are derived from CLASP. They are related to an incorrect number of function arguments, which is already covered by CWE-685.

There is the potential for arbitrary code execution with privileges of the vulnerable program if function parameter list is exhausted.

Potentially a program could fail if it needs more arguments then are available.


Improper Handling of Extra Parameters

Summary: The product does not handle or incorrectly handles when the number of parameters, fields, or arguments with the same name exceeds the expected amount.

This type of problem has a big role in multiple interpretation vulnerabilities and various HTTP attacks.


Improper Handling of Undefined Parameters

Summary: The product does not handle or incorrectly handles when a particular parameter, field, or argument name is not defined or supported by the product.


Improper Handling of Structural Elements

Summary: The product does not handle or incorrectly handles inputs that are related to complex structures.


Improper Handling of Incomplete Structural Elements

Summary: The product does not handle or incorrectly handles when a particular structural element is not completely specified.


Failure to Handle Incomplete Element

Summary: The product does not properly handle when a particular element is not completely specified.


Path Traversal: '../filedir'

Summary: The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "../" sequences that can resolve to a location that is outside of that directory.


Improper Handling of Inconsistent Structural Elements

Summary: The product does not handle or incorrectly handles when two or more structural elements should be consistent, but are not.


Improper Handling of Unexpected Data Type

Summary: The product does not handle or incorrectly handles when a particular element is not the expected type, e.g. it expects a digit (0-9) but is provided with a letter (A-Z).


Use of Inherently Dangerous Function

Summary: The product calls a function that can never be guaranteed to work safely.


Creation of chroot Jail Without Changing Working Directory

Summary: The product uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.


Improper Clearing of Heap Memory Before Release ('Heap Inspection')

Summary: Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory.

Be careful using vfork() and fork() in security sensitive code. The process state will not be cleaned up and will contain traces of data from past use.


J2EE Bad Practices: Direct Management of Connections

Summary: The J2EE application directly manages connections, instead of using the container's connection management facilities.


J2EE Bad Practices: Direct Use of Sockets

Summary: The J2EE application directly uses sockets instead of using framework method calls.


DEPRECATED: Reliance on DNS Lookups in a Security Decision

Summary: This entry has been deprecated because it was a duplicate of CWE-350. All content has been transferred to CWE-350.


Uncaught Exception

Summary: An exception is thrown from a function, but it is not caught.

An uncaught exception could cause the system to be placed in a state that could lead to a crash, exposure of sensitive information or other unintended behaviors.


DEPRECATED: Often Misused: Path Manipulation

Summary:
This entry has been deprecated because of name
	confusion and an accidental combination of multiple
	weaknesses. Most of its content has been transferred to
	CWE-785.


Path Traversal: '/../filedir'

Summary: The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "/../" sequences that can resolve to a location that is outside of that directory.


Execution with Unnecessary Privileges

Summary: The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.

There is a close association with CWE-653 (Insufficient Separation of Privileges). CWE-653 is about providing separate components for each privilege; CWE-250 is about ensuring that each component has the least amount of privileges possible.

CWE-271, CWE-272, and CWE-250 are all closely related and possibly overlapping. CWE-271 is probably better suited as a category. Both CWE-272 and CWE-250 are in active use by the community. The "least privilege" phrase has multiple interpretations.

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.

An attacker will be able to gain access to any resources that are allowed by the extra privileges. Common results include executing code, disabling services, and reading restricted data.


Unchecked Return Value

Summary: The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.

An unexpected return value could place the system in a state that could lead to a crash or other unintended behaviors.


Incorrect Check of Function Return Value

Summary: The product incorrectly checks a return value from a function, which prevents it from detecting errors or exceptional conditions.


Plaintext Storage of a Password

Summary: Storing a password in plaintext may result in a system compromise.


Storing Passwords in a Recoverable Format

Summary: The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. In fact, it should be noted that recoverable encrypted passwords provide no significant benefit over plaintext passwords since they are subject not only to reuse by malicious attackers but also by malicious insiders. If a system administrator can recover a password directly, or use a brute force search on the available information, the administrator can use the password on other accounts.

The meaning of this entry needs to be investigated more closely, especially with respect to what is meant by "recoverable."

Revealed passwords may be reused elsewhere to impersonate the users in question.


Empty Password in Configuration File

Summary: Using an empty string as a password is insecure.


Use of Hard-coded Password

Summary: The product contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.

This entry could be split into multiple variants: an inbound variant (as seen in the second demonstrative example) and an outbound variant (as seen in the first demonstrative example). These variants are likely to have different consequences, detectability, etc. More importantly, from a vulnerability theory perspective, they could be characterized as different behaviors.

If hard-coded passwords are used, it is almost certain that malicious users will gain access through the account in question.


Path Traversal: '/dir/../filename'

Summary: The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "/dir/../filename" sequences that can resolve to a location that is outside of that directory.


Password in Configuration File

Summary: The product stores a password in a configuration file that might be accessible to actors who do not know the password.


Weak Encoding for Password

Summary: Obscuring a password with a trivial encoding does not protect the password.


Not Using Password Aging

Summary: The product does not have a mechanism in place for managing password aging.

As passwords age, the probability that they are compromised grows.


Password Aging with Long Expiration

Summary: The product supports password aging, but the expiration period is too long.


Incorrect Privilege Assignment

Summary: A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.

A user can access restricted functionality and/or sensitive information that may include administrative functionality and user accounts.


Privilege Defined With Unsafe Actions

Summary: A particular privilege, role, capability, or right can be used to perform unsafe actions that were not intended, even when it is assigned to the correct entity.


Privilege Chaining

Summary: Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination.

There is some conceptual overlap with Unsafe Privilege.

A user can be given or gain access rights of another user. This can give the user unauthorized access to sensitive information including the access information of another user.


Improper Privilege Management

Summary: The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

The relationships between privileges, permissions, and actors (e.g. users and groups) need further refinement within the Research view. One complication is that these concepts apply to two different pillars, related to control of resources (CWE-664) and protection mechanism failures (CWE-693).


Path Traversal: 'dir/../../filename'

Summary: The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize multiple internal "../" sequences that can resolve to a location that is outside of that directory.


Privilege Context Switching Error

Summary: The product does not properly manage privileges while it is switching between different contexts that have different privileges or spheres of control.

A user can assume the identity of another user with separate privileges in another context. This will give the user unauthorized access that may allow them to acquire the access information of other users.


Privilege Dropping / Lowering Errors

Summary: The product does not drop privileges before passing control of a resource to an actor that does not have those privileges.

CWE-271, CWE-272, and CWE-250 are all closely related and possibly overlapping. CWE-271 is probably better suited as a category.

If privileges are not dropped, neither are access rights of the user. Often these rights can be prevented from being dropped.

If privileges are not dropped, in some cases the system may record actions as the user which is being impersonated rather than the impersonator.


Least Privilege Violation

Summary: The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.

An attacker may be able to access resources with the elevated privilege that could not be accessed with the attacker's original privileges. This is particularly likely in conjunction with another flaw, such as a buffer overflow.


Improper Check for Dropped Privileges

Summary: The product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.


Improper Handling of Insufficient Privileges

Summary: The product does not handle or incorrectly handles when it has insufficient privileges to perform an operation, leading to resultant weaknesses.

CWE-280 and CWE-274 are too similar. It is likely that CWE-274 will be deprecated in the future.

Overlaps dropped privileges, insufficient permissions.

This has a layering relationship with Unchecked Error Condition and Unchecked Return Value.

Within the context of vulnerability theory, privileges and permissions are two sides of the same coin. Privileges are associated with actors, and permissions are associated with resources. To perform access control, at some point the product makes a decision about whether the actor (and the privileges that have been assigned to that actor) is allowed to access the resource (based on the permissions that have been specified for that resource).


Incorrect Default Permissions

Summary: During installation, installed file permissions are set to allow anyone to modify those files.


Insecure Inherited Permissions

Summary: A product defines a set of insecure permissions that are inherited by objects that are created by the program.


Insecure Preserved Inherited Permissions

Summary: A product inherits a set of insecure permissions for an object, e.g. when copying from an archive file, without user awareness or involvement.


Summary: While it is executing, the product sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.


Path Traversal: '..\filedir'

Summary: The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "..\" sequences that can resolve to a location that is outside of that directory.


Improper Handling of Insufficient Permissions or Privileges

Summary: The product does not handle or incorrectly handles when it has insufficient privileges to access resources or functionality as specified by their permissions. This may cause it to follow unexpected code paths that may leave the product in an invalid state.

This can be both primary and resultant. When primary, it can expose a variety of weaknesses because a resource might not have the expected state, and subsequent operations might fail. It is often resultant from Unchecked Error Condition (CWE-391).

Within the context of vulnerability theory, privileges and permissions are two sides of the same coin. Privileges are associated with actors, and permissions are associated with resources. To perform access control, at some point the software makes a decision about whether the actor (and the privileges that have been assigned to that actor) is allowed to access the resource (based on the permissions that have been specified for that resource).

This type of issue is under-studied, since researchers often concentrate on whether an object has too many permissions, instead of not enough. These weaknesses are likely to appear in environments with fine-grained models for permissions and privileges, which can include operating systems and other large-scale software packages. However, even highly simplistic permission/privilege models are likely to contain these issues if the developer has not considered the possibility of access failure.


Improper Preservation of Permissions

Summary: The product does not preserve permissions or incorrectly preserves permissions when copying, restoring, or sharing objects, which can cause them to have less restrictive permissions than intended.


Improper Ownership Management

Summary: The product assigns the wrong ownership, or does not properly verify the ownership, of an object or resource.


Unverified Ownership

Summary: The product does not properly verify that a critical resource is owned by the proper entity.

This overlaps insufficient comparison, verification errors, permissions, and privileges.

An attacker could gain unauthorized access to system resources.


Improper Access Control

Authorization

The terms "access control" and "authorization" are often used interchangeably, although many people have distinct definitions. The CWE usage of "access control" is intended as a general term for the various mechanisms that restrict which users can access which resources, and "authorization" is more narrowly defined. It is unlikely that there will be community consensus on the use of these terms.

Summary: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.


Improper 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 or incorrectly performs 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

An attacker could read sensitive data, either by reading the data directly from a data store that is not properly 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 properly 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 insufficiently-protected, privileged functionality.


Incorrect User Management

Summary: The product does not properly manage a user within its environment.

The relationships between privileges, permissions, and actors (e.g. users and groups) need further refinement within the Research view. One complication is that these concepts apply to two different pillars, related to control of resources (CWE-664) and protection mechanism failures (CWE-693).

This item needs more work. Possible sub-categories include: user in wrong group, and user with insecure profile or "configuration". It also might be better expressed as a category than a weakness.


Improper Authentication

authentification

An alternate term is "authentification", which appears to be most commonly used by people from non-English-speaking countries.

AuthN

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

AuthC

"AuthC" is used as an abbreviation of "authentication," but it appears to used less frequently than "AuthN."

Summary: When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

This can be resultant from SQL injection vulnerabilities and other issues.

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.

This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.


Authentication Bypass Using an Alternate Path or Channel

Summary: The product requires authentication, but the product has an alternate path or channel that does not require authentication.


Authentication Bypass by Alternate Name

Summary: The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.

Overlaps equivalent encodings, canonicalization, authorization, multiple trailing slash, trailing space, mixed case, and other equivalence issues.

Alternate names are useful in data driven manipulation attacks, not just for authentication.


Path Traversal: '\..\filename'

Summary: The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '\..\filename' (leading backslash dot dot) sequences that can resolve to a location that is outside of that directory.


Authentication Bypass by Spoofing

Summary: This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

This can be resultant from insufficient verification.

This weakness can allow an attacker to access resources which are not otherwise accessible without proper authentication.


Reliance on IP Address for Authentication

Summary: The product uses an IP address for authentication.

Malicious users can fake authentication information, impersonating any IP address.


DEPRECATED: Trusting Self-reported DNS Name

Summary: This entry has been deprecated because it was a duplicate of CWE-350. All content has been transferred to CWE-350.


Using Referer Field for Authentication

referrer

While the proper spelling might be regarded as "referrer," the HTTP RFCs and their implementations use "referer," so this is regarded as the correct spelling.

Summary: The referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.

Actions, which may not be authorized otherwise, can be carried out as if they were validated by the server referred to.


Authentication Bypass by Capture-replay

Summary: A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).

Messages sent with a capture-relay attack allow access to resources which are not otherwise accessible without proper authentication.


Improper Certificate Validation

Summary: The product does not validate, or incorrectly validates, a certificate.


Improper Following of a Certificate's Chain of Trust

Summary: The product does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate.

Exploitation of this flaw can lead to the trust of data that may have originated with a spoofed source.

Data, requests, or actions taken by the attacking entity can be carried out as a spoofed benign entity.


Improper Validation of Certificate with Host Mismatch

Summary: The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.

Set up an untrusted endpoint (e.g. a server) with which the product will connect.  Create a test certificate that uses an invalid hostname but is signed by a trusted CA and provide this certificate from the untrusted endpoint. If the product performs any operations instead of disconnecting and reporting an error, then this indicates that the hostname is not being checked and the test certificate has been accepted.

When Certificate Pinning is being used in a mobile application, consider using a tool such as Spinner [REF-955].  This methodology might be extensible to other technologies.

The data read from the system vouched for by the certificate may not be from the expected system.

Trust afforded to the system in question - based on the malicious certificate - may allow for spoofing or redirection attacks.


Improper Validation of Certificate Expiration

Summary: A certificate expiration is not validated or is incorrectly validated, so trust may be assigned to certificates that have been abandoned due to age.

The data read from the system vouched for by the expired certificate may be flawed due to malicious spoofing.

Trust afforded to the system in question - based on the expired certificate - may allow for spoofing attacks.


Improper Check for Certificate Revocation

Summary: The product does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a certificate that has been compromised.

Trust may be assigned to an entity who is not who it claims to be.

Data from an untrusted (and possibly malicious) source may be integrated.

Data may be disclosed to an entity impersonating a trusted entity, resulting in information disclosure.


Path Traversal: '\dir\..\filename'

Summary: The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '\dir\..\filename' (leading backslash dot dot) sequences that can resolve to a location that is outside of that directory.


Channel Accessible by Non-Endpoint

Summary: The product does not adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint.

The summary identifies multiple distinct possibilities, suggesting that this is a category that must be broken into more specific weaknesses.

An attacker could pose as one of the entities and read or possibly modify the communication.