Reflection Attack in an Authentication Protocol

Summary: Simple authentication protocols are subject to reflection attacks if a malicious user can use the target machine to impersonate a trusted user.

The term "reflection" is used in multiple ways within CWE and the community, so its usage should be reviewed.

The primary result of reflection attacks is successful authentication with a target machine -- as an impersonated user.


Authentication Bypass by Assumed-Immutable Data

Summary: The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.


Incorrect Implementation of Authentication Algorithm

Summary: The requirements for the product dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect.


Missing Critical Step in Authentication

Summary: The product implements an authentication technique, but it skips a step that weakens the technique.

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 can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or allowing attackers to execute arbitrary code.


Authentication Bypass by Primary Weakness

Summary: The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.

Most "authentication bypass" errors are resultant, not primary.


Missing Authentication for Critical Function

Summary: The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

Manual Static Analysis - Binary or Bytecode

Dynamic Analysis with Automated Results Interpretation

Dynamic Analysis with Manual Results Interpretation

Exposing critical functionality essentially provides an attacker with the privilege level of that functionality. The consequences will depend on the associated functionality, but they can range from reading or modifying sensitive data, accessing administrative or other privileged functionality, or possibly even executing arbitrary code.


Improper Restriction of Excessive Authentication Attempts

Summary: The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.

An attacker could perform an arbitrary number of authentication attempts using different passwords, and eventually gain access to the targeted account using a brute force attack.


Use of Single-factor Authentication

Summary: The use of single-factor authentication can lead to unnecessary risk of compromise when compared with the benefits of a dual-factor authentication scheme.

If the secret in a single-factor authentication scheme gets compromised, full authentication is possible.


Use of Password System for Primary Authentication

Summary: The use of password systems as the primary means of authentication may be subject to several flaws or shortcomings, each reducing the effectiveness of the mechanism.

A password authentication mechanism error will almost always result in attackers being authorized as valid users.


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' (multiple internal backslash dot dot) sequences that can resolve to a location that is outside of that directory.


Missing Encryption of Sensitive Data

Summary: The product does not encrypt sensitive or critical information before storage or transmission.

The characterizaton of sensitive data often requires domain-specific understanding, so manual methods are useful. However, manual efforts might not achieve desired code coverage within limited time constraints. Black box methods may produce artifacts (e.g. stored data or unencrypted network transfer) that require manual evaluation.

Automated measurement of the entropy of an input/output source may indicate the use or lack of encryption, but human analysis is still required to distinguish intentionally-unencrypted data (e.g. metadata) from sensitive data.

There is an overlapping relationship between insecure storage of sensitive information (CWE-922) and missing encryption of sensitive information (CWE-311). Encryption is often used to prevent an attacker from reading the sensitive data. However, encryption does not prevent the attacker from erasing or overwriting the data.

If the application does not use a secure channel, such as SSL, to exchange sensitive information, it is possible for an attacker with access to the network traffic to sniff packets from the connection and uncover the data. This attack is not technically difficult, but does require physical access to some portion of the network over which the sensitive data travels. This access is usually somewhere near where the user is connected to the network (such as a colleague on the company network) but can be anywhere along the path from the user to the end server.

Omitting the use of encryption in any program which transfers data over a network of any kind should be considered on par with delivering the data sent to each user on the local networks of both the sender and receiver. Worse, this omission allows for the injection of data into a stream of communication between two parties -- with no means for the victims to separate valid data from invalid. In this day of widespread network attacks and password collection sniffers, it is an unnecessary risk to omit encryption from the design of any system which might benefit from it.


Cleartext Storage of Sensitive Information

Summary: The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).

An attacker with access to the system could read sensitive information stored in cleartext.


Cleartext Storage in a File or on Disk

Summary: The product stores sensitive information in cleartext in a file, or on disk.


Cleartext Storage in the Registry

Summary: The product stores sensitive information in cleartext in the registry.


Cleartext Storage of Sensitive Information in a Cookie

Summary: The product stores sensitive information in cleartext in a cookie.


Cleartext Storage of Sensitive Information in Memory

Summary: The product stores sensitive information in cleartext in memory.

This could be a resultant weakness, e.g. if the compiler removes code that was intended to wipe memory.


Cleartext Storage of Sensitive Information in GUI

Summary: The product stores sensitive information in cleartext within the GUI.


Cleartext Storage of Sensitive Information in Executable

Summary: The product stores sensitive information in cleartext in an executable.


Cleartext Transmission of Sensitive Information

Summary: The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

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.

Anyone can read the information by gaining access to the channel being used for communication.


Path Traversal: '...' (Triple Dot)

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


Use of Hard-coded Cryptographic Key

Summary: The use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered.

The main difference between the use of hard-coded passwords and the use of hard-coded cryptographic keys is the false sense of security that the former conveys. Many people believe that simply hashing a hard-coded password before storage will protect the information from malicious users. However, many hashes are reversible (or at least vulnerable to brute force attacks) -- and further, many authentication protocols simply request the hash itself, making it no better than a password.

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


Key Exchange without Entity Authentication

Summary: The product performs a key exchange with an actor without verifying the identity of that actor.

No authentication takes place in this process, bypassing an assumed protection of encryption.

The encrypted communication between a user and a trusted host may be subject to sniffing by any actor in the communication path.


Reusing a Nonce, Key Pair in Encryption

Summary: Nonces should be used for the present occasion and only once.

Potentially a replay attack, in which an attacker could send the same data twice, could be crafted if nonces are allowed to be reused. This could allow a user to send a message which masquerades as a valid message from a valid user.


Use of a Key Past its Expiration Date

Summary: The product uses a cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attacks against that key.

The cryptographic key in question may be compromised, providing a malicious user with a method for authenticating as the victim.


Missing Cryptographic Step

Summary: The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.

Overlaps incomplete/missing security check.


Inadequate Encryption Strength

Summary: The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.

An attacker may be able to decrypt the data using brute force attacks.


Use of a Broken or Risky Cryptographic Algorithm

Summary: The product uses a broken or risky cryptographic algorithm or protocol.

Automated methods may be useful for recognizing commonly-used libraries or features that have become obsolete.

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.

Automated Static Analysis - Binary or Bytecode

Since CWE 4.4, various cryptography-related entries, including CWE-327 and CWE-1240, have been slated for extensive research, analysis, and community consultation to define consistent terminology, improve relationships, and reduce overlap or duplication. As of CWE 4.6, this work is still ongoing.

The confidentiality of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.

The integrity of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.

If the cryptographic algorithm is used to ensure the identity of the source of the data (such as digital signatures), then a broken algorithm will compromise this scheme and the source of the data cannot be proven.


Use of Weak Hash

Summary: The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).

Since CWE 4.4, various cryptography-related entries including CWE-328 have been slated for extensive research, analysis, and community consultation to define consistent terminology, improve relationships, and reduce overlap or duplication. As of CWE 4.6, this work is still ongoing.


Generation of Predictable IV with CBC Mode

Summary: The product generates and uses a predictable initialization Vector (IV) with Cipher Block Chaining (CBC) Mode, which causes algorithms to be susceptible to dictionary attacks when they are encrypted under the same key.

