deardaniel/secdata-raw huggingface dataset:
CWE-823: Use of Out-of-range Pointer Offset

Description:
The product performs pointer arithmetic on a valid pointer, but it uses an offset that can point outside of the intended range of valid memory locations for the resulting pointer.

Extended Description:
While a pointer can contain a reference to any arbitrary memory location, a program typically only intends to use the pointer to access limited portions of memory, such as contiguous memory used to access an individual array. 
             Programs may use offsets in order to access fields or sub-elements stored within structured data. The offset might be out-of-range if it comes from an untrusted source, is the result of an incorrect calculation, or occurs because of another error. 
             If an attacker can control or influence the offset so that it points outside of the intended boundaries of the structure, then the attacker may be able to read or write to memory locations that are used elsewhere in the product. As a result, the attack might change the state of the product as accessed through program variables, cause a crash or instable behavior, and possibly lead to code execution.

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

Consequences:
  - Confidentiality: Read Memory
  - Availability: DoS: Crash, Exit, or Restart
  - Integrity: 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
  - 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].

Real-world examples:
  - CVE-2010-2160: Invalid offset in undocumented opcode leads to memory corruption.
  - CVE-2010-1281: Multimedia player uses untrusted value from a file when using file-pointer calculations.
  - CVE-2009-3129: Spreadsheet program processes a record with an invalid size field, which is later used as an offset.
  - CVE-2009-2694: Instant messaging library does not validate an offset value specified in a packet.
  - CVE-2009-2687: Language interpreter does not properly handle invalid offsets in JPEG image, leading to out-of-bounds memory access and crash.
CWE-824: Access of Uninitialized Pointer

Description:
The product accesses or uses a pointer that has not been initialized.

Extended Description:
If the pointer contains an uninitialized value, then the value might not point to a valid memory location. This could cause the product to read from or write to unexpected memory locations, leading to a denial of service. If the uninitialized pointer is used as a function call, then arbitrary functions could be invoked. If an attacker can influence the portion of uninitialized memory that is contained in the pointer, this weakness could be leveraged to execute code or perform other attacks. 
             Depending on memory layout, associated memory management behaviors, and product operation, the attacker might be able to influence the contents of the uninitialized pointer, thus gaining more fine-grained control of the memory location to be accessed.

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

Consequences:
  - Confidentiality: Read Memory
  - Availability: DoS: Crash, Exit, or Restart
  - Integrity: 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
  - 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].

Real-world examples:
  - CVE-2024-32878: LLM product has a free of an uninitialized pointer
  - CVE-2019-3836: Chain: secure communications library does not initialize a local variable for a data structure (CWE-456), leading to access of an uninitialized pointer (CWE-824).
  - CVE-2018-14641: Chain: C union member is not initialized (CWE-456), leading to access of invalid pointer (CWE-824)
  - CVE-2010-0211: chain: unchecked return value (CWE-252) leads to free of invalid, uninitialized pointer (CWE-824).
  - CVE-2009-2768: Pointer in structure is not initialized, leading to NULL pointer dereference (CWE-476) and system crash.
CWE-825: Expired Pointer Dereference

Description:
The product dereferences a pointer that contains a location for memory that was previously valid, but is no longer valid.

Extended Description:
When a product releases memory, but it maintains a pointer to that memory, then the memory might be re-allocated at a later time. If the original pointer is accessed to read or write data, then this could cause the product to read or modify data that is in use by a different function or process. Depending on how the newly-allocated memory is used, this could lead to a denial of service, information exposure, or code execution.

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

Consequences:
  - Confidentiality: Read Memory
  - Availability: DoS: Crash, Exit, or Restart
  - Integrity: 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
  - 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].

Mitigations:
  - [Architecture and Design] Choose a language that provides automatic memory management.
  - [Implementation] When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.

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-2023-26463: Chain: IPSec VPN product uses the same variable for multiple purposes in the same function (CWE-1109), leading to incorrect access control (CWE-284) and expired pointer dereference (CWE-825)
  - CVE-2008-5013: access of expired memory address leads to arbitrary code execution
  - CVE-2010-3257: stale pointer issue leads to denial of service and possibly other consequences
  - CVE-2008-0062: Chain: a message having an unknown message type may cause a reference to uninitialized memory resulting in a null pointer dereference (CWE-476) or dangling pointer (CWE-825), possibly crashing the sys
  - CVE-2007-1211: read of value at an offset into a structure after the offset is no longer valid
CWE-826: Premature Release of Resource During Expected Lifetime

Description:
The product releases a resource that is still intended to be used by itself or another actor.

Extended Description:
This weakness focuses on errors in which the product should not release a resource, but performs the release anyway. This is different than a weakness in which the product releases a resource at the appropriate time, but it maintains a reference to the resource, which it later accesses. For this weakness, the resource should still be valid upon the subsequent access. 
             When a product releases a resource that is still being used, it is possible that operations will still be taken on this resource, which may have been repurposed in the meantime, leading to issues similar to CWE-825. Consequences may include denial of service, information exposure, or code execution.

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

