deardaniel/secdata-raw huggingface dataset:
CWE-837: Improper Enforcement of a Single, Unique Action

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

Extended Description:
In various applications, a user is only expected to perform a certain action once, such as voting, requesting a refund, or making a purchase. When this restriction is not enforced, sometimes this can have security implications. For example, in a voting application, an attacker could attempt to "stuff the ballot box" by voting multiple times. If these votes are counted separately, then the attacker could directly affect who wins the vote. This could have significant business impact depending on the purpose of the product.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Web Based, Web Server
Parent weaknesses: CWE-799

Consequences:
  - Other: Varies by Context

Real-world examples:
  - CVE-2008-0294: Ticket-booking web application allows a user to lock a seat more than once.
  - CVE-2005-4051: CMS allows people to rate downloads by voting more than once.
  - CVE-2002-216: Polling software allows people to vote more than once by setting a cookie.
  - CVE-2003-1433: Chain: lack of validation of a challenge key in a game allows a player to register multiple times and lock other players out of the game.
  - CVE-2002-1018: Library feature allows attackers to check out the same e-book multiple times, preventing other users from accessing copies of the e-book.
CWE-84: Improper Neutralization of Encoded URI Schemes in a Web Page

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

Affected languages: Not Language-Specific
Affected technologies: Web Based, Web Server
Parent weaknesses: CWE-79

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - [Implementation] Resolve all URIs to absolute or canonical representations before processing.
  - [Implementation] Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fie
  - [Implementation] Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or au
  - [Implementation] With Struts, write all data from form beans with the bean's filter attribute set to true.

Real-world examples:
  - CVE-2005-0563: Cross-site scripting (XSS) vulnerability in Microsoft Outlook Web Access (OWA) component in Exchange Server 5.5 allows remote attackers to inject arbitrary web script or HTML via an email message with
  - CVE-2005-2276: Cross-site scripting (XSS) vulnerability in Novell Groupwise WebAccess 6.5 before July 11, 2005 allows remote attackers to inject arbitrary web script or HTML via an e-mail message with an encoded jav
  - CVE-2005-0692: Encoded script within BBcode IMG tag.
  - CVE-2002-0117: Encoded "javascript" in IMG tag.
  - CVE-2002-0118: Encoded "javascript" in IMG tag.
CWE-841: Improper Enforcement of Behavioral Workflow

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

Extended Description:
By performing actions in an unexpected order, or by omitting steps, an attacker could manipulate the business logic of the product or cause it to enter an invalid state. In some cases, this can also expose resultant weaknesses. 
             For example, a file-sharing protocol might require that an actor perform separate steps to provide a username, then a password, before being able to transfer files. If the file-sharing server accepts a password command followed by a transfer command, without any username being provided, the product might still perform the transfer. 
             Note that this is different than CWE-696, which focuses on when the product performs actions in the wrong sequence; this entry is closely related, but it is focused on ensuring that the actor performs actions in the correct sequence. 
             Workflow-related behaviors include: 
                
                   Steps are performed in the expected order. 
                   Required steps are not omi

Affected languages: Not Language-Specific
Parent weaknesses: CWE-691

Consequences:
  - Other: Alter Execution Logic

Detection methods:
  - Automated Static Analysis: 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 havin

Demonstrative examples:
This code is part of an FTP server and deals with various commands that could be sent by a user. It is intended that a user must successfully login before performing any other action such as retrieving or listing files.
The server correctly avoids sending files to a user that isn't logged in and doesn't own the file. However, the server will incorrectly list the files in any directory without confirming the command came from an authenticated user, and that the user is authorized to see the directory's contents.
def dispatchCommand(command, user, args): 
                         if command == 'Login': loginUser(args) return 
                            
                            
                            # user has requested a file 
                            if command == 'Retrieve_f

Real-world examples:
  - CVE-2011-0348: Bypass of access/billing restrictions by sending traffic to an unrestricted destination before sending to a restricted destination.
  - CVE-2007-3012: Attacker can access portions of a restricted page by canceling out of a dialog.
  - CVE-2009-5056: Ticket-tracking system does not enforce a permission setting.
  - CVE-2004-2164: Shopping cart does not close a database connection when user restores a previous order, leading to connection exhaustion.
  - CVE-2003-0777: Chain: product does not properly handle dropped connections, leading to missing NULL terminator (CWE-170) and segmentation fault.
CWE-842: Placement of User into Incorrect Group

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

Extended Description:
If the incorrect group has more access or privileges than the intended group, the user might be able to bypass intended security policy to access unexpected resources or perform unexpected actions. The access-control system might not be able to detect malicious usage of this group membership.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-286

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Real-world examples:
  - CVE-1999-1193: Operating system assigns user to privileged wheel group, allowing the user to gain root privileges.
  - CVE-2010-3716: Chain: drafted web request allows the creation of users with arbitrary group membership.
  - CVE-2008-5397: Chain: improper processing of configuration options causes users to contain unintended group memberships.
  - CVE-2007-6644: CMS does not prevent remote administrators from promoting other users to the administrator group, in violation of the intended security model.
  - CVE-2007-3260: Product assigns members to the root group, allowing escalation of privileges.
CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')

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

Extended Description:
When the product accesses the resource using an incompatible type, this could trigger logical errors because the resource does not have expected properties. In languages without memory safety, such as C and C++, type confusion can lead to out-of-bounds memory access. 
             While this weakness is frequently associated with unions when parsing data with many different embedded object types in C, it can be present in any application that can interpret the same variable or memory location in multiple ways. 
             This weakness is not unique to C and C++. For example, errors in PHP applications can be triggered by providing array parameters when scalars are expected, or vice versa. Languages such as Perl, which perform automatic conversion of a variable of one type when it is accessed as if it were another type, can also contain these issues.

Affected languages: C, C++
Parent weaknesses: CWE-704, CWE-704

Consequences:
  - Availability: Read Memory

Detection methods:
  - Automated Static Analysis: 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 havin

Demonstrative examples:
The following code uses a union to support the representation of different types of messages. It formats messages differently, depending on their type.
The code intends to process the message as a NAME_TYPE, and sets the default message to "Hello World." However, since both buf.name and buf.nameID are part of the same union, they can act as aliases for the same memory location, depending on memory layout after compilation.
#define NAME_TYPE 1 #define ID_TYPE 2 
                      struct MessageBuffer { int msgType; union { char *name; int nameID; }; }; 
                      
                      int main (int argc, char **argv) { 
                         struct MessageBuffer buf; char *defaultMessage = "Hello World"; 
                            buf.msgType = NAME_TYPE; buf.name = de

The following PHP code accepts a value, adds 5, and prints the sum.
When called with the following query string:
$value = $_GET['value']; $sum = $value + 5; echo "value parameter is '$value'<p>"; echo "SUM is $sum";

Real-world examples:
  - CVE-2025-32352: Type confusion in PHP app allows authentication bypass when users have passwords whose MD5 hashes can be interpreted as numbers
  - CVE-2010-4577: Type confusion in CSS sequence leads to out-of-bounds read.
  - CVE-2011-0611: Size inconsistency allows code execution, first discovered when it was actively exploited in-the-wild.
  - CVE-2010-0258: Improperly-parsed file containing records of different types leads to code execution when a memory location is interpreted as a different object than intended.
CWE-85: Doubled Character XSS Manipulations

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

Affected languages: Not Language-Specific
Affected technologies: Web Based, Web Server
Parent weaknesses: CWE-79

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Implementation] Resolve all filtered input to absolute or canonical representations before processing.
  - [Implementation] Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fie
  - [Implementation] Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or au
  - [Implementation] With Struts, write all data from form beans with the bean's filter attribute set to true.

Real-world examples:
  - CVE-2002-2086: XSS using "<script".
  - CVE-2000-0116: Encoded "javascript" in IMG tag.
  - CVE-2001-1157: Extra "<" in front of SCRIPT tag.
CWE-86: Improper Neutralization of Invalid Characters in Identifiers in Web Pages

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

Extended Description:
Some web browsers may remove these sequences, resulting in output that may have unintended control implications. For example, the product may attempt to remove a "javascript:" URI scheme, but a "java%00script:" URI may bypass this check and still be rendered as active javascript by some browsers, allowing XSS or other attacks.

Affected languages: Not Language-Specific
Affected technologies: Web Based, Web Server
Parent weaknesses: CWE-79, CWE-436

Consequences:
  - Confidentiality: Read Application Data

Detection methods:
  - Automated Static Analysis: 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 havin

Mitigations:
  - [Implementation] Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or au
  - [Implementation] To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to maliciou

Real-world examples:
  - CVE-2004-0595: XSS filter doesn't filter null characters before looking for dangerous tags, which are ignored by web browsers. Multiple Interpretation Error (MIE) and validate-before-cleanse.
CWE-87: Improper Neutralization of Alternate XSS Syntax

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

Affected languages: Not Language-Specific
Parent weaknesses: CWE-79

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Implementation] Resolve all input to absolute or canonical representations before processing.
  - [Implementation] Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fie
  - [Implementation] Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or au
  - [Implementation] With Struts, write all data from form beans with the bean's filter attribute set to true.

Demonstrative examples:
In the following example, an XSS neutralization method intends to replace script tags in user-supplied input with a safe equivalent:
The code only works when the "script" tag is in all lower-case, forming an incomplete denylist (CWE-184). Equivalent tags such as "SCRIPT" or "ScRiPt" will not be neutralized by this method, allowing an XSS attack.
public String preventXSS(String input, String mask) { return input.replaceAll("script", mask); }

Real-world examples:
  - CVE-2002-0738: XSS using "&={script}".
CWE-9: J2EE Misconfiguration: Weak Access Permissions for EJB Methods

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