As of CWE 4.5, terminology related to randomness, entropy, and
	   predictability can vary widely. Within the developer and other
	   communities, "randomness" is used heavily. However, within
	   cryptography, "entropy" is distinct, typically implied as a
	   measurement. There are no commonly-used definitions, even within
	   standards documents and cryptography papers. Future versions of
	   CWE will attempt to define these terms and, if necessary,
	   distinguish between them in ways that are appropriate for
	   different communities but do not reduce the usability of CWE for
	   mapping, understanding, or other scenarios.

If the IV is not properly initialized, data that is encrypted can be compromised and leak information.


Path Traversal: '....' (Multiple Dot)

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

Like the triple-dot CWE-32, this manipulation probably hides multiple weaknesses that should be made more explicit.


Use of Insufficiently Random Values

Summary: The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.

This can be primary to many other weaknesses such as cryptographic errors, authentication errors, symlink following, information leaks, and others.

As of CWE 4.3, CWE-330 and its descendants are being
			  investigated by the CWE crypto team to identify gaps
			  related to randomness and unpredictability, as well as
			  the relationships between randomness and cryptographic
			  primitives.  This "subtree analysis" might
			  result in the addition or deprecation of existing
			  entries; the reorganization of relationships in some
			  views, e.g. the research view (CWE-1000); more consistent
			  use of terminology; and/or significant modifications to
			  related entries.

When a protection mechanism relies on random values to restrict access to a sensitive resource, such as a session ID or a seed for generating a cryptographic key, then the resource being protected could be accessed by guessing the ID or key.

If product relies on unique, unguessable IDs to identify a resource, an attacker might be able to guess an ID for a resource that is owned by another user. The attacker could then read the resource, or pre-create a resource with the same ID to prevent the legitimate program from properly sending the resource to the intended user. For example, a product might maintain session information in a file whose name is based on a username. An attacker could pre-create this file for a victim user, then set the permissions so that the application cannot generate the session for the victim, preventing the victim from using the application.

When an authorization or authentication mechanism relies on random values to restrict access to restricted functionality, such as a session ID or a seed for generating a cryptographic key, then an attacker may access the restricted functionality by guessing the ID or key.


Insufficient Entropy

Summary: The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.

An attacker could guess the random numbers generated and could gain unauthorized access to a system if the random numbers are used for authentication and authorization.


Insufficient Entropy in PRNG

Summary: The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.

If a pseudo-random number generator is using a limited entropy source which runs out (if the generator fails closed), the program may pause or crash.

If a PRNG is using a limited entropy source which runs out, and the generator fails open, the generator could produce predictable random numbers. Potentially a weak source of random numbers could weaken the encryption method used for authentication of users.


Improper Handling of Insufficient Entropy in TRNG

Summary: True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block.

A program may crash or block if it runs out of random numbers.


Small Space of Random Values

Summary: The number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks.

An attacker could easily guess the values used. This could lead to unauthorized access to a system if the seed is used for authentication and authorization.


Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG)

Summary: The product uses a Pseudo-Random Number Generator (PRNG) but does not correctly manage seeds.

If a PRNG is used incorrectly, such as using the same seed for each initialization or using a predictable seed, then an attacker may be able to easily guess the seed and thus the random numbers. This could lead to unauthorized access to a system if the seed is used for authentication and authorization.


Same Seed in Pseudo-Random Number Generator (PRNG)

Summary: A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.


Predictable Seed in Pseudo-Random Number Generator (PRNG)

Summary: A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.


Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)

Summary: The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.

If a PRNG is used for authentication and authorization, such as a session ID or a seed for generating a cryptographic key, then an attacker may be able to easily guess the ID or cryptographic key and gain access to restricted functionality.


Small Seed Space in PRNG

Summary: A Pseudo-Random Number Generator (PRNG) uses a relatively small seed space, which makes it more susceptible to brute force attacks.

This entry may have a chaining relationship with predictable from observable state (CWE-341).


Path Traversal: '....//'

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

This could occur due to a cleansing error that removes a single "../" from "....//"


Generation of Predictable Numbers or Identifiers

Summary: The product uses a scheme that generates numbers or identifiers that are more predictable than required.

As of CWE 4.5, terminology related to randomness, entropy, and
	   predictability can vary widely. Within the developer and other
	   communities, "randomness" is used heavily. However, within
	   cryptography, "entropy" is distinct, typically implied as a
	   measurement. There are no commonly-used definitions, even within
	   standards documents and cryptography papers. Future versions of
	   CWE will attempt to define these terms and, if necessary,
	   distinguish between them in ways that are appropriate for
	   different communities but do not reduce the usability of CWE for
	   mapping, understanding, or other scenarios.


Predictable from Observable State

Summary: A number or object is predictable based on observations that the attacker can make about the state of the system or network, such as time, process ID, etc.

This weakness could be exploited by an attacker in a number ways depending on the context. If a predictable number is used to generate IDs or keys that are used within protection mechanisms, then an attacker could gain unauthorized access to the system. If predictable filenames are used for storing sensitive information, then an attacker might gain access to the system and may be able to gain access to the information in the file.


Predictable Exact Value from Previous Values

Summary: An exact value or random number can be precisely predicted by observing previous values.


Predictable Value Range from Previous Values

Summary: The product's random number generator produces a series of values which, when observed, can be used to infer a relatively small range of possibilities for the next value that could be generated.


Use of Invariant Value in Dynamically Changing Context

Summary: The product uses a constant value, name, or reference, but this value can (or should) vary across different environments.


Insufficient Verification of Data Authenticity

Summary: The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.

"origin validation" could fall under this.

The specific ways in which the origin is not properly identified should be laid out as separate weaknesses. In some sense, this is more like a category.


Origin Validation Error

Summary: The product does not properly verify that the source of data or communication is valid.

This entry has some significant overlap with other CWE entries and may need some clarification. See terminology notes.

The "Origin Validation Error" term was originally used in a 1995 thesis [REF-324]. Although not formally defined, an issue is considered to be an origin validation error if either (1) "an object [accepts] input from an unauthorized subject," or (2) "the system [fails] to properly or completely authenticate a subject." A later section says that an origin validation error can occur when the system (1) "does not properly authenticate a user or process" or (2) "does not properly authenticate the shared data or libraries." The only example provided in the thesis (covered by OSVDB:57615) involves a setuid program running command-line arguments without dropping privileges. So, this definition (and its examples in the thesis) effectively cover other weaknesses such as CWE-287 (Improper Authentication), CWE-285 (Improper Authorization), and CWE-250 (Execution with Unnecessary Privileges). There appears to be little usage of this term today, except in the SecurityFocus vulnerability database, where the term is used for a variety of issues, including web-browser problems that allow violation of the Same Origin Policy and improper validation of the source of an incoming message.

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


Improper Verification of Cryptographic Signature

Summary: The product does not verify, or incorrectly verifies, the cryptographic signature for data.

An attacker could gain access to sensitive data and possibly execute unauthorized code.


Use of Less Trusted Source

Summary: The product has two different sources of the same data or information, but it uses the source that has less support for verification, is less trusted, or is less resistant to attack.

An attacker could utilize the untrusted data source to bypass protection mechanisms and gain access to sensitive data.


Acceptance of Extraneous Untrusted Data With Trusted Data

Summary: The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.