Consequences:
  - Confidentiality: Read Application Data
  - Availability: DoS: Crash, Exit, or Restart
  - Integrity: 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

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-827: Improper Control of Document Type Definition

Description:
The product does not restrict a reference to a Document Type Definition (DTD) to the intended control sphere. This might allow attackers to reference arbitrary DTDs, possibly causing the product to expose files, consume excessive system resources, or execute arbitrary http requests on behalf of the attacker.

Extended Description:
As DTDs are processed, they might try to read or include files on the machine performing the parsing. If an attacker is able to control the DTD, then the attacker might be able to specify sensitive resources or requests or provide malicious content. 
             For example, the SOAP specification prohibits SOAP messages from containing DTDs.

Affected languages: XML
Parent weaknesses: CWE-706, CWE-829

Consequences:
  - Confidentiality: Read Files or Directories
  - Availability: DoS: Resource Consumption (CPU)
  - Integrity: Execute Unauthorized Code or Commands

Real-world examples:
  - CVE-2010-2076: Product does not properly reject DTDs in SOAP messages, which allows remote attackers to read arbitrary files, send HTTP requests to intranet servers, or cause a denial of service.
CWE-83: Improper Neutralization of Script in Attributes in a Web Page

Description:
The product does not neutralize or incorrectly neutralizes "javascript:" or other URIs from dangerous attributes within tags, such as onmouseover, onload, onerror, or style.

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

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] 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.
  - [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-2001-0520: Bypass filtering of SCRIPT tags using onload in BODY, href in A, BUTTON, INPUT, and others.
  - CVE-2002-1493: guestbook XSS in STYLE or IMG SRC attributes.
  - CVE-2002-1965: Javascript in onerror attribute of IMG tag.
  - CVE-2002-1495: XSS in web-based email product via onmouseover event.
  - CVE-2002-1681: XSS via script in <P> tag.
CWE-830: Inclusion of Web Functionality from an Untrusted Source

Description:
The product includes web functionality (such as a web widget) from another domain, which causes it to operate within the domain of the product, potentially granting total access and control of the product to the untrusted source.

Extended Description:
Including third party functionality in a web-based environment is risky, especially if the source of the functionality is untrusted. 
             Even if the third party is a trusted source, the product may still be exposed to attacks and malicious behavior if that trusted source is compromised, or if the code is modified in transmission from the third party to the product. 
             This weakness is common in "mashup" development on the web, which may include source functionality from other domains. For example, Javascript-based web widgets may be inserted by using '<SCRIPT SRC="http://other.domain.here">' tags, which causes the code to run in the domain of the product, not the remote site from which the widget was loaded. As a result, the included code has access to the local DOM, including cookies and other data that the developer might not want the remote site to be able to access. 
             Such dependencies may be desirable, or even required, but sometimes programmers ar

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

Consequences:
  - Confidentiality: Execute Unauthorized Code or Commands

Demonstrative examples:
This login webpage includes a weather widget from an external website:
This webpage is now only as secure as the external domain it is including functionality from. If an attacker compromised the external domain and could add malicious scripts to the weatherwidget.js file, the attacker would have complete control, as seen in any XSS weakness (CWE-79).
<div class="header"> Welcome! <div id="loginBox">Please Login: <form id ="loginForm" name="loginForm" action="login.php" method="post"> Username: <input type="text" name="username" /> <br/> Password: <input type="password" name="password" /> <input type="submit" value="Login" /> </form> </div> <div id="WeatherWidget"> <script type="text/javascript" src="externalDomain.example.com/weatherwidget.js"></script> </div> </div>
...Weather widget cod
CWE-831: Signal Handler Function Associated with Multiple Signals

Description:
The product defines a function that is used as a handler for more than one signal.

Extended Description:
While sometimes intentional and safe, when the same function is used to handle multiple signals, a race condition could occur if the function uses any state outside of its local declaration, such as global variables or non-reentrant functions, or has any side effects. 
             An attacker could send one signal that invokes the handler function; in many OSes, this will typically prevent the same signal from invoking the handler again, at least until the handler function has completed execution. However, the attacker could then send a different signal that is associated with the same handler function. This could interrupt the original handler function while it is still executing. If there is shared state, then the state could be corrupted. This can lead to a variety of potential consequences depending on context, including denial of service and code execution. 
             Another rarely-explored possibility arises when the signal handler is only designed to be executed once (if at

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

Consequences:
  - Availability: DoS: Crash, Exit, or Restart

Demonstrative examples:
This code registers the same signal handler function with two different signals.

void handler (int sigNum) { ... } 
                      int main (int argc, char* argv[]) { signal(SIGUSR1, handler) signal(SIGUSR2, handler) }

This code registers the same signal handler function with two different signals (CWE-831). If those signals are sent to the process, the handler creates a log message (specified in the first argument to the program) and exits.
The handler function uses global state (globalVar and logMessage), and it can be called by both the SIGHUP and SIGTERM signals. An attack scenario might follow these lines:
char *logMessage; 
                      void handler (int sigNum) { 
                         syslog(LOG_NOTICE, "%s\n", logMessage); free(logMessage); 
                            /* artificially increase the size of the timing window to make demonstration of this weakness easier. */ 
                            
                            sleep(10); exit(0); 
                      }
CWE-832: Unlock of a Resource that is not Locked

Description:
The product attempts to unlock a resource that is not locked.

Extended Description:
Depending on the locking functionality, an unlock of a non-locked resource might cause memory corruption or other modification to the resource (or its associated metadata that is used for tracking locks).

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

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

Real-world examples:
  - CVE-2010-4210: function in OS kernel unlocks a mutex that was not previously locked, causing a panic or overwrite of arbitrary memory.
  - CVE-2008-4302: Chain: OS kernel does not properly handle a failure of a function call (CWE-755), leading to an unlock of a resource that was not locked (CWE-832), with resultant crash.
  - CVE-2009-1243: OS kernel performs an unlock in some incorrect circumstances, leading to panic.
CWE-833: Deadlock

Description:
The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-667, CWE-662

Consequences:
  - Availability: DoS: Resource Consumption (CPU)

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

Real-world examples:
  - CVE-1999-1476: A bug in some Intel Pentium processors allow DoS (hang) via an invalid "CMPXCHG8B" instruction, causing a deadlock
  - CVE-2009-2857: OS deadlock
  - CVE-2009-1961: OS deadlock involving 3 separate functions
  - CVE-2009-2699: deadlock in library
  - CVE-2009-4272: deadlock triggered by packets that force collisions in a routing table
CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')

Description:
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.

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

Consequences:
  - Availability: DoS: Resource Consumption (CPU)

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:
In the following code the method processMessagesFromServer attempts to establish a connection to a server and read and process messages from the server. The method uses a do/while loop to continue trying to establish the connection to the server when an attempt fails.
However, this will create an infinite loop if the server does not respond. This infinite loop will consume system resources and can be used to create a denial of service attack. To resolve this a counter should be used to limit the number of attempts to establish a connection to the server, as in the following code.
int processMessagesFromServer(char *hostaddr, int port) { 
                         ... int servsock; int connected; struct sockaddr_in servaddr; 
                            
                            // create

For this example, the method isReorderNeeded is part of a bookstore application that determines if a particular book needs to be reordered based on the current inventory count and the rate at which the book is being sold.
However, the while loop will become an infinite loop if the rateSold input parameter has a value of zero since the inventoryCount will never fall below the minimumCount. In this case the input parameter should be validated to ensure that a value of zero does not cause an infinite loop, as in the following code.
public boolean isReorderNeeded(String bookISBN, int rateSold) { 
                         
                            boolean isReorder = false; 
                            int minimumCount = 10; int days = 0; 
                            
                       

Real-world examples:
  - CVE-2025-32399: Chain: library for implementing Profinet devices does not check an input for a loop condition (CWE-606), allowing an infinite loop (CWE-835) via a crafted RPC packet
  - CVE-2022-22224: Chain: an operating system does not properly process malformed Open Shortest Path First (OSPF) Type/Length/Value Identifiers (TLV) (CWE-703), which can cause the process to enter an infinite loop (CWE
  - CVE-2022-25304: A Python machine communication platform did not account for receiving a malformed packet with a null size, causing the receiving function to never update the message buffer and be caught in an infinit
  - CVE-2011-1027: Chain: off-by-one error (CWE-193) leads to infinite loop (CWE-835) using invalid hex-encoded characters.
  - CVE-2011-1142: Chain: self-referential values in recursive definitions lead to infinite loop.
CWE-836: Use of Password Hash Instead of Password for Authentication

Description:
The product records password hashes in a data store, receives a hash of a password from a client, and compares the supplied hash to the hash obtained from the data store.

Extended Description:
Some authentication mechanisms rely on the client to generate the hash for a password, possibly to reduce load on the server or avoid sending the password across the network. However, when the client is used to generate the hash, an attacker can bypass the authentication by obtaining a copy of the hash, e.g. by using SQL injection to compromise a database of authentication credentials, or by exploiting an information exposure. The attacker could then use a modified client to replay the stolen hash without having knowledge of the original password. 
             As a result, the server-side comparison against a client-side hash does not provide any more security than the use of passwords without hashing.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Real-world examples:
  - CVE-2009-1283: Product performs authentication with user-supplied password hashes that can be obtained from a separate SQL injection vulnerability (CVE-2009-1282).
  - CVE-2005-3435: Product allows attackers to bypass authentication by obtaining the password hash for another user and specifying the hash in the pwd argument.