Extended Description:
If the EJB deployment descriptor contains one or more method permissions that grant access to the special ANYONE role, it indicates that access control for the application has not been fully thought through or that the application is structured in such a way that reasonable access control restrictions are impossible.

Affected languages: Java
Parent weaknesses: CWE-266

Consequences:
  - Other: Other

Mitigations:
  - [Architecture and Design] Follow the principle of least privilege when assigning access rights to EJB methods. Permission to invoke EJB methods should not be granted to the ANYONE role.

Demonstrative examples:
The following deployment descriptor grants ANYONE permission to invoke the Employee EJB's method named getSalary().

<ejb-jar> ... <assembly-descriptor> <method-permission> <role-name>ANYONE</role-name> <method> <ejb-name>Employee</ejb-name> <method-name>getSalary</method-name> </method-permission> </assembly-descriptor> ... </ejb-jar>
CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')

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

Affected languages: Not Language-Specific
Affected technologies: Database Server
Parent weaknesses: CWE-943

Consequences:
  - Confidentiality: Execute Unauthorized Code or Commands

Detection methods:
  - Automated Static Analysis: 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 havin

Mitigations:
  - [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. 
                   When pe

Demonstrative examples:
The code below constructs an LDAP query using user input address data:
Because the code fails to neutralize the address string used to construct the query, an attacker can supply an address that includes additional LDAP queries.
context = new InitialDirContext(env); String searchFilter = "StreetAddress=" + address; NamingEnumeration answer = context.search(searchBase, searchFilter, searchCtls);

Real-world examples:
  - CVE-2021-41232: Chain: authentication routine in Go-based agile development product does not escape user name (CWE-116), allowing LDAP injection (CWE-90)
  - CVE-2005-2301: Server does not properly escape LDAP queries, which allows remote attackers to cause a DoS and possibly conduct an LDAP injection attack.
CWE-909: Missing Initialization of Resource

Description:
The product does not initialize a critical resource.

Extended Description:
Many resources require initialization before they can be properly used. If a resource is not initialized, it could contain unpredictable or expired data, or it could be initialized to defaults that are invalid. This can have security implications when the resource is expected to have certain properties or values.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-665, CWE-665

Consequences:
  - Confidentiality: Read Memory
  - Availability: DoS: Crash, Exit, or Restart

Detection methods:
  - Automated Static Analysis: 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 havin

Mitigations:
  - [Implementation] Explicitly initialize the resource before use. If this is performed through an API function or standard procedure, follow all specified steps.
  - [Implementation] Pay close attention to complex conditionals that affect initialization, since some branches might not perform the initialization.
  - [Implementation] Avoid race conditions (CWE-362) during initialization routines.
  - [Build and Compilation] Run or compile your product with settings that generate warnings about uninitialized variables or data.

Demonstrative examples:
Here, a boolean initiailized field is consulted to ensure that initialization tasks are only completed once. However, the field is mistakenly set to true during static initialization, so the initialization code is never reached.

private boolean initialized = true; public void someMethod() { 
                         if (!initialized) { 
                               
                                  
                                  // perform initialization tasks 
                                  ... 
                                  initialized = true; 
                            }

The following code intends to limit certain operations to the administrator only.
If the application is unable to extract the state information - say, due to a database timeout - then the $uid variable will not be explicitly set by the programmer. This will cause $uid to be regarded as equivalent to "0" in the conditional, allowing the original user to perform administrator actions. Even if the attacker cannot directly influence the state data, unexpected errors could cause incorrect privileges to be assigned to a user just by accident.
$username = GetCurrentUser(); $state = GetStateData($username); if (defined($state)) { $uid = ExtractUserID($state); } 
                      
                      # do stuff 
                      if ($uid == 0) { DoAdminThings(); }

Real-world examples:
  - CVE-2020-20739: A variable that has its value set in a conditional statement is sometimes used when the conditional fails, sometimes causing data leakage
  - CVE-2005-1036: Chain: Bypass of access restrictions due to improper authorization (CWE-862) of a user results from an improperly initialized (CWE-909) I/O permission bitmap
CWE-91: XML Injection (aka Blind XPath Injection)

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

Extended Description:
Within XML, special elements could include reserved words or characters such as "<", ">", """, and "&", which could then be used to add new data or modify XML syntax.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-74, CWE-74

Consequences:
  - Confidentiality: Execute Unauthorized Code or Commands

Detection methods:
  - Automated Static Analysis: 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 havin

Mitigations:
  - [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. 
                   When pe
CWE-910: Use of Expired File Descriptor

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

Extended Description:
After a file descriptor for a particular file or device has been released, it can be reused. The code might not write to the original file, since the reused file descriptor might reference a different file or device.

Affected languages: C, C++, Not Language-Specific
Parent weaknesses: CWE-672

Consequences:
  - Confidentiality: Read Files or Directories
  - Availability: DoS: Crash, Exit, or Restart

Detection methods:
  - Automated Static Analysis: 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 havin