deardaniel/secdata-raw huggingface dataset:
CWE-46: Path Equivalence: 'filename ' (Trailing Space)

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

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Web Based
Parent weaknesses: CWE-41, CWE-162

Consequences:
  - Confidentiality: Read Files or Directories

Real-world examples:
  - CVE-2001-0693: Source disclosure via trailing encoded space "%20"
  - CVE-2001-0778: Source disclosure via trailing encoded space "%20"
  - CVE-2001-1248: Source disclosure via trailing encoded space "%20"
  - CVE-2004-0280: Source disclosure via trailing encoded space "%20"
  - CVE-2004-2213: Source disclosure via trailing encoded space "%20"
CWE-460: Improper Cleanup on Thrown Exception

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

Extended Description:
Often, when functions or loops become complicated, some level of resource cleanup is needed throughout execution. Exceptions can disturb the flow of the code and prevent the necessary cleanup from happening.

Affected languages: C, C++, Java, C#
Parent weaknesses: CWE-459, CWE-755

Consequences:
  - Other: Varies by Context

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] If one breaks from a loop or function by throwing an exception, make sure that cleanup happens or that you should exit the program. Use throwing exceptions sparsely.

Demonstrative examples:
The following example demonstrates the weakness.
In this case, a thread might be left locked accidentally.
public class foo { 
                         public static final void main( String args[] ) { 
                               
                                  boolean returnValue; returnValue=doStuff(); 
                            } public static final boolean doStuff( ) { 
                               
                                  boolean threadLock; boolean truthvalue=true; try { 
                                     
                                        while( 
                                        //check some condition 
                                        ) { 
                                           
                                              threadLock=t
CWE-462: Duplicate Key in Associative List (Alist)

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

Extended Description:
A duplicate key entry -- if the alist is designed properly -- could be used as a constant time replace function. However, duplicate key entries could be inserted by mistake. Because of this ambiguity, duplicate key entries in an association list are not recommended and should not be allowed.

Affected languages: C, C++, Java, C#
Parent weaknesses: CWE-694

Consequences:
  - Other: Quality Degradation

Mitigations:
  - [Architecture and Design] Use a hash table instead of an alist.
  - [Architecture and Design] Use an alist which checks the uniqueness of hash keys with each entry before inserting the entry.

Demonstrative examples:
The following code adds data to a list and then attempts to sort the data.
Since basename is not necessarily unique, this may not sort how one would like it to be.
alist = [] while (foo()): #now assume there is a string data with a key basename queue.append(basename,data) queue.sort()
CWE-463: Deletion of Data Structure Sentinel

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

Extended Description:
Often times data-structure sentinels are used to mark structure of the data structure. A common example of this is the null character at the end of strings. Another common example is linked lists which may contain a sentinel to mark the end of the list. It is dangerous to allow this type of control data to be easily accessible. Therefore, it is important to protect from the deletion or modification outside of some wrapper interface which provides safety.

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

Consequences:
  - Availability: Other
  - Authorization: Other

Mitigations:
  - [Architecture and Design] Use an abstraction library to abstract away risky APIs. Not a complete solution.
  - [Build and Compilation] Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows. 
                   For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the c
  - [Operation] Use OS-level preventative functionality. Not a complete solution.

Demonstrative examples:
This example creates a null terminated string and prints it contents.
The string foo has space for 9 characters and a null terminator, but 10 characters are written to it. As a result, the string foo is not null terminated and calling printf() on it will have unpredictable and possibly dangerous results.
char *foo; int counter; foo=calloc(sizeof(char)*10); 
                      for (counter=0;counter!=10;counter++) { foo[counter]='a'; 
                      printf("%s\n",foo); }
CWE-464: Addition of Data Structure Sentinel

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

Extended Description:
Data-structure sentinels are often used to mark the structure of data. A common example of this is the null character at the end of strings or a special sentinel to mark the end of a linked list. It is dangerous to allow this type of control data to be easily accessible. Therefore, it is important to protect from the addition or modification of sentinels.

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

Consequences:
  - Integrity: Modify Application Data

Mitigations:
  - [Implementation] Encapsulate the user from interacting with data sentinels. Validate user input to verify that sentinels are not present.
  - [Implementation] Proper error checking can reduce the risk of inadvertently introducing sentinel values into data. For example, if a parsing function fails or encounters an error, it might return a value that is the same as the sentinel.
  - [Architecture and Design] Use an abstraction library to abstract away risky APIs. This is not a complete solution.
  - [Operation] Use OS-level preventative functionality. This is not a complete solution.

Demonstrative examples:
The following example assigns some
               character values to a list of characters and prints
               them each individually, and then as a string. The third
               character value is intended to be an integer taken from
               user input and converted to an int. The first print
               statement will print each character separated by a
               space.
However, if a NULL byte is read from stdin
               by fgetc, then it will return 0. When foo is printed as
               a string, the 0 at character foo[2] will act as a NULL
               terminator, and the second printf() statement will
			   not print foo[3].
char *foo; 
				   foo=malloc(sizeof(char)*5); 
				   foo[0]='a'; 
				   foo[1]='a'; 
				   foo[2]=fgetc(stdin); 
				   foo
CWE-466: Return of Pointer Value Outside of Expected Range

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

Affected languages: Memory-Unsafe, C, C++
Parent weaknesses: CWE-119, CWE-20

Consequences:
  - Confidentiality: 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
  - Automated Dynamic Analysis: Use tools that are integrated during
	     compilation to insert runtime error-checking mechanisms
	     related to memory safety errors, such as AddressSanitizer
	     (ASan) for C/C++ [REF-1518].
CWE-467: Use of sizeof() on a Pointer Type

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

Extended Description:
The use of sizeof() on a pointer can sometimes generate useful information. An obvious case is to find out the wordsize on a platform. More often than not, the appearance of sizeof(pointer) indicates a bug.

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

Consequences:
  - Integrity: Modify 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

Mitigations:
  - [Implementation] Use expressions such as "sizeof(*pointer)" instead of "sizeof(pointer)", unless you intend to run sizeof() on a pointer type to gain some platform independence or if you are allocating a variable on the stack.

Demonstrative examples:
Care should be taken to ensure sizeof returns the size of the data structure itself, and not the size of the pointer to the data structure.
In this example, sizeof(foo) returns the size of the pointer.
double *foo; ... foo = (double *)malloc(sizeof(foo));
double *foo; ... foo = (double *)malloc(sizeof(*foo));

This example defines a fixed username and password. The AuthenticateUser() function is intended to accept a username and a password from an untrusted user, and check to ensure that it matches the username and password. If the username and password match, AuthenticateUser() is intended to indicate that authentication succeeded.
In AuthenticateUser(), because sizeof() is applied to a parameter with an array type, the sizeof() call might return 4 on many modern architectures. As a result, the strncmp() call only checks the first four characters of the input password, resulting in a partial comparison (CWE-187), leading to improper authentication (CWE-287).
/* Ignore CWE-259 (hard-coded password) and CWE-309 (use of password system for authentication) for this example. */
CWE-468: Incorrect Pointer Scaling

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

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

Consequences:
  - Confidentiality: 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

Mitigations:
  - [Architecture and Design] Use a platform with high-level memory abstractions.
  - [Implementation] Always use array indexing instead of direct pointer manipulation.
  - [Architecture and Design] Use technologies for preventing buffer overflows.

Demonstrative examples:
This example attempts to calculate the position of the second byte of a pointer.
In this example, second_char is intended to point to the second byte of p. But, adding 1 to p actually adds sizeof(int) to p, giving a result that is incorrect (3 bytes off on 32-bit platforms). If the resulting memory address is read, this could potentially be an information leak. If it is a write, it could be a security-critical write to unauthorized memory-- whether or not it is a buffer overflow. Note that the above code may also be wrong in other ways, particularly in a little endian environment.
int *p = x; char * second_char = (char *)(p + 1);
CWE-469: Use of Pointer Subtraction to Determine Size

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

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

Consequences:
  - Access Control: Modify Memory

Detection methods:
  - Fuzzing: 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 rand
  - 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] Save an index variable. This is the recommended solution. Rather than subtract pointers from one another, use an index variable of the same size as the pointers in question. Use this variable to "walk" from one pointer to the other and calculate the difference. Always validate this number.

Demonstrative examples:
The following example contains the method size that is used to determine the number of nodes in a linked list. The method is passed a pointer to the head of the linked list.
However, the method creates a pointer that points to the end of the list and uses pointer subtraction to determine the number of nodes in the list by subtracting the tail pointer from the head pointer. There no guarantee that the pointers exist in the same memory area, therefore using pointer subtraction in this way could return incorrect results and allow other unintended behavior. In this example a counter should be used to determine the number of nodes in the list, as shown in the following code.
struct node { int data; struct node* next; }; 
                      
                      // Returns the number of node
CWE-47: Path Equivalence: ' filename' (Leading Space)

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

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

Consequences:
  - Confidentiality: Read Files or Directories
CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

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

Extended Description:
If the product uses external inputs to determine which class to instantiate or which method to invoke, then an attacker could supply values to select unexpected classes or methods. If this occurs, then the attacker could create control flow paths that were not intended by the developer. These paths could bypass authentication or access control checks, or otherwise cause the product to behave in an unexpected manner. This situation becomes a doomsday scenario if the attacker can upload files into a location that appears on the product's classpath (CWE-427) or add new entries to the product's classpath (CWE-426). Under either of these conditions, the attacker can use reflection to introduce new, malicious behavior into the product.

Affected languages: Java, PHP, Interpreted
Parent weaknesses: CWE-913, CWE-913, CWE-610, CWE-20

Consequences:
  - Integrity: Execute Unauthorized Code or Commands
  - Availability: DoS: Crash, Exit, or Restart
  - 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:
  - [Architecture and Design] Refactor your code to avoid using reflection.
  - [Architecture and Design] Do not use user-controlled inputs to select and load classes or code.
  - [Implementation] Apply strict input validation by using allowlists or indirect selection to ensure that the user is only selecting allowable classes or code.

Demonstrative examples:
A common reason that programmers use the
               reflection API is to implement their own command
               dispatcher. The following example shows a command
               dispatcher that does not use reflection:
A programmer might refactor this code to use reflection as follows:
String ctl = request.getParameter("ctl"); 
				  Worker ao = null; 
				  if (ctl.equals("Add")) {
				   
				  ao = new AddCommand();
				   
				  } 
				  else if (ctl.equals("Modify")) {
				   
				  ao = new ModifyCommand();
				   
				  } 
				  else {
				   
				  throw new UnknownActionError();
				   }
				   
				  ao.doAction(request);
String ctl = request.getParameter("ctl"); 
					Class cmdClass = Class.forName(ctl + "Command"); 
					Worker ao = (Worker) cmdClass.newInstance(); 
				

Real-world examples:
  - CVE-2[PII_REDACTED]: Cryptography API uses unsafe reflection when deserializing a private key
  - CVE-2004-2331: Database system allows attackers to bypass sandbox restrictions by using the Reflection API.
CWE-471: Modification of Assumed-Immutable Data (MAID)

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

Extended Description:
This occurs when a particular input is critical enough to the functioning of the application that it should not be modifiable at all, but it is. Certain resources are often assumed to be immutable when they are not, such as hidden form fields in web applications, cookies, and reverse DNS lookups.

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

Consequences:
  - Integrity: Modify Application Data
  - Integrity: Unexpected State

Mitigations:
  - [Architecture and Design] When the data is stored or transmitted through untrusted sources that could modify the data, implement integrity checks to detect unauthorized modification, or store/transmit the data in a trusted location that is free from external influence.

Demonstrative examples:
In the code excerpt below, an array returned by a Java method is modified despite the fact that arrays are mutable.

String[] colors = car.getAllPossibleColors(); colors[0] = "Red";

Real-world examples:
  - CVE-2002-1757: Relies on $PHP_SELF variable for authentication.
  - CVE-2005-1905: Gain privileges by modifying assumed-immutable code addresses that are accessed by a driver.
CWE-473: PHP External Variable Modification

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

Affected languages: PHP
Parent weaknesses: CWE-471

Consequences:
  - Integrity: Modify Application Data

Mitigations:
  - [Requirements] Carefully identify which variables can be controlled or influenced by an external user, and consider adopting a naming convention to emphasize when externally modifiable variables are being used. An application should be reluctant to trust variables that have been initialized outside of its trust bo

Real-world examples:
  - CVE-2000-0860: File upload allows arbitrary file read by setting hidden form variables to match internal variable names.
  - CVE-2001-0854: Mistakenly trusts $PHP_SELF variable to determine if include script was called by its parent.
  - CVE-2002-0764: PHP remote file inclusion by modified assumed-immutable variable.
  - CVE-2001-1025: Modify key variable when calling scripts that don't load a library that initializes it.
  - CVE-2003-0754: Authentication bypass by modifying array used for authentication.
CWE-474: Use of Function with Inconsistent Implementations

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

Extended Description:
The use of inconsistent implementations can cause changes in behavior when the code is ported or built under a different environment than the programmer expects, which can lead to security problems in some cases. 
             The implementation of many functions varies by platform, and at times, even by different versions of the same platform. Implementation differences can include: 
                
                   Slight differences in the way parameters are interpreted leading to inconsistent results. 
                   Some implementations of the function carry significant security risks. 
                   The function might not be defined on all platforms. 
                   The function might change which return codes it can provide, or change the meaning of its return codes.

Affected languages: C, PHP, Not Language-Specific
Parent weaknesses: CWE-758

Consequences:
  - Other: Quality Degradation

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:
  - [Architecture and Design] Do not accept inconsistent behavior from the API specifications when the deviant behavior increase the risk level.
CWE-475: Undefined Behavior for Input to API

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

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

Consequences:
  - Other: Quality Degradation

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