An attacker could package untrusted data with trusted data to bypass protection mechanisms to gain access to and possibly modify sensitive data.


Path Traversal: '.../...//'

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


Reliance on Reverse DNS Resolution for a Security-Critical Action

Summary: The product performs reverse DNS resolution on an IP address to obtain the hostname and make a security decision, but it does not properly ensure that the IP address is truly associated with the hostname.

CWE-350, CWE-247, and CWE-292 were merged into CWE-350 in CWE 2.5. CWE-247 was originally derived from Seven Pernicious Kingdoms, CWE-350 from PLOVER, and CWE-292 from CLASP. All taxonomies focused closely on the use of reverse DNS for authentication of incoming requests.

Malicious users can fake authentication information by providing false DNS information.


Insufficient Type Distinction

Summary: The product does not properly distinguish between different types of elements in a way that leads to insecure behavior.

Overlaps others, e.g. Multiple Interpretation Errors.


Cross-Site Request Forgery (CSRF)

Summary: The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.

CSRF is currently difficult to detect reliably using automated techniques. This is because each application has its own implicit security policy that dictates which requests can be influenced by an outsider and automatically performed on behalf of a user, versus which requests require strong confidence that the user intends to make the request. For example, a keyword search of the public portion of a web site is typically expected to be encoded within a link that can be launched automatically when the user clicks on the link.

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 CSRF is limited only by the victim's privileges.


Missing Support for Integrity Check

Summary: The product uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.

Data that is parsed and used may be corrupted.

Without a checksum it is impossible to determine if any changes have been made to the data after it was sent.


Improper Validation of Integrity Check Value

Summary: The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.

Integrity checks usually use a secret key that helps authenticate the data origin. Skipping integrity checking generally opens up the possibility that new data from an invalid source can be injected.

Without a checksum check, it is impossible to determine if any changes have been made to the data after it was sent.


Product UI does not Warn User of Unsafe Actions

Summary: The product's user interface does not warn the user before undertaking an unsafe action on behalf of that user. This makes it easier for attackers to trick users into inflicting damage to their system.

Often resultant, e.g. in unhandled error conditions.

Can overlap privilege errors, conceptually at least.


Insufficient UI Warning of Dangerous Operations

Summary: The user interface provides a warning to a user regarding dangerous or sensitive operations, but the warning is not noticeable enough to warrant attention.


Improperly Implemented Security Check for Standard

Summary: The product does not implement or incorrectly implements one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique.

This is a "missing step" error on the product side, which can overlap weaknesses such as insufficient verification and spoofing. It is frequently found in cryptographic and authentication errors. It is sometimes resultant.


Exposure of Private Personal Information to an Unauthorized Actor

Summary: The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected.

This entry overlaps many other entries that are not organized around the kind of sensitive information that is exposed.  However, because privacy is treated with such importance due to regulations and other factors, and it may be useful for weakness-finding tools to highlight capabilities that detect personal private information instead of system information, it is not clear whether - and how - this entry should be deprecated.


Absolute Path Traversal

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

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 a protection mechanisms such as authentication, it has the potential to lockout every user of the product.


Trust of System Event Data

Summary: Security based on event locations are insecure and can be spoofed.

If one trusts the system-event information and executes commands based on it, one could potentially take actions based on a spoofed identity.


Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Summary: The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

Black box methods may be able to identify evidence of race conditions via methods such as multiple simultaneous connections, which may cause the software to become instable or crash. However, race conditions with very narrow timing windows would not be detectable.

Common idioms are detectable in white box analysis, such as time-of-check-time-of-use (TOCTOU) file operations (CWE-367), or double-checked locking (CWE-609).

The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.

Race conditions in web applications are under-studied and probably under-reported. However, in 2008 there has been growing interest in this area.

Much of the focus of race condition research has been in Time-of-check Time-of-use (TOCTOU) variants (CWE-367), but many race conditions are related to synchronization problems that do not necessarily require a time-of-check.

From a classification/taxonomy perspective, the relationships between concurrency and program state need closer investigation and may be useful in organizing related issues.

When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization routines, it may lead to resource exhaustion.

When a race condition allows multiple control flows to access a resource simultaneously, it might lead the product(s) into unexpected states, possibly resulting in a crash.

When a race condition is combined with predictable resource names and loose permissions, it may be possible for an attacker to overwrite or access confidential data (CWE-59).

This can have security implications when the expected synchronization is in security-critical code, such as recording whether a user is authenticated or modifying important state information that should not be influenced by an outsider.


Race Condition Enabling Link Following

Summary: The product checks the status of a file or directory before accessing it, which produces a race condition in which the file can be replaced with a link before the access is performed, causing the product to access the wrong file.

This is already covered by the "Link Following" weakness (CWE-59). It is included here because so many people associate race conditions with link problems; however, not all link following issues involve race conditions.


Signal Handler Race Condition

Summary: The product uses a signal handler that introduces a race condition.

It may be possible to cause data corruption and possibly execute arbitrary code by modifying global variables or data structures at unexpected times, violating the assumptions of code that uses this global data.

If a signal handler interrupts code that is executing with privileges, it may be possible that the signal handler will also be executed with elevated privileges, possibly making subsequent exploits more severe.


DEPRECATED: Race Condition in Switch

Summary: This entry has been deprecated. There are no documented cases in which a switch's control expression is evaluated more than once.


Race Condition within a Thread

Summary: If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.

The main problem is that -- if a lock is overcome -- data could be altered in a bad state.


Time-of-check Time-of-use (TOCTOU) Race Condition

TOCTTOU

The TOCTTOU acronym expands to "Time Of Check To Time Of Use".

TOCCTOU

The TOCCTOU acronym is most likely a typo of TOCTTOU, but it has been used in some influential documents, so the typo is repeated fairly frequently.

Summary: The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. This can cause the product to perform invalid actions when the resource is in an unexpected state.

TOCTOU issues do not always involve symlinks, and not every symlink issue is a TOCTOU problem.

Non-symlink TOCTOU issues are not reported frequently, but they are likely to occur in code that attempts to be secure.

The attacker can gain access to otherwise unauthorized resources.

Race conditions such as this kind may be employed to gain read or write access to resources which are not normally readable or writable by the user in question.

The resource in question, or other resources (through the corrupted one), may be changed in undesirable ways by a malicious user.

If a file or other resource is written in this method, as opposed to in a valid way, logging of the activity may not occur.

In some cases it may be possible to delete files a malicious user might not otherwise have access to, such as log files.


Context Switching Race Condition

Summary: A product performs a series of non-atomic actions to switch between contexts that cross privilege or other security boundaries, but a race condition allows an attacker to modify or misrepresent the product's behavior during the switch.

Can overlap signal handler race conditions.

Under-studied as a concept. Frequency unknown; few vulnerability reports give enough detail to know when a context switching race condition is a factor.


Divide By Zero

Summary: The product divides a value by zero.

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.


