Trust Boundary Violation

Summary: The product mixes trusted and untrusted data in the same data structure or structured message.


Deserialization of Untrusted Data

Marshaling, Unmarshaling

Marshaling and unmarshaling are effectively synonyms for serialization and deserialization, respectively.

Pickling, Unpickling

In Python, the "pickle" functionality is used to perform serialization and deserialization.

PHP Object Injection

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

Summary: The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.

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

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

Attackers can modify unexpected objects or data that was assumed to be safe from modification. Deserialized data or code could be modified without using the provided accessor functions, or unexpected functions could be invoked.

If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.

The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used. Making an assumption that the code in the deserialized object is valid is dangerous and can enable exploitation. One example is attackers using gadget chains to perform unauthorized actions, such as generating a shell.


Embedded Malicious Code

Summary: The product contains code that appears to be malicious in nature.

Manual Static Analysis - Binary or Bytecode

Dynamic Analysis with Manual Results Interpretation

The term "Trojan horse" was introduced by Dan Edwards and recorded by James Anderson [18] to characterize a particular computer security threat; it has been redefined many times [4,18-20].


Trojan Horse

Summary: The product appears to contain benign or useful functionality, but it also contains code that is hidden from normal operation that violates the intended security policy of the user or the system administrator.

Potentially malicious dynamic code compiled at runtime can conceal any number of attacks that will not appear in the baseline. The use of dynamically compiled code could also allow the injection of attacks on post-deployed applications.


Non-Replicating Malicious Code

Summary: Non-replicating malicious code only resides on the target system or product that is attacked; it does not attempt to spread to other systems.


Replicating Malicious Code (Virus or Worm)

Summary: Replicating malicious code, including viruses and worms, will attempt to attack other systems once it has successfully compromised the target system or the product.


