deardaniel/secdata-raw huggingface dataset:
CWE-670: Always-Incorrect Control Flow Implementation

Description:
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.

Extended Description:
This weakness captures cases in which a particular code segment is always incorrect with respect to the algorithm that it is implementing. For example, if a C programmer intends to include multiple statements in a single block but does not include the enclosing braces (CWE-483), then the logic is always incorrect. This issue is in contrast to most weaknesses in which the code usually behaves correctly, except when it is externally manipulated in malicious ways.

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

Consequences:
  - Other: Other

Demonstrative examples:
This code queries a server and displays its status when a request comes from an authorized IP address.
This code redirects unauthorized users, but continues to execute code after calling http_redirect(). This means even unauthorized users may be able to access the contents of the page or perform a DoS attack on the server being queried. Also, note that this code is vulnerable to an IP address spoofing attack (CWE-212).
$requestingIP = $_SERVER['REMOTE_ADDR']; if(!in_array($requestingIP,$ipAllowList)){ echo "You are not authorized to view this page"; http_redirect($errorPageURL); } $status = getServerStatus(); echo $status; 
                ...

In this example, the programmer has indented the statements to call Do_X() and Do_Y(), as if the intention is that these functions are only called when the condition is true. However, because there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.
This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.
if (condition==true) Do_X(); Do_Y();

Real-world examples:
  - CVE-2021-3011: virtual interrupt controller in a virtualization product allows crash of host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code
CWE-671: Lack of Administrator Control over Security

Description:
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.

Extended Description:
If the product's administrator does not have the ability to manage security-related decisions at all times, then protecting the product from outside threats - including the product's developer - can become impossible. For example, a hard-coded account name and password cannot be changed by the administrator, thus exposing that product to attacks that the administrator can not prevent.

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

Consequences:
  - Other: Varies by Context

Demonstrative examples:
The following code is an example of an internal hard-coded password in the back-end:
Every instance of this program can be placed into diagnostic mode with the same password. Even worse is the fact that if this program is distributed as a binary-only distribution, it is very difficult to change that password or disable this "functionality."
int VerifyAdmin(char *password) { 
                if (strcmp(password, "Mew!")) { 
                
               printf("Incorrect Password!\n"); return(0) 
                } printf("Entering Diagnostic Mode...\n"); return(1); 
                }
int VerifyAdmin(String password) { if (!password.equals("Mew!")) { return(0) } //Diagnostic Mode return(1); }

Real-world examples:
  - CVE-2022-29953: Condition Monitor firmware has a maintenance interface with hard-coded credentials
  - CVE-2000-0127: GUI configuration tool does not enable a security option when a checkbox is selected, although that option is honored when manually set in the configuration file.
CWE-672: Operation on a Resource after Expiration or Release

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

Affected languages: Not Language-Specific
Affected technologies: Mobile
Parent weaknesses: CWE-666

Consequences:
  - Integrity: Modify Application Data
  - Other: Other

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 shows a simple example of a use after free error:
When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.
char* ptr = (char*)malloc (SIZE); if (err) { abrt = 1; free(ptr); } ... if (abrt) { logError("operation aborted before commit", ptr); }

The following code shows a simple example of a double free error:
Double free vulnerabilities have two common (and sometimes overlapping) causes:
char* ptr = (char*)malloc (SIZE); ... if (abrt) { free(ptr); } ... free(ptr);

Real-world examples:
  - CVE-2009-3547: Chain: race condition (CWE-362) might allow resource to be released before operating on it, leading to NULL dereference (CWE-476)
CWE-673: External Influence of Sphere Definition

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

Extended Description:
Typically, a product defines its control sphere within the code itself, or through configuration by the product's administrator. In some cases, an external party can change the definition of the control sphere. This is typically a resultant weakness.

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

Consequences:
  - Other: Other

Demonstrative examples:
Consider a blog publishing tool, which might have three explicit control spheres: the creation of articles, only accessible to a "publisher;" commenting on articles, only accessible to a "commenter" who is a registered user; and reading articles, only accessible to an anonymous reader. Suppose that the application is deployed on a web server that is shared with untrusted parties. If a local user can modify the data files that define who a publisher is, then this user has modified the control sphere. In this case, the issue would be resultant from another weakness such as insufficient permissions.

In Untrusted Search Path (CWE-426), a user might be able to define the PATH environment variable to cause the product to search in the wrong directory for a library to load. The product's intended sphere of control would include "resources that are only modifiable by the person who installed the product." The PATH effectively changes the definition of this sphere so that it overlaps the attacker's sphere of control.

Real-world examples:
  - CVE-2008-2613: setuid program allows compromise using path that finds and loads a malicious library.
CWE-674: Uncontrolled Recursion

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

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

Consequences:
  - Availability: DoS: Resource Consumption (CPU)
  - 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] Ensure that an end condition will be reached under all logic conditions.  The end condition may include checking against the depth of recursion and exiting with an error if the recursion goes too deep. The complexity of the end condition contributes to the effectiveness of this action.
  - [Implementation] Increase the stack size.