Summary: The product accepts input in the form of a slash absolute path ('/absolute/pathname/here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.


Missing Check for Certificate Revocation after Initial Check

Summary: The product does not check the revocation status of a certificate after its initial revocation check, which can cause the product to perform privileged actions even after the certificate is revoked at a later time.

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.


Incomplete Internal State Distinction

Summary: The product does not properly determine which state it is in, causing it to assume it is in state X when in fact it is in state Y, causing it to perform incorrect operations in a security-relevant manner.

This conceptually overlaps other categories such as insufficient verification, but this entry refers to the product's incorrect perception of its own state.

This is probably resultant from other weaknesses such as unhandled error conditions, inability to handle out-of-order steps, multiple interpretation errors, etc.

This entry is being considered for deprecation.  It was poorly-defined in PLOVER and is not easily described using the behavior/resource/property model of vulnerability theory.


DEPRECATED: State Synchronization Error

Summary: This entry was deprecated because it overlapped the same concepts as race condition (CWE-362) and Improper Synchronization (CWE-662).


Passing Mutable Objects to an Untrusted Method

Summary: The product sends non-cloned mutable data as an argument to a method or function.

Potentially data could be tampered with by another function which should not have been tampered with.


Returning a Mutable Object to an Untrusted Caller

Summary: Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.


Insecure Temporary File

Summary: Creating and using insecure temporary files can leave application and system data vulnerable to attack.


Creation of Temporary File With Insecure Permissions

Summary: Opening temporary files without appropriate measures or controls can leave the file, its contents and any function that it impacts vulnerable to attack.

If the temporary file can be read by the attacker, sensitive information may be in that file which could be revealed.

If that file can be written to by the attacker, the file might be moved into a place to which the attacker does not have access. This will allow the attacker to gain selective resource access-control privileges.

Depending on the data stored in the temporary file, there is the potential for an attacker to gain an additional input vector which is trusted as non-malicious. It may be possible to make arbitrary changes to data structures, user information, or even process ownership.


Creation of Temporary File in Directory with Insecure Permissions

Summary: The product creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file.

Since the file is visible and the application which is using the temp file could be known, the attacker has gained information about what the user is doing at that time.


Summary: The product accepts input in the form of a backslash absolute path ('\absolute\pathname\here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.


J2EE Bad Practices: Use of System.exit()

Summary: A J2EE application uses System.exit(), which also shuts down its container.


J2EE Bad Practices: Direct Use of Threads

Summary: Thread management in a Web application is forbidden in some circumstances and is always highly error prone.


Session Fixation

Summary: Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.

Other attack vectors include DNS poisoning and related network based attacks where an attacker causes the user to visit a malicious site by redirecting a request for a valid site. Network based attacks typically involve a physical presence on the victim's network or control of a compromised machine on the network, which makes them harder to exploit remotely, but their significance should not be overlooked. Less secure session management mechanisms, such as the default implementation in Apache Tomcat, allow session identifiers normally expected in a cookie to be specified on the URL as well, which enables an attacker to cause a victim to use a fixed session identifier simply by emailing a malicious URL.


Covert Timing Channel

Summary: Covert timing channels convey information by modulating some aspect of system behavior over time, so that the program receiving the information can observe system behavior and infer protected information.

As of CWE 4.9, members of the CWE Hardware SIG are working to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks that create or exploit covert channels. As a result of that work, this entry might change in CWE 4.10.


Symbolic Name not Mapping to Correct Object

Summary: A constant symbolic reference to an object is used, even though the reference can resolve to a different object over time.

The attacker can gain access to otherwise unauthorized resources.

Race conditions such as this kind may be employed to gain read or write access to resources not normally readable or writable by the user in question.

The resource in question, or other resources (through the corrupted one) may be changed in undesirable ways by a malicious user.

If a file or other resource is written in this method, as opposed to a valid way, logging of the activity may not occur.

In some cases it may be possible to delete files that a malicious user might not otherwise have access to -- such as log files.


Path Traversal: 'C:dirname'

Summary: The product accepts input that contains a drive letter or Windows volume letter ('C:dirname') that potentially redirects access to an unintended location or arbitrary file.

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


Detection of Error Condition Without Action

Summary: The product detects a specific error, but takes no actions to handle the error.

An attacker could utilize an ignored error condition to place the system in an unexpected state that could lead to the execution of unintended logic and could cause other unintended behavior.


Unchecked Error Condition

Summary: [PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.

This entry is slated for deprecation; it has multiple widespread interpretations by CWE analysts.  It currently combines information from three different taxonomies, but each taxonomy is talking about a slightly different issue.  CWE analysts might map to this entry based on any of these issues.  7PK has "Empty Catch Block" which has an association with empty exception block (CWE-1069); in this case, the exception has performed the check, but does not handle.  In PLOVER there is "Unchecked Return Value" which is CWE-252, but unlike "Empty Catch Block" there isn't even a check of the issue - and "Unchecked Error Condition" implies lack of a check.  For CLASP, "Uncaught Exception" (CWE-248) is associated with incorrect error propagation - uncovered in CWE 3.2 and earlier, at least.  There are other issues related to error handling and checks.


Missing Report of Error Condition

Summary: The product encounters an error but does not provide a status code or return value to indicate that an error has occurred.

Errors that are not properly reported could place the system in an unexpected state that could lead to unintended behaviors.


Return of Wrong Status Code

Summary: A function or operation returns an incorrect return value or status code that does not indicate an error, but causes the product to modify its behavior based on the incorrect result.

This can be primary or resultant, but it is probably most often primary to other issues.

This weakness could place the system in a state that could lead unexpected logic to be executed or other unintended behaviors.


Unexpected Status Code or Return Value

Summary: The product does not properly check when a function or operation returns a value that is legitimate for the function, but is not expected by the product.

Usually primary, but can be resultant from issues such as behavioral change or API abuse. This can produce resultant vulnerabilities.


Use of NullPointerException Catch to Detect NULL Pointer Dereference

Summary: Catching NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer.


Declaration of Catch for Generic Exception

Summary: Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.


Declaration of Throws for Generic Exception

Summary: Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.

For C++, this weakness only applies to C++98, C++03, and C++11. It relies on a feature known as Dynamic Exception Specification, which was part of early versions of C++ but was deprecated in C++11. It has been removed for C++17 and later.


Path Traversal: '\\UNC\share\name\' (Windows UNC Share)

Summary: The product accepts input that identifies a Windows UNC share ('\\UNC\share\name') that potentially redirects access to an unintended location or arbitrary file.


Uncontrolled Resource Consumption

Summary: The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.

Certain automated dynamic analysis techniques may be effective in spotting resource exhaustion problems, especially with resources such as processes, memory, and connections. The technique may involve generating a large number of requests to the product within a short time frame.

While fuzzing is typically geared toward finding low-level implementation bugs, it can inadvertently find resource exhaustion problems. This can occur when the fuzzer generates a large number of test cases but does not restart the targeted product in between test cases. If an individual test case produces a crash, but it does not do so reliably, then an inability to handle resource exhaustion may be the cause.

"Resource consumption" could be interpreted as a consequence instead of an insecure behavior, so this entry is being considered for modification.  It appears to be referenced too frequently when more precise mappings are available.  Some of its children, such as CWE-771, might be better considered as a chain.

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

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.

The most common result of resource exhaustion is denial of service. The product may slow down, crash due to unhandled errors, or lock out legitimate users.

In some cases it may be possible to force the product to "fail open" in the event of resource exhaustion. The state of the product -- and possibly the security functionality - may then be compromised.


Missing Release of Memory after Effective Lifetime

Summary: The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.

This is often a resultant weakness due to improper handling of malformed data or early termination of sessions.

"memory leak" has sometimes been used to describe other kinds of issues, e.g. for information leaks in which the contents of memory are inadvertently leaked (CVE-2003-0400 is one such example of this terminology conflict).

Most memory leaks result in general product reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing or hanging the program) or take advantage of other unexpected program behavior resulting from a low memory condition.


Transmission of Private Resources into a New Sphere ('Resource Leak')

Summary: The product makes resources available to untrusted parties when those resources are only intended to be accessed by the product.


Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')

File descriptor leak

While this issue is frequently called a file descriptor leak, the "leak" term is often used in two different ways - exposure of a resource, or consumption of a resource. Use of this term could cause confusion.

Summary: A process does not close sensitive file descriptors before invoking a child process, which allows the child to perform unauthorized I/O operations using those descriptors.


Improper Resource Shutdown or Release

Summary: The product does not release or incorrectly releases a resource before it is made available for re-use.

Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the product 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.

Overlaps memory leaks, asymmetric resource consumption, malformed input errors.

Most unreleased resource issues result in general software reliability problems, but if an attacker can intentionally trigger a resource leak, the attacker might be able to launch a denial of service attack by depleting the resource pool.

When a resource containing sensitive information is not correctly shutdown, it may expose the sensitive data in a subsequent allocation.


Asymmetric Resource Consumption (Amplification)

Summary: The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."

Sometimes this is a factor in "flood" attacks, but other types of amplification exist.


Insufficient Control of Network Message Volume (Network Amplification)

Summary: The product does not sufficiently monitor or control transmitted network traffic volume, so that an actor can cause the product to transmit more traffic than should be allowed for that actor.

This can be resultant from weaknesses that simplify spoofing attacks.

Network amplification, when performed with spoofing, is normally a multi-channel attack from attacker (acting as user) to amplifier, and amplifier to victim.

System resources can be quickly consumed leading to poor application performance or system crash. This may affect network performance and could be used to attack other systems and applications relying on network performance.


Inefficient Algorithmic Complexity

Quadratic Complexity

Used when the algorithmic complexity is related to the square of the number of inputs (N^2)

Summary: An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached.

The typical consequence is CPU consumption, but memory consumption and consumption of other resources can also occur.


Incorrect Behavior Order: Early Amplification

Summary: The product allows an entity to perform a legitimate but expensive operation before authentication or authorization has taken place.

System resources, CPU and memory, can be quickly consumed. This can lead to poor system performance or system crash.


Improper Handling of Highly Compressed Data (Data Amplification)

Summary: The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.


Improper Resolution of Path Equivalence

Summary: The product is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object.

Some of these manipulations could be effective in path traversal issues, too.

An attacker may be able to traverse the file system to unintended locations and read or overwrite the contents of unexpected files. If the files are used for a security mechanism than an attacker may be able to bypass the mechanism.


Insufficient Resource Pool

Summary: The product's resource pool is not large enough to handle peak demand, which allows an attacker to prevent others from accessing the resource by using a (relatively) large number of requests for resources.

Floods often cause a crash or other problem besides denial of the resource itself; these are likely examples of *other* vulnerabilities, not an insufficient resource pool.


Unrestricted Externally Accessible Lock

Summary: The product properly checks for the existence of a lock, but the lock can be externally controlled or influenced by an actor that is outside of the intended sphere of control.

Automated code analysis techniques might not be able to reliably detect this weakness, since the application's behavior and general security model dictate which resource locks are critical. Interpretation of the weakness might require knowledge of the environment, e.g. if the existence of a file is used as a lock, but the file is created in a world-writable directory.

This overlaps Insufficient Resource Pool when the "pool" is of size 1. It can also be resultant from race conditions, although the timing window could be quite large in some cases.

When an attacker can control a lock, the program may wait indefinitely until the attacker releases the lock, causing a denial of service to other users of the program. This is especially problematic if there is a blocking operation on the lock.


Improper Resource Locking

Summary: The product does not lock or does not correctly lock a resource when the product must have exclusive access to the resource.

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


Missing Lock Check

Summary: A product does not check to see if a lock is present before performing sensitive operations on a resource.


Double Free

Summary: The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.

This is usually resultant from another weakness, such as an unhandled error or race condition between threads. It could also be primary to weaknesses such as buffer overflows.

It could be argued that Double Free would be most appropriately located as a child of "Use after Free", but "Use" and "Release" are considered to be distinct operations within vulnerability theory, therefore this is more accurately "Release of a Resource after Expiration or Release", which doesn't exist yet.

Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.


Use After Free

Dangling pointer

a pointer that no longer points to valid memory, often after it has been freed

UAF

commonly used acronym for Use After Free

Summary: The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

The use of previously freed memory may corrupt valid data, if the memory area in question has been allocated and used properly elsewhere.

If chunk consolidation occurs after the use of previously freed data, the process may crash when invalid data is used as chunk information.

If malicious data is entered before chunk consolidation can take place, it may be possible to take advantage of a write-what-where primitive to execute arbitrary code. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.


Unprotected Primary Channel

Summary: The product uses a primary channel for administration or restricted functionality, but it does not properly protect the channel.


Path Equivalence: 'filename.' (Trailing Dot)

Summary: The product accepts path input in the form of trailing dot ('filedir.') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.


Unprotected Alternate Channel

Summary: The product protects a primary channel, but it does not use the same level of protection for an alternate channel.

This can be primary to authentication errors, and resultant from unhandled error conditions.


Race Condition During Access to Alternate Channel

Summary: The product opens an alternate channel to communicate with an authorized user, but the channel is accessible to other actors.


Unprotected Windows Messaging Channel ('Shatter')

Summary: The product does not properly verify the source of a message in the Windows Messaging System while running at elevated privileges, creating an alternate channel through which an attacker can directly send a message to the product.

Overlaps privilege errors and UI errors.


DEPRECATED: Proxied Trusted Channel

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


Improper Protection of Alternate Path

Summary: The product does not sufficiently protect all possible paths that a user can take to access restricted functionality or resources.


Direct Request ('Forced Browsing')

forced browsing

The "forced browsing" term could be misinterpreted to include weaknesses such as CSRF or XSS, so its use is discouraged.

Summary: The web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files.

Overlaps Modification of Assumed-Immutable Data (MAID), authorization errors, container errors; often primary to other weaknesses such as XSS and SQL injection.

"Forced browsing" is a step-based manipulation involving the omission of one or more steps, whose order is assumed to be immutable. The application does not verify that the first step was performed successfully before the second step. The consequence is typically "authentication bypass" or "path disclosure," although it can be primary to all kinds of weaknesses, especially in languages such as PHP, which allow external modification of assumed-immutable variables.


Untrusted Search Path

Summary: The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.

Use 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. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

There is the potential for arbitrary code execution with privileges of the vulnerable program.

The program could be redirected to the wrong files, potentially triggering a crash or hang when the targeted file is too large or does not have the expected format.

The program could send the output of unauthorized files to the attacker.


Uncontrolled Search Path Element

DLL preloading

This term is one of several that are used to describe exploitation of untrusted search path elements in Windows systems, which received wide attention in August 2010. From a weakness perspective, the term is imprecise because it can apply to both CWE-426 and CWE-427.

Dependency confusion

As of February 2021, this term is used to describe CWE-427 in the context of managing installation of software package dependencies, in which attackers release packages on public sites where the names are the same as package names used by private repositories, and the search for the dependent package tries the public site first, downloading untrusted code. It may also be referred to as a "substitution attack."

Summary: The product uses a fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors.

Unlike untrusted search path (CWE-426), which inherently involves control over the definition of a control sphere (i.e., modification of a search path), this entry concerns a fixed control sphere in which some part of the sphere may be under attacker control (i.e., the search path cannot be modified by an attacker, but one element of the path can be under attacker control).

This weakness is not a clean fit under CWE-668 or CWE-610, which suggests that the control sphere model might need enhancement or clarification.


Unquoted Search Path or Element

Summary: The product uses a search path that contains an unquoted element, in which the element contains whitespace or other separators. This can cause the product to access resources in a parent path.


Path Equivalence: 'filename....' (Multiple Trailing Dot)

Summary: The product accepts path input in the form of multiple trailing dot ('filedir....') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.


Deployment of Wrong Handler

Summary: The wrong "handler" is assigned to process an object.


Missing Handler

Summary: A handler is not available or implemented.


Dangerous Signal Handler not Disabled During Sensitive Operations

Summary: The product uses a signal handler that shares state with other signal handlers, but it does not properly mask or prevent those signal handlers from being invoked while the original signal handler is still running.


Unparsed Raw Web Content Delivery

Summary: The product stores raw content or supporting code under the web document root with an extension that is not specifically handled by the server.

This overlaps direct requests (CWE-425), alternate path (CWE-424), permissions (CWE-275), and sensitive file under web root (CWE-219).


Unrestricted Upload of File with Dangerous Type

Unrestricted File Upload

Used in vulnerability databases and elsewhere, but it is insufficiently precise. The phrase could be interpreted as the lack of restrictions on the size or number of uploaded files, which is a resource consumption issue.

Summary: The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.

Arbitrary code execution is possible if an uploaded file is interpreted and executed as code by the recipient. This is especially true for web-server extensions such as .asp and .php because these file types are often treated as automatically executable, even when file system permissions do not specify execution. For example, in Unix environments, programs typically cannot run unless the execute bit is set, but PHP programs may be executed by the web server without directly invoking them on the operating system.


Improper Interaction Between Multiple Correctly-Behaving Entities

Summary: An interaction error occurs when two entities have correct behavior when running independently of each other, but when they are integrated as components in a larger system or process, they introduce incorrect behaviors that may cause resultant weaknesses.

The "Interaction Error" term, in CWE and elsewhere, is only intended to describe products that behave according to specification. When one or more of the products do not comply with specifications, then it is more likely to be API Abuse (CWE-227) or an interpretation conflict (CWE-436). This distinction can be blurred in real world scenarios, especially when "de facto" standards do not comply with specifications, or when there are no standards but there is widespread adoption. As a result, it can be difficult to distinguish these weaknesses during mapping and classification.


Interpretation Conflict

Summary: Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.


Incomplete Model of Endpoint Features

Summary: A product acts as an intermediary or monitor between two or more endpoints, but it does not have a complete model of an endpoint's features, behaviors, or state, potentially causing the product to perform incorrect actions based on this incomplete model.

This can be related to interaction errors, although in some cases, one of the endpoints is not performing correctly according to specification.


Behavioral Change in New Version or Environment

Summary: A's behavior or functionality changes with a new version of A, or a new environment, which is not known (or manageable) by B.


Path Equivalence: 'file.name' (Internal Dot)

Summary: The product accepts path input in the form of internal dot ('file.ordir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.

An improper attempt to remove the internal dots from the string could lead to CWE-181 (Incorrect Behavior Order: Validate Before Filter).


Expected Behavior Violation

Summary: A feature, API, or function does not perform according to its specification.

The behavior of an application that is not consistent with the expectations of the developer may lead to incorrect use of the software.


Unintended Proxy or Intermediary ('Confused Deputy')

Confused Deputy

This weakness is sometimes referred to as the "Confused deputy" problem, in which an attacker misused the authority of one victim (the "confused deputy") when targeting another victim.

Summary: The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.

This weakness has a chaining relationship with CWE-668 (Exposure of Resource to Wrong Sphere) because the proxy effectively provides the attacker with access to the target's resources that the attacker cannot directly obtain.

This could possibly be considered as an emergent resource.

It could be argued that the "confused deputy" is a fundamental aspect of most vulnerabilities that require an active attacker. Even for common implementation issues such as buffer overflows, SQL injection, OS command injection, and path traversal, the vulnerable program already has the authorization to run code or access files. The vulnerability arises when the attacker causes the program to run unexpected code or access unexpected files.


DEPRECATED: HTTP response splitting

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


Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')

Summary:
The product acts as an intermediary HTTP agent
         (such as a proxy or firewall) in the data flow between two
         entities such as a client and server, but it does not
         interpret malformed HTTP requests or responses in ways that
         are consistent with how the messages will be processed by
         those entities that are at the ultimate destination.

Request smuggling can be performed due to a multiple interpretation error, where the target is an intermediary or monitor, via a consistency manipulation (Transfer-Encoding and Content-Length headers).

An attacker could create HTTP messages to exploit a number of weaknesses including 1) the message can trick the web server to associate a URL with another URL's webpage and caching the contents of the webpage (web cache poisoning attack), 2) the message can be structured to bypass the firewall protection mechanisms and gain unauthorized access to a web application, and 3) the message can invoke a script or a page that returns client credentials (similar to a Cross Site Scripting attack).


UI Discrepancy for Security Feature

Summary: The user interface does not correctly enable or configure a security feature, but the interface provides feedback that causes the user to believe that the feature is in a secure state.

This entry is likely a loose composite that could be broken down into the different types of errors that cause the user interface to have incorrect interactions with the underlying security feature.


Unimplemented or Unsupported Feature in UI

Summary: A UI function for a security feature appears to be supported and gives feedback to the user that suggests that it is supported, but the underlying functionality is not implemented.

This issue needs more study, as there are not many examples. It is not clear whether it is primary or resultant.


Obsolete Feature in UI

Summary: A UI function is obsolete and the product does not warn the user.


The UI Performs the Wrong Action

Summary: The UI performs the wrong action with respect to the user's request.


Path Equivalence: 'file...name' (Multiple Internal Dot)

Summary: The product accepts path input in the form of multiple internal dot ('file...dir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.


Multiple Interpretations of UI Input

Summary: The UI has multiple interpretations of user input but does not prompt the user when it selects the less secure interpretation.


User Interface (UI) Misrepresentation of Critical Information

Summary: The user interface (UI) does not properly represent critical information to the user, allowing the information - or its source - to be obscured or spoofed. This is often a component in phishing attacks.

This entry should be broken down into more precise entries. See extended description.

Misrepresentation problems are frequently studied in web browsers, but there are no known efforts for classifying these kinds of problems in terms of the shortcomings of the interface. In addition, many misrepresentation issues are resultant.


Insecure Default Variable Initialization

Summary: The product, by default, initializes an internal variable with an insecure or less secure value than is possible.

This overlaps other categories, probably should be split into separate items.

An attacker could gain access to and modify sensitive data or system information.


External Initialization of Trusted Variables or Data Stores

Summary: The product initializes critical internal variables or data stores using inputs that can be modified by untrusted actors.

Overlaps Missing variable initialization, especially in PHP.


Non-exit on Failed Initialization

Summary: The product does not exit or otherwise modify its operation when security-relevant errors occur during initialization, such as when a configuration file has a format error or a hardware security module (HSM) cannot be activated, which can cause the product to execute in a less secure fashion than intended by the administrator.

Under-studied. These issues are not frequently reported, and it is difficult to find published examples.

The application could be placed in an insecure state that may allow an attacker to modify sensitive data or allow unintended logic to be executed.


Missing Initialization of a Variable

Summary: The product does not initialize critical variables, which causes the execution environment to use unexpected values.

This weakness is a major factor in a number of resultant weaknesses, especially in web applications that allow global variable initialization (such as PHP) with libraries that can be directly requested.

It is highly likely that a large number of resultant weaknesses have missing initialization as a primary factor, but researcher reports generally do not provide this level of detail.

The uninitialized data may be invalid, causing logic errors within the program. In some cases, this could result in a security problem.


Use of Uninitialized Variable

Summary: The code uses a variable that has not been initialized, leading to unpredictable or unintended results.

Initial variables usually contain junk, which can not be trusted for consistency. This can lead to denial of service conditions, or modify control flow in unexpected ways. In some cases, an attacker can "pre-initialize" the variable using previous actions, which might enable code execution. This can cause a race condition if a lock variable check passes when it should not.

Strings that are not initialized are especially dangerous, since many functions expect a null at the end -- and only at the end -- of a string.


DEPRECATED: Incorrect Initialization

Summary: This weakness has been deprecated because its name and description did not match. The description duplicated CWE-454, while the name suggested a more abstract initialization problem. Please refer to CWE-665 for the more abstract problem.


Incomplete Cleanup

Summary: The product does not properly "clean up" and remove temporary or supporting resources after they have been used.

CWE-459 is a child of CWE-404 because, while CWE-404 covers any type of improper shutdown or release of a resource, CWE-459 deals specifically with a multi-step shutdown process in which a crucial step for "proper" cleanup is omitted or impossible. That is, CWE-459 deals specifically with a cleanup or shutdown process that does not successfully remove all potentially sensitive data.

Overlaps other categories such as permissions and containment. Concept needs further development. This could be primary (e.g. leading to infoleak) or resultant (e.g. resulting from unhandled error conditions or early termination).

It is possible to overflow the number of temporary files because directories typically have limits on the number of files allowed. This could create a denial of service problem.


Path Equivalence: 'filename ' (Trailing Space)

Summary: The product accepts path input in the form of trailing space ('filedir ') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.


Improper Cleanup on Thrown Exception

Summary: The product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.


Duplicate Key in Associative List (Alist)

Summary: Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error.


Deletion of Data Structure Sentinel

Summary: The accidental deletion of a data-structure sentinel can cause serious programming logic problems.

Generally this error will cause the data structure to not work properly.

If a control character, such as NULL is removed, one may cause resource access control problems.


Addition of Data Structure Sentinel

Summary: The accidental addition of a data-structure sentinel can cause serious programming logic problems.

Generally this error will cause the data structure to not work properly by truncating the data.


Return of Pointer Value Outside of Expected Range

Summary: A function can return a pointer to memory that is outside of the buffer that the pointer is expected to reference.

This entry should have a chaining relationship with CWE-119 instead of a parent / child relationship, however the focus of this weakness does not map cleanly to any existing entries in CWE. A new parent is being considered which covers the more generic problem of incorrect return values. There is also an abstract relationship to weaknesses in which one component sends incorrect messages to another component; in this case, one routine is sending an incorrect value to another.


Use of sizeof() on a Pointer Type

Summary: The code calls sizeof() on a pointer type, which can be an incorrect calculation if the programmer intended to determine the size of the data that is being pointed to.

This error can often cause one to allocate a buffer that is much smaller than what is needed, leading to resultant weaknesses such as buffer overflows.


Incorrect Pointer Scaling

Summary: In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.

Incorrect pointer scaling will often result in buffer overflow conditions. Confidentiality can be compromised if the weakness is in the context of a buffer over-read or under-read.


Use of Pointer Subtraction to Determine Size

Summary: The product subtracts one pointer from another in order to determine size, but this calculation can be incorrect if the pointers do not exist in the same memory chunk.

There is the potential for arbitrary code execution with privileges of the vulnerable program.


Path Equivalence: ' filename' (Leading Space)

Summary: The product accepts path input in the form of leading space (' filedir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.


Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

Summary: The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.

The attacker might be able to execute code that is not directly accessible to the attacker. Alternately, the attacker could call unexpected code in the wrong place or the wrong time, possibly modifying critical system state.

The attacker might be able to use reflection to call the wrong code, possibly with unexpected arguments that violate the API (CWE-227). This could cause the product to exit or hang.

By causing the wrong code to be invoked, the attacker might be able to trigger a runtime error that leaks sensitive information in the error message, such as CWE-536.


Modification of Assumed-Immutable Data (MAID)

Summary: The product does not properly protect an assumed-immutable element from being modified by an attacker.

MAID issues can be primary to many other weaknesses, and they are a major factor in languages that provide easy access to internal program constructs, such as PHP's register_globals and similar features. However, MAID issues can also be resultant from weaknesses that modify internal state; for example, a program might validate some data and store it in memory, but a buffer overflow could overwrite that validated data, leading to a change in program logic.

There are many examples where the MUTABILITY property is a major factor in a vulnerability.

Common data types that are attacked are environment variables, web application parameters, and HTTP headers.


External Control of Assumed-Immutable Web Parameter

Summary: The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.

This is a primary weakness for many other weaknesses and functional consequences, including XSS, SQL injection, path disclosure, and file inclusion.

This is a technology-specific MAID problem.

Without appropriate protection mechanisms, the client can easily tamper with cookies and similar web data. Reliance on the cookies without detailed validation can lead to problems such as SQL injection. If you use cookie values for security related decisions on the server side, manipulating the cookies might lead to violations of security policies such as authentication bypassing, user impersonation and privilege escalation. In addition, storing sensitive data in the cookie without appropriate protection can also lead to disclosure of sensitive user data, especially data stored in persistent cookies.


PHP External Variable Modification

Summary: A PHP application does not properly protect against the modification of variables from external sources, such as query parameters or cookies. This can expose the application to numerous weaknesses that would not exist otherwise.

This is a language-specific instance of Modification of Assumed-Immutable Data (MAID). This can be resultant from direct request (alternate path) issues. It can be primary to weaknesses such as PHP file inclusion, SQL injection, XSS, authentication bypass, and others.


Use of Function with Inconsistent Implementations

Summary: The code uses a function that has inconsistent implementations across operating systems and versions.


Undefined Behavior for Input to API

Summary: The behavior of this function is undefined unless its control parameter is set to a specific value.

The Linux Standard Base Specification 2.0.1 for libc places constraints on the arguments to some internal functions [21]. If the constraints are not met, the behavior of the functions is not defined. It is unusual for this function to be called directly. It is almost always invoked through a macro defined in a system header file, and the macro ensures that the following constraints are met: The value 1 must be passed to the third parameter (the version number) of the following file system function: __xmknod The value 2 must be passed to the third parameter (the group argument) of the following wide character string functions: __wcstod_internal __wcstof_internal __wcstol_internal __wcstold_internal __wcstoul_internal The value 3 must be passed as the first parameter (the version number) of the following file system functions: __xstat __lxstat __fxstat __xstat64 __lxstat64 __fxstat64


NULL Pointer Dereference

NPD

Common abbreviation for Null Pointer Dereference

NPE

Common abbreviation for Null Pointer Exception

nil pointer dereference

used for access of nil in Go programs

Summary: The product dereferences a pointer that it expects to be valid but is NULL.

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

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.

NULL pointer dereferences usually result in the failure of the process unless exception handling (on some platforms) is available and implemented. Even when exception handling is being used, it can still be very difficult to return the software to a safe state of operation.

In rare circumstances, when NULL is equivalent to the 0x0 memory address and privileged code can access it, then writing or reading memory is possible, which may lead to code execution.


Use of Obsolete Function

Summary: The code uses deprecated or obsolete functions, which suggests that the code has not been actively reviewed or maintained.


Missing Default Case in Multiple Condition Expression

Summary: The code does not have a default case in an expression with multiple conditions, such as a switch statement.

Depending on the logical circumstances involved, any consequences may result: e.g., issues of confidentiality, authentication, authorization, availability, integrity, accountability, or non-repudiation.


Signal Handler Use of a Non-reentrant Function

Summary: The product defines a signal handler that calls a non-reentrant function.

It may be possible to execute arbitrary code through the use of a write-what-where condition.

Signal race conditions often result in data corruption.


Path Equivalence: 'file name' (Internal Whitespace)

Summary: The product accepts path input in the form of internal space ('file(SPACE)name') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.

This weakness is likely to overlap quoting problems, e.g. the "Program Files" unquoted search path (CWE-428). It also could be an equivalence issue if filtering removes all extraneous spaces.

Whitespace can be a factor in other weaknesses not directly related to equivalence. It can also be used to spoof icons or hide files with dangerous names (see icon manipulation and visual truncation in CWE-451).


Use of Incorrect Operator

Summary: The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.

This weakness can be found easily using static analysis. However in some cases an operator might appear to be incorrect, but is actually correct and reflects unusual logic within the program.

This weakness can cause unintended logic to be executed and other unexpected application behavior.


Assigning instead of Comparing

Summary: The code uses an operator for assignment when the intention was to perform a comparison.


Comparing instead of Assigning

Summary: The code uses an operator for comparison when the intention was to perform an assignment.

The assignment will not take place, which should cause obvious program execution problems.


Incorrect Block Delimitation

Summary: The code does not explicitly delimit a block that is intended to contain 2 or more statements, creating a logic error.

This is a general logic error which will often lead to obviously-incorrect behaviors that are quickly noticed and fixed. In lightly tested or untested code, this error may be introduced it into a production environment and provide additional attack vectors by creating a control flow path leading to an unexpected state in the application. The consequences will depend on the types of behaviors that are being incorrectly executed.


Omitted Break Statement in Switch

Summary: The product omits a break statement within a switch or similar construct, causing code associated with multiple conditions to execute. This can cause problems when the programmer only intended to execute code associated with one condition.

Omission of a break statement might be intentional, in order to support fallthrough. Automated detection methods might therefore be erroneous. Semantic understanding of expected product behavior is required to interpret whether the code is correct.

Since this weakness is associated with a code construct, it would be indistinguishable from other errors that produce the same behavior.


Comparison of Classes by Name

Summary: The product compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name.

If a product relies solely on the name of an object to determine identity, it may execute the incorrect or unintended code.


Reliance on Package-level Scope

Summary: Java packages are not inherently closed; therefore, relying on them for code security is not a good practice.

Any data in a Java package can be accessed outside of the Java framework if the package is distributed.

The data in a Java class can be modified by anyone outside of the Java framework if the packages is distributed.


Exposure of Data Element to Wrong Session

Summary: The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.


Active Debug Code

Leftover debug code

This term originates from Seven Pernicious Kingdoms

Summary: The product is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information.

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

In J2EE a main method may be a good indicator that debug code has been left in the application, although there may not be any direct security impact.

The severity of the exposed debug application will depend on the particular instance. At the least, it will give an attacker sensitive information about the settings and mechanics of web applications on the server. At worst, as is often the case, the debug application will allow an attacker complete control over the web application and server, as well as confidential information that either of these access.


Path Equivalence: 'filename/' (Trailing Slash)

Summary: The product accepts path input in the form of trailing slash ('filedir/') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.


Public cloneable() Method Without Final ('Object Hijack')

Summary: A class has a cloneable() method that is not declared final, which allows an object to be created without calling the constructor. This can cause the object to be in an unexpected state.


Use of Inner Class Containing Sensitive Data

Summary: Inner classes are translated into classes that are accessible at package scope and may expose code that the programmer intended to keep private to attackers.

Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running.

"Inner Classes" data confidentiality aspects can often be overcome.


Critical Public Variable Without Final Modifier

Summary: The product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values.

The object could potentially be tampered with.

The object could potentially allow the object to be read.


Download of Code Without Integrity Check

Summary: The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.

This is critical for mobile code, but it is likely to become more and more common as developers continue to adopt automated, network-based product distributions and upgrades. Software-as-a-Service (SaaS) might introduce additional subtleties. Common exploitation scenarios may include ad server compromises and bad upgrades.

Executing untrusted code could compromise the control flow of the program. The untrusted code could execute attacker-controlled commands, read or modify sensitive resources, or prevent the software from functioning correctly for legitimate users.


Private Data Structure Returned From A Public Method

Summary: The product has a method that is declared public, but returns a reference to a private data structure, which could then be modified in unexpected ways.

The contents of the data structure can be modified from outside the intended scope.


Public Data Assigned to Private Array-Typed Field

Summary: Assigning public data to a private array is equivalent to giving public access to the array.

The contents of the array can be modified from outside the intended scope.


Exposure of Sensitive System Information to an Unauthorized Control Sphere

Summary: The product does not properly prevent sensitive system-level information from being accessed by unauthorized actors who do not have the same level of access to the underlying system as the product does.


Cloneable Class Containing Sensitive Information

Summary: The code contains a class with sensitive data, but the class is cloneable. The data can then be accessed by cloning the class.

A class that can be cloned can be produced without executing the constructor. This is dangerous since the constructor may perform security-related checks. By allowing the object to be cloned, those checks may be bypassed.


Serializable Class Containing Sensitive Data

Summary: The code contains a class with sensitive data, but the class does not explicitly deny serialization. The data can be accessed by serializing the class through another class.

an attacker can write out the class to a byte stream, then extract the important data from it.


J2EE Misconfiguration: Data Transmission Without Encryption

Summary: Information sent over a network can be compromised while in transit. An attacker may be able to read or modify the contents if the data are sent in plaintext or are weakly encrypted.


Summary: The product accepts path input in the form of multiple leading slash ('//multiple/leading/slash') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.


Public Static Field Not Marked Final

Summary: An object contains a public static field that is not marked final, which might allow it to be modified in unexpected ways.