Summary: The product accepts path input in the form of multiple internal slash ('/multiple//internal/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.


Trapdoor

Summary: A trapdoor is a hidden piece of code that responds to a special input, allowing its user access to resources without passing through the normal security enforcement mechanism.

Automated Static Analysis - Binary or Bytecode


Logic/Time Bomb

Summary: The product contains code that is designed to disrupt the legitimate operation of the product (or its environment) when a certain time passes, or when a certain logical condition is met.


Spyware

Summary: The product collects personally identifiable information about a human user or the user's activities, but the product accesses this information using other resources besides itself, and it does not require that user's explicit approval or direct input into the product.


Covert Channel

Summary: A covert channel is a path that can be used to transfer information in a way not intended by the system's designers.

A covert channel can be thought of as an emergent resource, meaning that it was not an originally intended resource, however it exists due the application's behaviors.

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.


Covert Storage Channel

Summary: A covert storage channel transfers information through the setting of bits by one program and the reading of those bits by another. What distinguishes this case from that of ordinary operation is that the bits are used to convey encoded information.

Covert storage channels may provide attackers with important information about the system in question.

If these messages or packets are sent with unnecessary data contained within, it may tip off malicious listeners as to the process that created the message. With this information, attackers may learn any number of things, including the hardware platform, operating system, or algorithms used by the sender. This information can be of significant value to the user in launching further attacks.


DEPRECATED: Covert Timing Channel

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


Summary: The product accepts path input in the form of multiple trailing slash ('/multiple/trailing/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.


.NET Misconfiguration: Use of Impersonation

Summary: Allowing a .NET application to run at potentially escalated levels of access to the underlying operating and file systems can be dangerous and result in various forms of attacks.


Weak Password Requirements

Summary: The product does not require that users should have strong passwords, which makes it easier for attackers to compromise user accounts.

An attacker could easily guess user passwords and gain access user accounts.


Insufficiently Protected Credentials

Summary: The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.

An attacker could gain access to user accounts and access sensitive data used by the user accounts.


Unprotected Transport of Credentials

Summary: Login pages do not use adequate measures to protect the user name and password while they are in transit from the client to the server.


Use of Cache Containing Sensitive Information

Summary: The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.


Use of Web Browser Cache Containing Sensitive Information

Summary: The web application does not use an appropriate caching policy that specifies the extent to which each web page and associated form fields should be cached.

Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.


Cleartext Storage of Sensitive Information in an Environment Variable

Summary: The product uses an environment variable to store unencrypted sensitive information.


Exposure of Version-Control Repository to an Unauthorized Control Sphere

Summary: The product stores a CVS, git, or other repository in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized actors.


Exposure of Core Dump File to an Unauthorized Control Sphere

Summary: The product generates a core dump file in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized actors.


Exposure of Access Control List Files to an Unauthorized Control Sphere

Summary: The product stores access control list files in a directory or other container that is accessible to actors outside of the intended control sphere.


Summary: The product accepts path input in the form of multiple internal backslash ('\multiple\trailing\\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.


Exposure of Backup File to an Unauthorized Control Sphere

Summary: A backup file is stored in a directory or archive that is made accessible to unauthorized actors.

At a minimum, an attacker who retrieves this file would have all the information contained in it, whether that be database calls, the format of parameters accepted by the application, or simply information regarding the architectural structure of your site.


Inclusion of Sensitive Information in Test Code

Summary: Accessible test applications can pose a variety of security risks. Since developers or administrators rarely consider that someone besides themselves would even know about the existence of these applications, it is common for them to contain sensitive information or functions.


Insertion of Sensitive Information into Log File

Summary: The product writes sensitive information to a log file.

Logging sensitive user data, full path names, or system information often provides attackers with an additional, less-protected path to acquiring the information.


DEPRECATED: Information Exposure Through Server Log Files

Summary: This entry has been deprecated because its abstraction was too low-level.  See CWE-532.


DEPRECATED: Information Exposure Through Debug Log Files


Exposure of Information Through Shell Error Message

Summary: A command shell error message indicates that there exists an unhandled exception in the web application code. In many cases, an attacker can leverage the conditions that cause these errors in order to gain unauthorized access to the system.


Servlet Runtime Error Message Containing Sensitive Information

Summary: A servlet error message indicates that there exists an unhandled exception in your web application code and may provide useful information to an attacker.

The error message may contain the location of the file in which the offending function is located. This may disclose the web root's absolute path as well as give the attacker the location of application files or configuration information. It may even disclose the portion of code that failed. In many cases, an attacker can use the data to launch further attacks against the system.


Java Runtime Error Message Containing Sensitive Information

Summary: In many cases, an attacker can leverage the conditions that cause unhandled exception errors in order to gain unauthorized access to the system.


Insertion of Sensitive Information into Externally-Accessible File or Directory

Summary: The product places sensitive information into files or directories that are accessible to actors who are allowed to have access to the files, but not to the sensitive information.

Depending on usage, this could be a weakness or a category. Further study of all its children is needed, and the entire sub-tree may need to be clarified. The current organization is based primarily on the exposure of sensitive information as a consequence, instead of as a primary weakness.

There is a close relationship with CWE-552, which is more focused on weaknesses. As a result, it may be more appropriate to convert CWE-538 to a category.


Use of Persistent Cookies Containing Sensitive Information

Summary: The web application uses persistent cookies, but the cookies contain sensitive information.


Path Equivalence: 'filedir\' (Trailing Backslash)

Summary: The product accepts path input in the form of trailing backslash ('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.


Inclusion of Sensitive Information in Source Code

Summary: Source code on a web server or repository often contains sensitive information and should generally not be accessible to users.


Inclusion of Sensitive Information in an Include File

Summary: If an include file source is accessible, the file can contain usernames and passwords, as well as sensitive information pertaining to the application and system.


DEPRECATED: Information Exposure Through Cleanup Log Files


Use of Singleton Pattern Without Synchronization in a Multithreaded Context

Summary: The product uses the singleton pattern when creating a resource within a multithreaded environment.


Missing Standardized Error Handling Mechanism

Summary: The product does not use a standardized method for handling errors throughout the code, which might introduce inconsistent error handling and resultant weaknesses.


DEPRECATED: Use of Dynamic Class Loading

Summary: This weakness has been deprecated because it partially overlaps CWE-470, it describes legitimate programmer behavior, and other portions will need to be integrated into other entries.


Suspicious Comment

Summary: The code contains comments that suggest the presence of bugs, incomplete functionality, or weaknesses.

Suspicious comments could be an indication that there are problems in the source code that may need to be fixed and is an indication of poor quality. This could lead to further bugs and the introduction of weaknesses.


Use of Hard-coded, Security-relevant Constants

Summary: The product uses hard-coded constants instead of symbolic names for security-critical values, which increases the likelihood of mistakes during code maintenance or security policy change.

The existence of hardcoded constants could cause unexpected behavior and the introduction of weaknesses during code maintenance or when making changes to the code if all occurrences are not modified. The use of hardcoded constants is an indication of poor quality.


Exposure of Information Through Directory Listing

Summary: A directory listing is inappropriately exposed, yielding potentially sensitive information to attackers.

Exposing the contents of a directory can lead to an attacker gaining access to source code or providing useful information for the attacker to devise exploits, such as creation times of files or any information that may be encoded in file names. The directory listing may also compromise private or confidential data.


Missing Password Field Masking

Summary: The product does not mask passwords during entry, increasing the potential for attackers to observe and capture passwords.


Path Equivalence: '/./' (Single Dot Directory)

Summary: The product accepts path input in the form of single dot directory exploit ('/./') 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.


Server-generated Error Message Containing Sensitive Information

Summary: Certain conditions, such as network failure, will cause a server error message to be displayed.


Incorrect Behavior Order: Authorization Before Parsing and Canonicalization

Summary: If a web server does not fully parse requested URLs before it examines them for authorization, it may be possible for an attacker to bypass authorization protection.


Files or Directories Accessible to External Parties

Summary: The product makes files or directories accessible to unauthorized actors, even though they should not be.


Command Shell in Externally Accessible Directory

Summary: A possible shell file exists in /cgi-bin/ or other accessible directories. This is extremely dangerous and can be used by an attacker to execute commands on the web server.


ASP.NET Misconfiguration: Not Using Input Validation Framework

Summary: The ASP.NET application does not use an input validation framework.

Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others.


J2EE Misconfiguration: Plaintext Password in Configuration File

Summary: The J2EE application stores a plaintext password in a configuration file.


ASP.NET Misconfiguration: Use of Identity Impersonation

Summary: Configuring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges.


Use of getlogin() in Multithreaded Application

Summary: The product uses the getlogin() function in a multithreaded context, potentially causing it to return incorrect values.


Path Equivalence: 'filedir*' (Wildcard)

Summary: The product accepts path input in the form of asterisk wildcard ('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 umask() with chmod-style Argument

Summary: The product calls umask() with an incorrect argument that is specified as if it is an argument to chmod().

Some umask() manual pages begin with the false statement: "umask sets the umask to mask & 0777" Although this behavior would better align with the usage of chmod(), where the user provided argument specifies the bits to enable on the specified file, the behavior of umask() is in fact opposite: umask() sets the umask to ~mask & 0777. The documentation goes on to describe the correct usage of umask(): "The umask is used by open() to set initial file permissions on a newly-created file. Specifically, permissions in the umask are turned off from the mode argument to open(2) (so, for example, the common umask default value of 022 results in new files being created with permissions 0666 & ~022 = 0644 = rw-r--r-- in the usual case where the mode is specified as 0666)."


Dead Code

Summary: The product contains dead code, which can never be executed.

Dynamic Analysis with Automated Results Interpretation

Dead code that results from code that can never be executed is an indication of problems with the source code that needs to be fixed and is an indication of poor quality.


Return of Stack Variable Address

Summary: A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.

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.

If the returned stack buffer address is dereferenced after the return, then an attacker may be able to modify or read memory, depending on how the address is used.  If the address is used for reading, then the address itself may be exposed, or the contents that the address points to.  If the address is used for writing, this can lead to a crash and possibly code execution.


Assignment to Variable without Use

Summary: The variable's value is assigned but never used, making it a dead store.

This weakness could be an indication of a bug in the program or a deprecated variable that was not removed and is an indication of poor quality. This could lead to further bugs and the introduction of weaknesses.


SQL Injection: Hibernate

Summary: Using Hibernate to execute a dynamic SQL statement built with user-controlled input can allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.


Reliance on Cookies without Validation and Integrity Checking

Summary: The product relies on the existence or values of cookies when performing security-critical operations, but it does not properly ensure that the setting is valid for the associated user.

This problem can be primary to many types of weaknesses in web applications. A developer may perform proper validation against URL parameters while assuming that attackers cannot modify cookies. As a result, the program might skip basic input validation to enable cross-site scripting, SQL injection, price tampering, and other attacks..

It is dangerous to use cookies to set a user's privileges. The cookie can be manipulated to escalate an attacker's privileges to an administrative level.


Authorization Bypass Through User-Controlled SQL Primary Key

Summary: The product uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.


Unsynchronized Access to Shared Data in a Multithreaded Context

Summary: The product does not properly synchronize shared data, such as static variables across threads, which can lead to undefined behavior and unpredictable data changes.

If the shared variable contains sensitive data, it may be manipulated or displayed in another user session. If this data is used to control the application, its value can be manipulated to cause the application to crash or perform poorly.


finalize() Method Without super.finalize()

Summary: The product contains a finalize() method that does not call super.finalize().


Summary: The product contains protection mechanisms to restrict access to 'realdir/filename', but it constructs pathnames using external input in the form of 'fakedir/../realdir/filename' that are not handled by those mechanisms. This allows attackers to perform unauthorized actions against the targeted file.

This is a manipulation that uses an injection for one consequence (containment violation using relative path) to achieve a different consequence (equivalence by alternate name).


Expression is Always False

Summary: The product contains an expression that will always evaluate to false.


Expression is Always True

Summary: The product contains an expression that will always evaluate to true.


Call to Thread run() instead of start()

Summary: The product calls a thread's run() method instead of calling start(), which causes the code to run in the thread of the caller instead of the callee.


Improper Following of Specification by Caller

Summary: The product does not follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.


EJB Bad Practices: Use of Synchronization Primitives

Summary: The product violates the Enterprise JavaBeans (EJB) specification by using thread synchronization primitives.


EJB Bad Practices: Use of AWT Swing

Summary: The product violates the Enterprise JavaBeans (EJB) specification by using AWT/Swing.


EJB Bad Practices: Use of Java I/O

Summary: The product violates the Enterprise JavaBeans (EJB) specification by using the java.io package.


EJB Bad Practices: Use of Sockets

Summary: The product violates the Enterprise JavaBeans (EJB) specification by using sockets.


EJB Bad Practices: Use of Class Loader

Summary: The product violates the Enterprise JavaBeans (EJB) specification by using the class loader.


J2EE Bad Practices: Non-serializable Object Stored in Session

Summary: The product stores a non-serializable object as an HttpSession attribute, which can hurt reliability.


Path Equivalence: Windows 8.3 Filename

Summary: The product contains a protection mechanism that restricts access to a long filename on a Windows operating system, but it does not properly restrict access to the equivalent short "8.3" filename.


clone() Method Without super.clone()

Summary: The product contains a clone() method that does not call super.clone() to obtain the new object.


Object Model Violation: Just One of Equals and Hashcode Defined

Summary: The product does not maintain equal hashcodes for equal objects.

If this invariant is not upheld, it is likely to cause trouble if objects of this class are stored in a collection. If the objects of the class in question are used as a key in a Hashtable or if they are inserted into a Map or Set, it is critical that equal objects have equal hashcodes.


Array Declared Public, Final, and Static

Summary: The product declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified.


finalize() Method Declared Public

Summary: The product violates secure coding principles for mobile code by declaring a finalize() method public.


Return Inside Finally Block

Summary: The code has a return statement inside a finally block, which will cause any thrown exception in the try block to be discarded.


Empty Synchronized Block

Summary: The product contains an empty synchronized block.

An empty synchronized block will wait until nobody else is using the synchronizer being specified. While this may be part of the desired behavior, because you haven't protected the subsequent code by placing it inside the synchronized block, nothing is stopping somebody else from modifying whatever it was you were waiting for while you run the subsequent code.


Explicit Call to Finalize()

Summary: The product makes an explicit call to the finalize() method from outside the finalizer.


Assignment of a Fixed Address to a Pointer

Summary: The product sets a pointer to a specific address other than NULL or 0.

If one executes code at a known location, an attacker might be able to inject code there beforehand.

If the code is ported to another platform or environment, the pointer is likely to be invalid and cause a crash.

The data at a known pointer location can be easily read or influenced by an attacker.


Attempt to Access Child of a Non-structure Pointer

Summary: Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption.

Adjacent variables in memory may be corrupted by assignments performed on fields after the cast.

Execution may end due to a memory access error.


Call to Non-ubiquitous API

Summary: The product uses an API function that does not exist on all versions of the target platform. This could cause portability problems or inconsistencies that allow denial of service or other consequences.


Improper Link Resolution Before File Access ('Link Following')

insecure temporary file

Some people use the phrase "insecure temporary file" when referring to a link following weakness, but other weaknesses can produce insecure temporary files without any symlink involvement at all.

Zip Slip

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

Summary: The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.

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 then an attacker may be able to bypass the mechanism.

Windows simple shortcuts, sometimes referred to as soft links, can be exploited remotely since a ".LNK" file can be uploaded like a normal file. This can enable remote execution.


Free of Memory not on the Heap

Summary: The product calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().

In C++, if the new operator was used to allocate the memory, it may be allocated with the malloc(), calloc() or realloc() family of functions in the implementation. Someone aware of this behavior might choose to map this problem to CWE-590 or to its parent, CWE-762, depending on their perspective.

There is the potential for arbitrary code execution with privileges of the vulnerable program via a "write, what where" primitive. If pointers to memory which hold user information are freed, a malicious user will be able to write 4 bytes anywhere in memory.


Sensitive Data Storage in Improperly Locked Memory

Summary: The product stores sensitive data in memory that is not locked, or that has been incorrectly locked, which might cause the memory to be written to swap files on disk by the virtual memory manager. This can make the data more accessible to external actors.

Sensitive data that is written to a swap file may be exposed.


DEPRECATED: Authentication Bypass Issues

Summary: This weakness has been deprecated because it covered redundant concepts already described in CWE-287.


Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created

Summary: The product modifies the SSL context after connection creation has begun.

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 a sniffing attack.


J2EE Framework: Saving Unserializable Objects to Disk

Summary: When the J2EE container attempts to write unserializable objects to disk there is no guarantee that the process will complete successfully.

Data represented by unserializable objects can be corrupted.

Non-serializability of objects can lead to system crash.


Comparison of Object References Instead of Object Contents

Summary: The product compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.

This weakness can lead to erroneous results that can cause unexpected application behaviors.


DEPRECATED: Incorrect Semantic Object Comparison

Summary: This weakness has been deprecated.  It was poorly described and difficult to distinguish from other entries.  It was also inappropriate to assign a separate ID solely because of domain-specific considerations.  Its closest equivalent is CWE-1023.


Use of Wrong Operator in String Comparison

Summary: The product uses the wrong operator when comparing a string, such as using "==" when the .equals() method should be used instead.


Use of GET Request Method With Sensitive Query Strings

Summary: The web application uses the HTTP GET method to process a request and includes sensitive information in the query string of that request.

At a minimum, attackers can garner information from query strings that can be utilized in escalating their method of attack, such as information about the internal workings of the application or database column names. Successful exploitation of query string parameter vulnerabilities could lead to an attacker impersonating a legitimate user, obtaining proprietary data, or simply executing actions not intended by the application developers.


Missing Validation of OpenSSL Certificate

Summary: The product uses OpenSSL and trusts or uses a certificate without using the SSL_get_verify_result() function to ensure that the certificate satisfies all necessary security requirements.

CWE-295 and CWE-599 are very similar, although CWE-599 has a more narrow scope that is only applied to OpenSSL certificates. As a result, other children of CWE-295 can be regarded as children of CWE-599 as well. CWE's use of one-dimensional hierarchical relationships is not well-suited to handle different kinds of abstraction relationships based on concepts like types of resources ("OpenSSL certificate" as a child of "any certificate") and types of behaviors ("not validating expiration" as a child of "improper validation").

The data read may not be properly secured, it might be viewed by an attacker.

Trust afforded to the system in question may allow for spoofing or redirection attacks.

If the certificate is not checked, it may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to provide data under the guise of a trusted host. While the attacker in question may have a valid certificate, it may simply be a valid certificate for a different site. In order to ensure data integrity, we must check that the certificate is valid, and that it pertains to the site we wish to access.


J2EE Misconfiguration: Insufficient Session-ID Length

Summary: The J2EE application is configured to use an insufficient session ID length.

If an attacker can guess an authenticated user's session identifier, they can take over the user's session.


Uncaught Exception in Servlet

Summary: The Servlet does not catch all exceptions, which may reveal sensitive debugging information.

The "Missing Catch Block" concept is probably broader than just Servlets, but the broader concept is not sufficiently covered in CWE.


URL Redirection to Untrusted Site ('Open Redirect')

Summary: The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.

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

Automated black box tools that supply URLs to every input may be able to spot Location header modifications, but test case coverage is a factor, and custom redirects may not be detected.

Automated static analysis tools may not be able to determine whether input influences the beginning of a URL, which is important for reducing false positives.

Whether this issue poses a vulnerability will be subject to the intended behavior of the application. For example, a search engine might intentionally provide redirects to arbitrary URLs.

The user may be redirected to an untrusted page that contains malware which may then compromise the user's machine. This will expose the user to extensive risk and the user's interaction with the web server may also be compromised if the malware conducts keylogging or other attacks that steal credentials, personally identifiable information (PII), or other important data.

By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam. The user may be subjected to phishing attacks by being redirected to an untrusted page. The phishing attack may point to an attacker controlled web page that appears to be a trusted web site. The phishers may then steal the user's credentials and then use these credentials to access the legitimate web site. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance.


Client-Side Enforcement of Server-Side Security

Summary: The product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.

Client-side validation checks can be easily bypassed, allowing malformed or unexpected input to pass into the application, potentially as trusted data. This may lead to unexpected states, behaviors and possibly a resulting crash.

Client-side checks for authentication can be easily bypassed, allowing clients to escalate their access levels and perform unintended actions.


Use of Client-Side Authentication

Summary: A client/server product performs authentication within client code but not in server code, allowing server-side authentication to be bypassed via a modified client that omits the authentication check.


Multiple Binds to the Same Port

Summary: When multiple sockets are allowed to bind to the same port, other services on that port may be stolen or spoofed.

Packets from a variety of network services may be stolen or the services spoofed.


Unchecked Input for Loop Condition

Summary: The product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service or other consequences because of excessive looping.


Public Static Final Field References Mutable Object

Summary: A public or protected static final field references a mutable object, which allows the object to be changed by malicious code, or accidentally from another package.


Struts: Non-private Field in ActionForm Class

Summary: An ActionForm class contains a field that has not been declared private, which can be accessed without using a setter or getter.


Double-Checked Locking

Summary: The product uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.


UNIX Symbolic Link (Symlink) Following

Summary: The product, when opening a file or directory, does not sufficiently account for when the file is a symbolic link that resolves to a target outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.


Externally Controlled Reference to a Resource in Another Sphere

Summary: The product uses an externally controlled name or reference that resolves to a resource that is outside of the intended control sphere.

This is a general class of weakness, but most research is focused on more specialized cases, such as path traversal (CWE-22) and symlink following (CWE-61). A symbolic link has a name; in general, it appears like any other file in the file system. However, the link includes a reference to another file, often in another directory - perhaps in another sphere of control. Many common library functions that accept filenames will "follow" a symbolic link and use the link's target instead.

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


Improper Restriction of XML External Entity Reference

XXE

An acronym used for the term "XML eXternal Entities"

Summary: The product processes an XML document that can contain XML entities with URIs that resolve to documents outside of the intended sphere of control, causing the product to embed incorrect documents into its output.

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

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

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

The product could consume excessive CPU cycles or memory using a URI that points to a large file, or a device that always returns data such as /dev/random. Alternately, the URI could reference a file that contains many nested or recursive entity references to further slow down parsing.


Improper Authorization of Index Containing Sensitive Information

Summary: The product creates a search index of private or sensitive documents, but it does not properly limit index access to actors who are authorized to see the original information.

This weakness is probably under-studied and under-reported.


Insufficient Session Expiration

Summary: According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."

The lack of proper session expiration may improve the likely success of certain attacks. For example, an attacker may intercept a session ID, possibly via a network sniffer or Cross-site Scripting attack. Although short session expiration times do not help if a stolen token is immediately used, they will protect against ongoing replaying of the session ID. In another scenario, a user might access a web site from a shared computer (such as at a library, Internet cafe, or open work environment). Insufficient Session Expiration could allow an attacker to use the browser's back button to access web pages previously accessed by the victim.


Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

Summary: The Secure attribute for sensitive cookies in HTTPS sessions is not set, which could cause the user agent to send those cookies in plaintext over an HTTP session.


Inclusion of Sensitive Information in Source Code Comments

Summary: While adding general comments is very useful, some programmers tend to leave important data, such as: filenames related to the web application, old links or links which were not meant to be browsed by users, old code fragments, etc.


Incomplete Identification of Uploaded File Variables (PHP)

Summary: The PHP application uses an old method for processing uploaded files by referencing the four global variables that are set for each file (e.g. $varname, $varname_size, $varname_name, $varname_type). These variables could be overwritten by attackers, causing the application to process unauthorized files.


Reachable Assertion

Summary: The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.

An attacker that can trigger an assert statement can still lead to a denial of service if the relevant code can be triggered by an attacker, and if the scope of the assert() extends beyond the attacker's own session.


Exposed Unsafe ActiveX Method

Summary: An ActiveX control is intended for use in a web browser, but it exposes dangerous methods that perform actions that are outside of the browser's security model (e.g. the zone or domain).


Dangling Database Cursor ('Cursor Injection')

Summary: If a database cursor is not closed properly, then it could become accessible to other users while retaining the same privileges that were originally assigned, leaving the cursor "dangling."


UNIX Hard Link

Summary: The product, when opening a file or directory, does not sufficiently account for when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.


Unverified Password Change

Summary: When setting a new password for a user, the product does not require knowledge of the original password, or using another form of authentication.


Variable Extraction Error

Summary: The product uses external input to determine the names of variables into which information is extracted, without verifying that the names of the specified variables are valid. This could cause the program to overwrite unintended variables.

Probably under-reported for PHP. Seems under-studied for other interpreted languages.

An attacker could modify sensitive data or program variables.


Improper Validation of Function Hook Arguments

Summary: The product adds hooks to user-accessible API functions, but it does not properly validate the arguments. This could lead to resultant vulnerabilities.


Unsafe ActiveX Control Marked Safe For Scripting

Summary: An ActiveX control is intended for restricted use, but it has been marked as safe-for-scripting.


Executable Regular Expression Error

Summary: The product uses a regular expression that either (1) contains an executable component with user-controlled inputs, or (2) allows a user to enable execution by inserting pattern modifiers.

Under-studied. The existing PHP reports are limited to highly skilled researchers, but there are few examples for other languages. It is suspected that this is under-reported for all languages. Usability factors might make it more prevalent in PHP, but this theory has not been investigated.


Permissive Regular Expression

Summary: The product uses a regular expression that does not sufficiently restrict the set of allowed values.


Null Byte Interaction Error (Poison Null Byte)

Summary: The product does not properly handle null bytes or NUL characters when passing data between different representations or components.

Current usage of "poison null byte" is typically related to this C/Perl/PHP interaction error, but the original term in 1998 was applied to an off-by-one buffer overflow involving a null byte.

There are not many CVE examples, because the poison NULL byte is a design limitation, which typically is not included in CVE by itself. It is typically used as a facilitator manipulation to widen the scope of potential attacks against other vulnerabilities.


Dynamic Variable Evaluation

Summary: In a language where the user can influence the name of a variable at runtime, if the variable names are not controlled, an attacker can read or write to arbitrary variables, or access arbitrary functions.

Under-studied, probably under-reported. Few researchers look for this issue; most public reports are for PHP, although other languages are affected. This issue is likely to grow in PHP as developers begin to implement functionality in place of register_globals.

An attacker could gain unauthorized access to internal program variables and execute arbitrary code.


Function Call with Incorrectly Specified Arguments

Summary: The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.

Since these bugs typically introduce incorrect behavior that is obvious to users, they are found quickly, unless they occur in rarely-tested code paths. Managing the correct number of arguments can be made more difficult in cases where format strings are used, or when variable numbers of arguments are supported.

This weakness can cause unintended behavior and can lead to additional weaknesses such as allowing an attacker to gain unintended access to system resources.


Not Failing Securely ('Failing Open')

Summary: When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.

Since design issues are hard to fix, they are rarely publicly reported, so there are few CVE examples of this problem as of January 2008. Most publicly reported issues occur as the result of an implementation error instead of design, such as CVE-2005-3177 (Improper handling of large numbers of resources) or CVE-2005-2969 (inadvertently disabling a verification step, leading to selection of a weaker protocol).

Intended access restrictions can be bypassed, which is often contradictory to what the product's administrator expects.


Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism')

Summary: The product uses a more complex mechanism than necessary, which could lead to resultant weaknesses when the mechanism is not correctly understood, modeled, configured, implemented, or used.


Not Using Complete Mediation

Summary: The product does not perform access checks on a resource every time the resource is accessed by an entity, which can create resultant weaknesses if that entity's rights or privileges change over time.

A user might retain access to a critical resource even after privileges have been revoked, possibly allowing access to privileged functionality or sensitive information, depending on the role of the resource.


Authorization Bypass Through User-Controlled Key

Insecure Direct Object Reference / IDOR

The "Insecure Direct Object Reference" term, as described in the OWASP Top Ten, is broader than this CWE because it also covers path traversal (CWE-22). Within the context of vulnerability theory, there is a similarity between the OWASP concept and CWE-706: Use of Incorrectly-Resolved Name or Reference.

Broken Object Level Authorization / BOLA

BOLA is used in the 2019 OWASP API Security Top 10 and is said to be the same as IDOR.

Horizontal Authorization

"Horizontal Authorization" is used to describe situations in which two users have the same privilege level, but must be prevented from accessing each other's resources. This is fairly common when using key-based access to resources in a multi-user context.

Summary: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

Access control checks for specific user data or functionality can be bypassed.

Horizontal escalation of privilege is possible (one user can view/modify information of another user).

Vertical escalation of privilege is possible if the user-controlled key is actually a flag that indicates administrator status, allowing the attacker to gain administrative access.


Windows Shortcut Following (.LNK)

Summary: The product, when opening a file or directory, does not sufficiently handle when the file is a Windows shortcut (.LNK) whose target is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.

Under-studied. Windows .LNK files are more "portable" than Unix symlinks and have been used in remote exploits. Some Windows API's will access LNK's as if they are regular files, so one would expect that they would be reported more frequently.


Weak Password Recovery Mechanism for Forgotten Password

Summary: The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.

This entry might be reclassified as a category or "loose composite," since it lists multiple specific errors that can make the mechanism weak. However, under view 1000, it could be a weakness under protection mechanism failure, although it is different from most PMF issues since it is related to a feature that is designed to bypass a protection mechanism (specifically, the lack of knowledge of a password).

This entry probably needs to be split; see extended description.

An attacker could gain unauthorized access to the system by retrieving legitimate user's authentication credentials.

An attacker could deny service to legitimate system users by launching a brute force attack on the password recovery mechanism using user ids of legitimate users.

The system's security functionality is turned against the system by the attacker.


Improper Restriction of Names for Files and Other Resources

Summary: The product constructs the name of a file or other resource using input from an upstream component, but it does not restrict or incorrectly restricts the resulting name.

Execution of arbitrary code in the context of usage of the resources with dangerous names.

Crash of the consumer code of these resources resulting in information leakage or denial of service.


External Control of Critical State Data

Summary: The product stores security-critical state information about its users, or the product itself, in a location that is accessible to unauthorized actors.

An attacker could potentially modify the state in malicious ways. If the state is related to the privileges or level of authentication that the user has, then state modification might allow the user to bypass authentication or elevate privileges.

The state variables may contain sensitive information that should not be known by the client.

By modifying state variables, the attacker could violate the application's expectations for the contents of the state, leading to a denial of service due to an unexpected error condition.


Improper Neutralization of Data within XPath Expressions ('XPath Injection')

Summary: The product uses external input to dynamically construct an XPath expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.

This weakness is similar to other weaknesses that enable injection style attacks, such as SQL injection, command injection and LDAP injection. The main difference is that the target of attack here is the XML database.

Controlling application flow (e.g. bypassing authentication).

The attacker could read restricted XML content.


Improper Neutralization of HTTP Headers for Scripting Syntax

Summary: The product does not neutralize or incorrectly neutralizes web scripting syntax in HTTP headers that can be used by web browser components that can process raw headers, such as Flash.

Attackers may be able to obtain sensitive information.


Overly Restrictive Account Lockout Mechanism

Summary: The product contains an account lockout protection mechanism, but the mechanism is too restrictive and can be triggered too easily, which allows attackers to deny service to legitimate users by causing their accounts to be locked out.


Reliance on File Name or Extension of Externally-Supplied File

Summary: The product allows a file to be uploaded, but it relies on the file name or extension of the file to determine the appropriate behaviors. This could be used by attackers to cause the file to be misclassified and processed in a dangerous fashion.

An attacker may be able to read sensitive data.

An attacker may be able to cause a denial of service.

An attacker may be able to gain privileges.


Use of Non-Canonical URL Paths for Authorization Decisions

Summary: The product defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.

An attacker may be able to bypass the authorization mechanism to gain access to the otherwise-protected URL.

If a non-canonical URL is used, the server may choose to return the contents of the file, instead of pre-processing the file (e.g. as a program).


Incorrect Use of Privileged APIs

Summary: The product does not conform to the API requirements for a function call that requires extra privileges. This could allow attackers to gain privileges by causing the function to be called incorrectly.

An attacker may be able to elevate privileges.

An attacker may be able to obtain sensitive information.

An attacker may be able to execute code.


Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking

Summary: The product uses obfuscation or encryption of inputs that should not be mutable by an external actor, but the product does not use integrity checks to detect if those inputs have been modified.

The inputs could be modified without detection, causing the product to have unexpected system state or make incorrect security decisions.


Windows Hard Link

Summary: The product, when opening a file or directory, does not sufficiently handle when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.


Trusting HTTP Permission Methods on the Server Side

Summary: The server contains a protection mechanism that assumes that any URI that is accessed using HTTP GET will not cause a state change to the associated resource. This might allow attackers to bypass intended access restrictions and conduct resource modification and deletion attacks, since some applications allow GET to modify state.

An attacker could obtain sensitive information.


Exposure of WSDL File Containing Sensitive Information

Summary: The Web services architecture may require exposing a Web Service Definition Language (WSDL) file that contains information on the publicly accessible services and how callers of these services should interact with them (e.g. what parameters they expect and what types they return).

The attacker may find sensitive information located in the WSDL file.


Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')

Summary: The product uses external input to dynamically construct an XQuery expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.

An attacker might be able to read sensitive information from the XML database.


Improper Isolation or Compartmentalization

Separation of Privilege

Some people and publications use the term "Separation of Privilege" to describe this weakness, but this term has dual meanings in current usage. This node conflicts with the original definition of "Separation of Privilege" by Saltzer and Schroeder; that original definition is more closely associated with CWE-654. Because there are multiple interpretations, use of the "Separation of Privilege" term is discouraged.

Summary: The product does not properly compartmentalize or isolate functionality, processes, or resources that require different privilege levels, rights, or permissions.

There is a close association with CWE-250 (Execution with Unnecessary Privileges). CWE-653 is about providing separate components for each "privilege"; CWE-250 is about ensuring that each component has the least amount of privileges possible. In this fashion, compartmentalization becomes one mechanism for reducing privileges.

The term "Separation of Privilege" is used in several different ways in the industry, but they generally combine two closely related principles: compartmentalization (this node) and using only one factor in a security decision (CWE-654). Proper compartmentalization implicitly introduces multiple factors into a security decision, but there can be cases in which multiple factors are required for authentication or other mechanisms that do not involve compartmentalization, such as performing all required checks on a submitted certificate. It is likely that CWE-653 and CWE-654 will provoke further discussion.

The exploitation of a weakness in low-privileged areas of the software can be leveraged to reach higher-privileged areas without having to overcome any additional obstacles.


Reliance on a Single Factor in a Security Decision

Separation of Privilege

Some people and publications use the term "Separation of Privilege" to describe this weakness, but this term has dual meanings in current usage. While this entry is closely associated with the original definition of "Separation of Privilege" by Saltzer and Schroeder, others use the same term to describe poor compartmentalization (CWE-653). Because there are multiple interpretations, use of the "Separation of Privilege" term is discouraged.

Summary: A protection mechanism relies exclusively, or to a large extent, on the evaluation of a single condition or the integrity of a single object or entity in order to make a decision about granting access to restricted resources or functionality.

This entry is closely associated with the term "Separation of Privilege." This term is used in several different ways in the industry, but they generally combine two closely related principles: compartmentalization (CWE-653) and using only one factor in a security decision (this entry). Proper compartmentalization implicitly introduces multiple factors into a security decision, but there can be cases in which multiple factors are required for authentication or other mechanisms that do not involve compartmentalization, such as performing all required checks on a submitted certificate. It is likely that CWE-653 and CWE-654 will provoke further discussion.

If the single factor is compromised (e.g. by theft or spoofing), then the integrity of the entire security mechanism can be violated with respect to the user that is identified by that factor.

It can become difficult or impossible for the product to be able to distinguish between legitimate activities by the entity who provided the factor, versus illegitimate activities by an attacker.


Summary: The product has a protection mechanism that is too difficult or inconvenient to use, encouraging non-malicious users to disable or bypass the mechanism, whether by accident or on purpose.

This weakness covers many security measures causing user inconvenience, requiring effort or causing frustration, that are disproportionate to the risks or value of the protected assets, or that are perceived to be ineffective.

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.

By bypassing the security mechanism, a user might leave the system in a less secure state than intended by the administrator, making it more susceptible to compromise.


Reliance on Security Through Obscurity

Summary: The product uses a protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism.

Note that there is a close relationship between this weakness and CWE-603 (Use of Client-Side Authentication). If developers do not believe that a user can reverse engineer a client, then they are more likely to choose client-side authentication in the belief that it is safe.

The security mechanism can be bypassed easily.


Violation of Secure Design Principles

Summary: The product violates well-established principles for secure design.


Improper Handling of File Names that Identify Virtual Resources

Summary: The product does not handle or incorrectly handles a file name that identifies a "virtual" resource that is not directly specified within the directory that is associated with the file name, causing the product to perform file-based operations on a resource that is not a file.


Improper Synchronization

Summary: The product utilizes multiple threads or processes to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.

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


Use of a Non-reentrant Function in a Concurrent Context

Summary: The product calls a non-reentrant function in a concurrent context in which a competing code sequence (e.g. thread or signal handler) may have an opportunity to call the same function or otherwise influence its state.


Improper Control of a Resource Through its Lifetime

Summary: The product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.

More work is needed on this entry and its children. There are perspective/layering issues; for example, one breakdown is based on lifecycle phase (CWE-404, CWE-665), while other children are independent of lifecycle, such as CWE-400. Others do not specify as many bases or variants, such as CWE-704, which primarily covers numbers at this stage.


Improper Initialization

Summary: The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.

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.

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

If security-critical decisions rely on a variable having a "0" or equivalent value, and the programming language performs this initialization on behalf of the programmer, then a bypass of security may occur.

The uninitialized data may contain values that cause program flow to change in ways that the programmer did not intend. For example, if an uninitialized variable is used as an array index in C, then its previous contents may produce an index that is outside the range of the array, possibly causing a crash or an exit in other environments.


Operation on Resource in Wrong Phase of Lifetime

Summary: The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.


Improper Locking

Summary: The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

Inconsistent locking discipline can lead to deadlock.


Exposure of Resource to Wrong Sphere

Summary: The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.

A "control sphere" is a set of resources and behaviors that are accessible to a single actor, or a group of actors. A product's security model will typically define multiple spheres, possibly implicitly. For example, a server might define one sphere for "administrators" who can create new user accounts with subdirectories under /home/server/, and a second sphere might cover the set of users who can create or delete files within their own subdirectories. A third sphere might be "users who are authenticated to the operating system on which the product is installed." Each sphere has different sets of actors and allowable behaviors.


Incorrect Resource Transfer Between Spheres

Summary: The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.


Improper Handling of Windows Device Names

Summary: The product constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.


Always-Incorrect Control Flow Implementation

Summary: The code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated.

This node could possibly be split into lower-level nodes. "Early Return" is for returning control to the caller too soon (e.g., CWE-584). "Excess Return" is when control is returned too far up the call stack (CWE-600, CWE-395). "Improper control limitation" occurs when the product maintains control at a lower level of execution, when control should be returned "further" up the call stack (CWE-455). "Incorrect syntax" covers code that's "just plain wrong" such as CWE-484 and CWE-483.


Lack of Administrator Control over Security

Summary: The product uses security features in a way that prevents the product's administrator from tailoring security settings to reflect the environment in which the product is being used. This introduces resultant weaknesses or prevents it from operating at a level of security that is desired by the administrator.


Operation on a Resource after Expiration or Release

Summary: The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.

If a released resource is subsequently reused or reallocated, then an attempt to use the original resource might allow access to sensitive data that is associated with a different user or entity.

When a resource is released it might not be in an expected state, later attempts to access the resource may lead to resultant errors that may lead to a crash.


External Influence of Sphere Definition

Summary: The product does not prevent the definition of control spheres from external actors.


Uncontrolled Recursion

Summary: The product does not properly control the amount of recursion that takes place,  consuming excessive resources, such as allocated memory or the program stack.

Resources including CPU, memory, and stack memory could be rapidly consumed or exhausted, eventually leading to an exit or crash.

In some cases, an application's interpreter might kill a process or thread that appears to be consuming too much resources, such as with PHP's memory_limit setting. When the interpreter kills the process/thread, it might report an error containing detailed information such as the application's installation path.


Multiple Operations on Resource in Single-Operation Context

Summary: The product performs the same operation on a resource two or more times, when the operation should only be applied once.

This weakness is probably closely associated with other issues related to doubling, such as CWE-462 (duplicate key in alist) or CWE-102 (Struts duplicate validation forms). It's usually a case of an API contract violation (CWE-227).


Use of Potentially Dangerous Function

Summary: The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.

This weakness is different than CWE-242 (Use of Inherently Dangerous Function). CWE-242 covers functions with such significant security problems that they can never be guaranteed to be safe. Some functions, if used properly, do not directly pose a security risk, but can introduce a weakness if not called correctly. These are regarded as potentially dangerous. A well-known example is the strcpy() function. When provided with a destination buffer that is larger than its source, strcpy() will not overflow. However, it is so often misused that some developers prohibit strcpy() entirely.

If the function is used incorrectly, then it could result in security problems.


Integer Overflow to Buffer Overflow

Summary: The product performs a calculation to determine how much memory to allocate, but an integer overflow can occur that causes less memory to be allocated than expected, leading to a buffer overflow.


Incorrect Conversion between Numeric Types

Summary: When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.

The program could wind up using the wrong number and generate incorrect results. If the number is used to allocate resources or make a security decision, then this could introduce a vulnerability.


Incorrect Calculation

Summary: The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.

If the incorrect calculation causes the program to move into an unexpected state, it may lead to a crash or impairment of service.

If the incorrect calculation is used in the context of resource allocation, it could lead to an out-of-bounds operation (CWE-119) leading to a crash or even arbitrary code execution. Alternatively, it may result in an integer overflow (CWE-190) and / or a resource consumption problem (CWE-400).

In the context of privilege or permissions assignment, an incorrect calculation can provide an attacker with access to sensitive resources.

If the incorrect calculation leads to an insufficient comparison (CWE-697), it may compromise a protection mechanism such as a validation routine and allow an attacker to bypass the security-critical code.


Function Call With Incorrect Order of Arguments

Summary: The product calls a function, procedure, or routine, but the caller specifies the arguments in an incorrect order, leading to resultant weaknesses.


Incorrect Provision of Specified Functionality

Summary: The code does not function according to its published specifications, potentially leading to incorrect usage.


Function Call With Incorrect Number of Arguments

Summary: The product calls a function, procedure, or routine, but the caller specifies too many arguments, or too few arguments, which may lead to undefined behavior and resultant weaknesses.

While this weakness might be caught by the compiler in some languages, it can occur more frequently in cases in which the called function accepts variable numbers of arguments, such as format strings in C. It also can occur in languages or environments that do not require that functions always be called with the correct number of arguments, such as Perl.


Function Call With Incorrect Argument Type

Summary: The product calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.


Function Call With Incorrectly Specified Argument Value

Summary: The product calls a function, procedure, or routine, but the caller specifies an argument that contains the wrong value, which may lead to resultant weaknesses.

This might require an understanding of intended program behavior or design to determine whether the value is incorrect.

When primary, this weakness is most likely to occur in rarely-tested code, since the wrong value can change the semantic meaning of the program's execution and lead to obviously-incorrect behavior. It can also be resultant from issues in which the program assigns the wrong value to a variable, and that variable is later used in a function call. In that sense, this issue could be argued as having chaining relationships with many implementation errors in CWE.


Function Call With Incorrect Variable or Reference as Argument

Summary: The product calls a function, procedure, or routine, but the caller specifies the wrong variable or reference as one of the arguments, which may lead to undefined behavior and resultant weaknesses.

While this weakness might be caught by the compiler in some languages, it can occur more frequently in cases in which the called function accepts variable numbers of arguments, such as format strings in C. It also can occur in loosely typed languages or environments. This might require an understanding of intended program behavior or design to determine whether the value is incorrect.


Permission Race Condition During Resource Copy

Summary: The product, while copying or cloning a resource, does not set the resource's permissions or access control until the copy is complete, leaving the resource exposed to other spheres while the copy is taking place.

Under-studied. It seems likely that this weakness could occur in any situation in which a complex or large copy operation occurs, when the resource can be made available to other spheres as soon as it is created, but before its initialization is complete.


Improper Handling of Windows ::DATA Alternate Data Stream

Summary: The product does not properly prevent access to, or detect usage of, alternate data streams (ADS).

This and similar problems exist because the same resource can have multiple identifiers that dictate which behavior can be performed on the resource.


Unchecked Return Value to NULL Pointer Dereference

Summary: The product does not check for an error after calling a function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference.

This typically occurs in rarely-triggered error conditions, reducing the chances of detection during black box testing.

Code analysis can require knowledge of API behaviors for library functions that might return NULL, reducing the chances of detection when unknown libraries are used.

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.


Insufficient Control Flow Management

Summary: The code does not sufficiently manage its control flow during execution, creating conditions in which the control flow can be modified in unexpected ways.


Incomplete Denylist to Cross-Site Scripting

Summary: The product uses a denylist-based protection mechanism to defend against XSS attacks, but the denylist is incomplete, allowing XSS variants to succeed.


Protection Mechanism Failure

Summary: The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

The concept of protection mechanisms is well established, but protection mechanism failures have not been studied comprehensively. It is suspected that protection mechanisms can have significantly different types of weaknesses than the weaknesses that they are intended to prevent.


Use of Multiple Resources with Duplicate Identifier

Summary: The product uses multiple resources that can have the same identifier, in a context in which unique identifiers are required.

This weakness is probably closely associated with other issues related to doubling, such as CWE-675 (Duplicate Operations on Resource). It's often a case of an API contract violation (CWE-227).

If unique identifiers are assumed when protecting sensitive resources, then duplicate identifiers might allow attackers to bypass the protection.


Use of Low-Level Functionality

Summary: The product uses low-level functionality that is explicitly prohibited by the framework or specification under which the product is supposed to operate.

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


Incorrect Behavior Order

Summary: The product performs multiple related behaviors, but the behaviors are performed in the wrong order in ways which may produce resultant weaknesses.


Incorrect Comparison

Summary: The product compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.

This entry likely has some relationships with case sensitivity (CWE-178), but case sensitivity is a factor in other types of weaknesses besides comparison.  Also, in cryptography, certain attacks are possible when certain comparison operations do not take place in constant time, causing a timing-related information leak (CWE-208).


Execution After Redirect (EAR)

Summary: The web application sends a redirect to another location, but instead of exiting, it executes additional code.

This issue might not be detected if testing is performed using a web browser, because the browser might obey the redirect and move the user to a different page before the application has produced outputs that indicate something is amiss.

This weakness could affect the control flow of the application and allow execution of untrusted code.


J2EE Misconfiguration: Missing Custom Error Page

Summary: The default error page of a web application should not display sensitive information about the product.

A stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.


Improper Check or Handling of Exceptional Conditions

Summary: The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.

This is a high-level class that might have some overlap with other classes. It could be argued that even "normal" weaknesses such as buffer overflows involve unusual or exceptional conditions. In that sense, this might be an inherent aspect of most other weaknesses within CWE, similar to API Abuse (CWE-227) and Indicator of Poor Code Quality (CWE-398). However, this entry is currently intended to unify disparate concepts that do not have other places within the Research Concepts view (CWE-1000).


Incorrect Type Conversion or Cast

Summary: The product does not correctly convert an object, resource, or structure from one type to a different type.

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.


Incorrect Control Flow Scoping

Summary: The product does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.


Use of Incorrectly-Resolved Name or Reference

Summary: The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere.


Improper Neutralization

Summary: The product does not ensure or incorrectly ensures that structured messages or data are well-formed and that certain security properties are met before being read from an upstream component or sent to a downstream component.

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


Incorrect Ownership Assignment

Summary: The product assigns an owner to a resource, but the owner is outside of the intended control sphere.

An attacker could read and modify data for which they do not have permissions to access directly.


DEPRECATED: Apple '.DS_Store'

Summary: This entry has been deprecated as it represents a specific observed example of a UNIX Hard Link weakness type rather than its own individual weakness type. Please refer to CWE-62.


Improper Adherence to Coding Standards

Summary: The product does not follow certain coding rules for development, which can lead to resultant weaknesses or increase the severity of the associated vulnerabilities.


Improper Handling of Apple HFS+ Alternate Data Stream Path

Summary: The product does not properly handle special paths that may identify the data or resource fork of a file on the HFS+ file system.


External Control of File Name or Path

Summary: The product allows user input to control or influence paths or file names that are used in filesystem operations.

CWE-114 is a Class, but it is listed a child of CWE-73 in view 1000. This suggests some abstraction problems that should be resolved in future versions.

The application can operate on unexpected files. Confidentiality is violated when the targeted filename is not directly readable by the attacker.

The application can operate on unexpected files. This may violate integrity if the filename is written to, or if the filename is for a program or other form of executable code.

The application can operate on unexpected files. Availability can be violated if the attacker specifies an unexpected file that the application modifies. Availability can also be affected if the attacker specifies a filename for a large file, or points to a special device or a file that does not have the format that the application expects.


Incorrect Permission Assignment for Critical Resource

Summary: The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.

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.

Manual static analysis may be effective in detecting the use of custom permissions models and functions. The code could then be examined to identifying usage of the related functions. Then the human analyst could evaluate permission assignments in the context of the intended security model of the software.

Manual dynamic analysis may be effective in detecting the use of custom permissions models and functions. The program could then be executed with a focus on exercising code paths that are related to the custom permissions. Then the human analyst could evaluate permission assignments in the context of the intended security model of the software.

Fuzzing is not effective in detecting this weakness.

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

An attacker may be able to read sensitive information from the associated resource, such as credentials or configuration information stored in a file.

An attacker may be able to modify critical properties of the associated resource to gain privileges, such as replacing a world-writable executable with a Trojan horse.

An attacker may be able to destroy or corrupt critical data in the associated resource, such as deletion of records from a database.


Compiler Optimization Removal or Modification of Security-critical Code

Summary: The developer builds a security-critical protection mechanism into the software, but the compiler optimizes the program such that the mechanism is removed or modified.

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

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


Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')

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

Many people treat injection only as an input validation problem (CWE-20) because many people do not distinguish between the consequence/attack (injection) and the protection mechanism that prevents the attack from succeeding. However, input validation is only one potential protection mechanism (output encoding is another), and there is a chaining relationship between improper input validation and the improper enforcement of the structure of messages to other components. Other issues not directly related to input validation, such as race conditions, could similarly impact message structure.

Many injection attacks involve the disclosure of important information -- in terms of both data sensitivity and usefulness in further exploitation.

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

Injection attacks are characterized by the ability to significantly change the flow of a given process, and in some cases, to the execution of arbitrary code.

Data injection attacks lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing.

Often the actions performed by injected control code are unlogged.


Exposed Dangerous Method or Function

Summary: The product provides an Applications Programming Interface (API) or similar interface for interaction with external actors, but the interface includes a dangerous method or function that is not properly restricted.

Under-reported and under-studied. This weakness could appear in any technology, language, or framework that allows the programmer to provide a functional interface to external parties, but it is not heavily reported. In 2007, CVE began showing a notable increase in reports of exposed method vulnerabilities in ActiveX applications, as well as IOCTL access to OS-level resources. These weaknesses have been documented for Java applications in various secure programming sources, but there are few reports in CVE, which suggests limited awareness in most parts of the vulnerability research community.

Exposing critical functionality essentially provides an attacker with the privilege level of the exposed functionality. This could result in the modification or exposure of sensitive data or possibly even execution of arbitrary code.


Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)

Summary: The product does not adequately filter user-controlled input for special elements with control implications.


Improper Check for Unusual or Exceptional Conditions

Summary: The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

Automated static analysis may be useful for detecting unusual conditions involving system resources or common programming idioms, but not for violations of business rules.

Sometimes, when a return value can be used to indicate an error, an unchecked return value is a code-layer instance of a missing application-layer check for exceptional conditions. However, return values are not always needed to communicate exceptional conditions. For example, expiration of resources, values passed by reference, asynchronously modified data, sockets, etc. may indicate exceptional conditions without the use of a return value.

The data which were produced as a result of a function call could be in a bad state upon return. If the return value is not checked, then this bad data may be used in operations, possibly leading to a crash or other unintended behaviors.


Improper Handling of Exceptional Conditions

Summary: The product does not handle or incorrectly handles an exceptional condition.


Missing Custom Error Page

Summary: The product does not return custom error pages to the user, possibly exposing sensitive information.

Attackers can leverage the additional information provided by a default error page to mount attacks targeted on the framework, database, or other resources used by the application.


Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')

Summary: A protocol or its implementation supports interaction between multiple actors and allows those actors to negotiate which algorithm should be used as a protection mechanism such as encryption or authentication, but it does not select the strongest algorithm that is available to both parties.

This is related to CWE-300, although not all downgrade attacks necessarily require an entity that redirects or interferes with the network.  See examples.


Reliance on Undefined, Unspecified, or Implementation-Defined Behavior

Summary: The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.


Use of a One-Way Hash without a Salt

Summary: The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product does not also use a salt as part of the input.

If an attacker can gain access to the hashes, then the lack of a salt makes it easier to conduct brute force attacks using techniques such as rainbow tables.


Improper Neutralization of Equivalent Special Elements

Summary: The product correctly neutralizes certain special elements, but it improperly neutralizes equivalent special elements.


Use of a One-Way Hash with a Predictable Salt

Summary: The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product uses a predictable salt as part of the input.

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.


Free of Pointer not at Start of Buffer

Summary: The product calls free() on a pointer to a memory resource that was allocated on the heap, but the pointer is not at the start of the buffer.

Currently, CWE-763 is the parent, however it may be desirable to have an intermediate parent which is not function-specific, similar to how CWE-762 is an intermediate parent between CWE-763 and CWE-590.


Mismatched Memory Management Routines

Summary: The product attempts to return a memory resource to the system, but it calls a release function that is not compatible with the function that was originally used to allocate that resource.


Release of Invalid Pointer or Reference

Summary: The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly.

The view-1000 subtree that is associated with this weakness needs additional work. Several entries will likely be created in this branch. Currently the focus is on free() of memory, but delete and other related release routines may require the creation of intermediate entries that are not specific to a particular function. In addition, the role of other types of invalid pointers, such as an expired pointer, i.e. CWE-415 Double Free and release of uninitialized pointers, related to CWE-457.

This weakness may result in the corruption of memory, and perhaps instructions, possibly leading to a crash. If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code.


Multiple Locks of a Critical Resource

Summary: The product locks a critical resource more times than intended, leading to an unexpected state in the system.

An alternate way to think about this weakness is as an imbalance between the number of locks / unlocks in the control flow. Over the course of execution, if each lock call is not followed by a subsequent call to unlock in a reasonable amount of time, then system performance may be degraded or at least operating at less than peak levels if there is competition for the locks. This entry may need to be modified to reflect these concepts in the future.


Multiple Unlocks of a Critical Resource

Summary: The product unlocks a critical resource more times than intended, leading to an unexpected state in the system.


Critical Data Element Declared Public

Summary: The product declares a critical variable, field, or member to be public when intended security policy requires it to be private.

Making a critical variable public allows anyone with access to the object in which the variable is contained to alter or read the value.


Access to Critical Private Variable via Public Method

Summary: The product defines a public method that reads or modifies a private variable.

This entry is closely associated with access control for public methods. If the public methods are restricted with proper access controls, then the information in the private variable will not be exposed to unexpected parties. There may be chaining or composite relationships between improper access controls and this weakness.


Incorrect Short Circuit Evaluation

Summary: The product contains a conditional statement with multiple logical expressions in which one of the non-leading expressions may produce side effects. This may lead to an unexpected state in the program after the execution of the conditional, because short-circuiting logic may prevent the side effects from occurring.

Widely varied consequences are possible if an attacker is aware of an unexpected state in the product after a conditional. It may lead to information exposure, a system crash, or even complete attacker control of the system.


DEPRECATED: Uncontrolled File Descriptor Consumption

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


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

Command injection

an attack-oriented phrase for this weakness. Note: often used when "OS command injection" (CWE-78) was intended.

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

If a malicious user injects a character (such as a semi-colon) that delimits the end of one command and the beginning of another, it may be possible to then insert an entirely new and unrelated command that was not intended to be executed. This gives an attacker a privilege or capability that they would not otherwise have.