Demonstrative examples:
In this example a mistake exists in the code where the exit condition contained in flg is never called. This results in the function calling itself over and over again until the stack is exhausted.
Note that the only difference between the Good and Bad examples is that the recursion flag will change value and cause the recursive call to return.
void do_something_recursive (int flg) 
	    { 
	     
	      ... // Do some real work here, but the value of flg is unmodified 
	      if (flg) { do_something_recursive (flg); }    // flg is never modified so it is always TRUE - this call will continue until the stack explodes 
	     
	    } 
	    int flag = 1; // Set to TRUE 
	    do_something_recursive (flag);
void do_something_recursive (int flg) 
	    { 
	     
	      ... // Do some real work he

Real-world examples:
  - CVE-2007-1285: Deeply nested arrays trigger stack exhaustion.
  - CVE-2007-3409: Self-referencing pointers create infinite loop and resultant stack exhaustion.
  - CVE-2016-10707: Javascript application accidentally changes input in a way that prevents a recursive call from detecting an exit condition.
  - CVE-2016-3627: An attempt to recover a corrupted XML file infinite recursion protection counter was not always incremented missing the exit condition.
  - CVE-2019-15118: USB-audio driver's descriptor code parsing allows unlimited recursion leading to stack exhaustion.
CWE-675: Multiple Operations on Resource in Single-Operation Context

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

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

Consequences:
  - Other: Other

Demonstrative examples:
The following code shows a simple example of a double free vulnerability.
Double free vulnerabilities have two common (and sometimes overlapping) causes:
char* ptr = (char*)malloc (SIZE); ... if (abrt) { free(ptr); } ... free(ptr);

This code binds a server socket to port 21, allowing the server to listen for traffic on that port.
This code may result in two servers binding a socket to same port, thus receiving each other's traffic. This could be used by an attacker to steal packets meant for another process, such as a secure FTP server.
void bind_socket(void) { 
                
                  int server_sockfd; int server_len; struct sockaddr_in server_address; 
                  
                  /*unlink the socket if already bound to avoid an error when bind() is called*/ 
                  
                  unlink("server_socket"); server_sockfd = socket(AF_INET, SOCK_STREAM, 0); 
                  server_address.sin_family = AF_INET; server_address.sin_port = 21; server_address.sin_addr.s_addr = htonl(INAD

Real-world examples:
  - CVE-2009-0935: Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice
  - CVE-2019-13351: file descriptor double close can cause the wrong file to be associated with a file descriptor.
  - CVE-2004-1939: XSS protection mechanism attempts to remove "/" that could be used to close tags, but it can be bypassed using double encoded slashes (%252F)
CWE-676: Use of Potentially Dangerous Function

Description:
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.

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

Consequences:
  - Other: Varies by Context

Detection methods:
  - Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                           
  - Manual Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Dynamic Analysis with Manual Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                           
  - Manual Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                           

Mitigations:
  - [Build and Compilation] Identify a list of prohibited API functions and prohibit developers from using these functions, providing safer alternatives. In some cases, automatic code analysis tools or the compiler can be instructed to spot use of prohibited functions, such as the "banned.h" include file from Microsoft's SDL. 

Demonstrative examples:
The following code attempts to create a local copy of a buffer to perform some manipulations to the data.
However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter.
void manipulate_string(char * string){ char buf[24]; strcpy(buf, string); ... }

Real-world examples:
  - CVE-2007-1470: Library has multiple buffer overflows using sprintf() and strcpy()
  - CVE-2009-3849: Buffer overflow using strcat()
  - CVE-2006-2114: Buffer overflow using strcpy()
  - CVE-2006-0963: Buffer overflow using strcpy()
  - CVE-2011-0712: Vulnerable use of strcpy() changed to use safer strlcpy()
CWE-680: Integer Overflow to Buffer Overflow

Description:
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.

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

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

Demonstrative examples:
The following image processing code allocates a table for images.
This code intends to allocate a table of size num_imgs, however as num_imgs grows large, the calculation determining the size of the list will eventually overflow (CWE-190). This will result in a very small list to be allocated instead. If the subsequent code operates on the list as if it were num_imgs long, it may result in many types of out-of-bounds problems (CWE-119).
img_t table_ptr; /*struct containing img data, 10kB each*/ int num_imgs; ... num_imgs = get_num_imgs(); table_ptr = (img_t*)malloc(sizeof(img_t)*num_imgs); ...

Real-world examples:
  - CVE-2021-43537: Chain: in a web browser, an unsigned 64-bit integer is forcibly cast to a 32-bit integer (CWE-681) and potentially leading to an integer overflow (CWE-190). If an integer overflow occurs, this can cau
  - CVE-2[PII_REDACTED]: chain: unchecked message size metadata allows integer overflow (CWE-190) leading to buffer overflow (CWE-119).
CWE-681: Incorrect Conversion between Numeric Types

Description:
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.

Affected languages: C, Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-704, CWE-704

Consequences:
  - Other: Unexpected State

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] Avoid making conversion between numeric types. Always check for the allowed ranges.

Demonstrative examples:
In the following Java example, a float literal is cast to an integer, thus causing a loss of precision.

int i = (int) 33457.8f;

This code adds a float and an integer together, casting the result to an integer.
Normally, PHP will preserve the precision of this operation, making $result = 4.8345. After the cast to int, it is reasonable to expect PHP to follow rounding convention and set $result = 5. However, the explicit cast to int always rounds DOWN, so the final value of $result is 4. This behavior may have unintended consequences.
$floatVal = 1.8345; $intVal = 3; $result = (int)$floatVal + $intVal;

Real-world examples:
  - CVE-2022-2639: Chain: integer coercion error (CWE-192) prevents a return value from indicating an error, leading to out-of-bounds write (CWE-787)
  - CVE-2021-43537: Chain: in a web browser, an unsigned 64-bit integer is forcibly cast to a 32-bit integer (CWE-681) and potentially leading to an integer overflow (CWE-190). If an integer overflow occurs, this can cau
  - CVE-2007-4268: Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)
  - CVE-2007-4988: Chain: signed short width value in image processor is sign extended during conversion to unsigned int, which leads to integer overflow and heap-based buffer overflow.
  - CVE-2009-0231: Integer truncation of length value leads to heap-based buffer overflow.
CWE-683: Function Call With Incorrect Order of Arguments

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

Extended Description:
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 or types of arguments, such as format strings in C. It also can occur in languages or environments that do not enforce strong typing.

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

Consequences:
  - Other: Quality Degradation

Detection methods:
  - Automated Analysis: Because this function call often produces
	     incorrect behavior, it will usually be detected during
	     testing or normal operation of the product.
  - Automated Analysis: Exercising all possible control paths will
	     typically expose this weakness, except in rare cases when
	     the incorrect function call accidentally produces the
	     correct results, or if the 

Mitigations:
  - [Implementation] Use the function, procedure, or routine as specified.

Demonstrative examples:
The following PHP method authenticates a user given a username/password combination but is called with the parameters in reverse order.

function authenticate($username, $password) { 
                         
                            
                            // authenticate user 
                            ... 
                      } 
                      authenticate($_POST['password'], $_POST['username']);

Real-world examples:
  - CVE-2006-7049: Application calls functions with arguments in the wrong order, allowing attacker to bypass intended access restrictions.
CWE-684: Incorrect Provision of Specified Functionality

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

Extended Description:
When providing functionality to an external party, it is important that the product behaves in accordance with the details specified. When requirements of nuances are not documented, the functionality may produce unintended behaviors for the caller, possibly leading to an exploitable state.

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

Consequences:
  - Other: Quality Degradation

Mitigations:
  - [Implementation] Ensure that your code strictly conforms to specifications.

Demonstrative examples:
In the following snippet from a doPost() servlet method, the server returns "200 OK" (default) even if an error occurs.

try { 
                         
                            
                            // Something that may throw an exception. 
                            ... 
                      } catch (Throwable t) { logger.error("Caught: " + t.toString()); return; }

In the following example, an HTTP 404 status code is returned in the event of an IOException encountered in a Java servlet. A 404 code is typically meant to indicate a non-existent resource and would be somewhat misleading in this case.

try { 
                         
                            
                            // something that might throw IOException 
                            ... 
                      } catch (IOException ioe) { response.sendError(SC_NOT_FOUND); }

Real-world examples:
  - CVE-2002-1446: Error checking routine in PKCS#11 library returns "OK" status even when invalid signature is detected, allowing spoofed messages.
  - CVE-2001-1559: Chain: System call returns wrong value (CWE-393), leading to a resultant NULL dereference (CWE-476).
  - CVE-2003-0187: Program uses large timeouts on unconfirmed connections resulting from inconsistency in linked lists implementations.
  - CVE-1999-1446: UI inconsistency; visited URLs list not cleared when "Clear History" option is selected.
CWE-685: Function Call With Incorrect Number of Arguments

Description:
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.

Affected languages: C, Perl
Parent weaknesses: CWE-628

Consequences:
  - Other: Quality Degradation

Detection methods:
  - Other: 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 

Mitigations:
  - [Testing] Because this function call often produces incorrect behavior it will usually be detected during testing or normal operation of the product. During testing exercise all possible control paths will typically expose this weakness except in rare cases when the incorrect function call accidentally produc
CWE-686: Function Call With Incorrect Argument Type

Description:
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.

Extended Description:
This weakness is most likely to occur in loosely typed languages, or in strongly typed languages in which the types of variable arguments cannot be enforced at compilation time, or where there is implicit casting.

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

Consequences:
  - Other: Quality Degradation

Detection methods:
  - Other: Because this function call often produces
	     incorrect behavior, it will usually be detected during
	     testing or normal operation of the product.