deardaniel/secdata-raw huggingface dataset:
CWE-1335: Incorrect Bitwise Shift of Integer

Description:
An integer value is specified to be shifted by a negative amount or an amount greater than or equal to the number of bits contained in the value causing an unexpected or indeterminate result.

Extended Description:
Specifying a value to be shifted by a negative amount is undefined in various languages. Various computer architectures implement this action in different ways. The compilers and interpreters when generating code to accomplish a shift generally do not do a check for this issue. 
				 Specifying an over-shift, a shift greater than or equal to the number of bits contained in a value to be shifted, produces a result which varies by architecture and compiler. In some languages, this action is specifically listed as producing an undefined result.

Affected languages: C, C++, C#, Java, JavaScript
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-682

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

Mitigations:
  - [Implementation] Implicitly or explicitly add checks and mitigation for negative or over-shift values.

Demonstrative examples:
A negative shift amount for an x86 or x86_64 shift instruction will produce the number of bits to be shifted by taking a 2's-complement of the shift amount and effectively masking that amount to the lowest 6 bits for a 64 bit shift instruction.
The example above ends up with a shift amount of -5. The hexadecimal value is FFFFFFFFFFFFFFFD which, when bits above the  6th bit are masked off, the shift amount becomes a binary shift value of 111101 which is 61 decimal. A shift of 61 produces a very different result than -5. The previous example is a very simple version of the following code which is probably more realistic of what happens in a real system.
unsigned int r = 1 << -5;
int choose_bit(int reg_bit, int bit_number_from_elsewhere)  
					  { 
					   
					    if (NEED_TO_SHIFT) 
					

Real-world examples:
  - CVE-2023-4720: multimedia product performs a left shift with a negative value, leading to a crash
  - CVE-2009-4307: An unexpected large value in the ext4 filesystem causes an overshift condition resulting in a divide by zero.
  - CVE-2012-2100: An unexpected large value in the ext4 filesystem causes an overshift condition resulting in a divide by zero - fix of CVE-2009-4307.
  - CVE-2020-8835: An overshift in a kernel allowed out of bounds reads and writes resulting in a root takeover.
  - CVE-2015-1607: Program is not properly handling signed bitwise left-shifts causing an overlapping memcpy memory range error.
CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine

Description:
The product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine.

Extended Description:
Many web applications use template engines that allow developers to insert externally-influenced values into free text or messages in order to generate a full web page, document, message, etc. Such engines include Twig, Jinja2, Pug, Java Server Pages, FreeMarker, Velocity, ColdFusion, Smarty, and many others - including PHP itself. Some CMS (Content Management Systems) also use templates. 
				 Template engines often have their own custom command or expression language. If an attacker can influence input into a template before it is processed, then the attacker can invoke arbitrary expressions, i.e. perform injection attacks. For example, in some template languages, an attacker could inject the expression "{{7*7}}" and determine if the output returns "49" instead. The syntax varies depending on the language. 
				 In some cases, XSS-style attacks can work, which can obscure the root cause if the developer does not closely investigate the root cause of the error. 
				 Template engines 

Affected languages: Java, PHP, Python, JavaScript, Interpreted
Affected technologies: Not Technology-Specific, AI/ML, Client Server
Parent weaknesses: CWE-94

Consequences:
  - 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] Choose a template engine that offers a sandbox or restricted mode, or at least limits the power of any available expressions, function calls, or commands.
  - [Implementation] Use the template engine's sandbox or restricted mode, if available.

Real-world examples:
  - CVE-2024-34359: Chain: Python bindings for LLM
					library do not use a sandboxed environment when
					parsing a template and constructing a prompt,
					allowing jinja2 Server Side Template Injection and
					code
  - CVE-2017-16783: server-side template injection in content management server
  - CVE-2020-9437: authentication / identity management product has client-side template injection
  - CVE-2020-12790: Server-Side Template Injection using a Twig template
  - CVE-2021-21244: devops platform allows SSTI
CWE-1338: Improper Protections Against Hardware Overheating

Description:
A hardware device is missing or has inadequate protection features to prevent overheating.

Extended Description:
Hardware, electrical circuits, and semiconductor silicon have thermal side effects, such that some of the energy consumed by the device gets dissipated as heat and increases the temperature of the device. For example, in semiconductors, higher-operating frequency of silicon results in higher power dissipation and heat. The leakage current in CMOS circuits increases with temperature, and this creates positive feedback that can result in thermal runaway and damage the device permanently. 
				 Any device lacking protections such as thermal sensors, adequate platform cooling, or thermal insulation is susceptible to attacks by malicious software that might deliberately operate the device in modes that result in overheating. This can be used as an effective denial of service (DoS) or permanent denial of service (PDoS) attack. 
				 Depending on the type of hardware device and its expected usage, such thermal overheating can also cause safety hazards and reliability issues. Note that battery

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, ICS/OT, Power Management Hardware, Processor Hardware
Parent weaknesses: CWE-693

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

Detection methods:
  - Dynamic Analysis with Manual Results Interpretation: Dynamic tests should be performed to stress-test temperature controls.
  - Architecture or Design Review: Power management controls should be part of Architecture and Design reviews.

Mitigations:
  - [Architecture and Design] Temperature maximum and minimum limits should be enforced using thermal sensors both in silicon and at the platform level.
  - [Implementation] The platform should support cooling solutions such as fans that can be modulated based on device-operation needs to maintain a stable temperature.

Demonstrative examples:
Malicious software running on a core can execute instructions that consume maximum power or increase core frequency. Such a power-virus program could execute on the platform for an extended time to overheat the device, resulting in permanent damage.
Execution core and platform do not support thermal sensors, performance throttling, or platform-cooling countermeasures to ensure that any software executing on the system cannot cause overheating past the maximum allowable temperature.
CWE-1342: Information Exposure through Microarchitectural State after Transient Execution

Description:
The processor does not properly clear microarchitectural state after incorrect microcode assists or speculative execution, resulting in transient execution.

Extended Description:
In many processor architectures an exception, mis-speculation, or microcode assist results in a flush operation to clear results that are no longer required. This action prevents these results from influencing architectural state that is intended to be visible from software. However, traces of this transient execution may remain in microarchitectural buffers, resulting in a change in microarchitectural state that can expose sensitive information to an attacker using side-channel analysis. For example, Load Value Injection (LVI) [REF-1202] can exploit direct injection of erroneous values into intermediate load and store buffers. 
				 Several conditions may need to be fulfilled for a successful attack: 
			     
				 incorrect transient execution that results in remanence of sensitive information; 
				 attacker has the ability to provoke microarchitectural exceptions; 
				 operations and structures in victim code that can be exploited must be identified.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, System on Chip
Parent weaknesses: CWE-226, CWE-226

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Architecture and Design] Hardware ensures that no illegal data flows from faulting micro-ops exists at the microarchitectural level.
  - [Build and Compilation] Include instructions that explicitly remove traces of unneeded computations from software interactions with microarchitectural elements e.g. lfence, sfence, mfence, clflush.

Demonstrative examples:
Faulting loads in a victim domain may trigger incorrect transient forwarding, which leaves secret-dependent traces in the microarchitectural state. Consider this example from [REF-1203].
Consider the code gadget:
void call_victim(size_t untrusted_arg) { 
					     
					      *arg_copy = untrusted_arg; 
					      array[**trusted_ptr * 4096]; 
					     
					    }

Real-world examples:
  - CVE-2020-0551: Load value injection in some processors utilizing speculative execution may allow an authenticated user to enable information disclosure via a side-channel with local access.
CWE-135: Incorrect Calculation of Multi-Byte String Length

Description:
The product does not correctly calculate the length of strings that can contain wide or multi-byte characters.

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

Consequences:
  - Integrity: Execute Unauthorized Code or Commands
  - Availability: Read Memory
  - 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:
  - [Implementation] Always verify the length of the string unit character.
  - [Implementation] Use length computing functions (e.g. strlen, wcslen, etc.) appropriately with their equivalent type (e.g.: byte, wchar_t, etc.)

Demonstrative examples:
The following example would be exploitable if any of the commented incorrect malloc calls were used.
The output from the printf() statement would be:
#include <stdio.h> #include <strings.h> #include <wchar.h> 
                      int main() { 
                         
                            wchar_t wideString[] = L"The spazzy orange tiger jumped " \ "over the tawny jaguar."; wchar_t *newString; 
                            printf("Strlen() output: %d\nWcslen() output: %d\n", strlen(wideString), wcslen(wideString)); 
                            /* Wrong because the number of chars in a string isn't related to its length in bytes // newString = (wchar_t *) malloc(strlen(wideString)); */ 
                            /* Wrong because wide characters aren't 1 byte long! // newString = (
CWE-1351: Improper Handling of Hardware Behavior in Exceptionally Cold Environments

Description:
A hardware device, or the firmware running on it, is
                missing or has incorrect protection features to maintain
                goals of security primitives when the device is cooled below
                standard operating temperatures.

Extended Description:
The hardware designer may improperly anticipate
                    hardware behavior when exposed to exceptionally cold
                    conditions. As a result they may introduce a weakness by not
                    accounting for the modified behavior of critical components
                    when in extreme environments. 
                 An example of a change in behavior is that power loss
                    won't clear/reset any volatile state when cooled below
                    standard operating temperatures. This may result in
                    a weakness when the starting state of the volatile memory is
                    being relied upon for a security decision. For example, a
                    Physical Unclonable Function (PUF) may be supplied as a
                    security primitive to improve confidentiality,
                    authenticity, and integrity guarantees. However, when the
                    PUF is paired with DRAM, SRAM, or another tempera

Affected languages: Not Language-Specific
Affected technologies: System on Chip
Parent weaknesses: CWE-1384

Consequences:
  - Integrity: Varies by Context

Mitigations:
  - [Architecture and Design] The system should account for security primitive behavior when cooled outside standard temperatures.
CWE-1385: Missing Origin Validation in WebSockets

Description:
The product uses a WebSocket, but it does not properly verify that the source of data or communication is valid.

Extended Description:
WebSockets provide a bi-directional low latency communication (near real-time) between a client and a server. WebSockets are different than HTTP in that the connections are long-lived, as the channel will remain open until the client or the server is ready to send the message, whereas in HTTP, once the response occurs (which typically happens immediately), the transaction completes.  
	 A WebSocket can leverage the existing HTTP protocol over ports 80 and 443, but it is not limited to HTTP. WebSockets can make cross-origin requests that are not restricted by browser-based protection mechanisms such as the Same Origin Policy (SOP) or Cross-Origin Resource Sharing (CORS). Without explicit origin validation, this makes CSRF attacks more powerful.

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

Consequences:
  - Confidentiality: Varies by Context

Mitigations:
  - [Implementation] Enable CORS-like access restrictions by verifying the 'Origin' header during the WebSocket handshake.
  - [Implementation] Use a randomized CSRF token to verify requests.
  - [Implementation] Use TLS to securely communicate using 'wss' (WebSocket Secure) instead of 'ws'.
  - [Architecture and Design] Require user authentication prior to the WebSocket connection being established. For example, the WS library in Node has a 'verifyClient' function.

Real-world examples:
  - CVE-2020-25095: web console for SIEM product does not check Origin header, allowing Cross Site WebSocket Hijacking (CSWH)
  - CVE-2018-6651: Chain: gaming client attempts to validate the Origin header, but only uses a substring, allowing Cross-Site WebSocket hijacking by forcing requests from an origin whose hostname is a substring of the 
  - CVE-2018-14730: WebSocket server does not check the origin of requests, allowing attackers to steal developer's code using a ws://127.0.0.1:3123/ connection.
  - CVE-2018-14731: WebSocket server does not check the origin of requests, allowing attackers to steal developer's code using a ws://127.0.0.1/ connection to a randomized port number.
  - CVE-2018-14732: WebSocket server does not check the origin of requests, allowing attackers to steal developer's code using a ws://127.0.0.1:8080/ connection.
CWE-1386: Insecure Operation on Windows Junction / Mount Point

Description:
The product opens a file or directory, but it does not properly prevent the name from being associated with a junction or mount point to a destination that is outside of the intended control sphere.

Extended Description:
Depending on the intended action
			  being performed, this could allow an
			  attacker to cause the product to read,
			  write, delete, or otherwise operate on
			  unauthorized files. 
			   In Windows, NTFS5 allows for file
			  system objects called reparse points.
			  Applications can create a hard link from one
			  directory to another directory, called a
			  junction point. They can also create a
			  mapping from a directory to a drive letter,
			  called a mount point. If a file is used by a
			  privileged program, but it can be replaced
			  with a hard link to a sensitive file (e.g.,
			  AUTOEXEC.BAT), an attacker could escalate
			  privileges. When the process opens the file,
			  the attacker can assume the privileges of
			  that process, tricking the privileged
			  process to read, modify, or delete the
			  sensitive file, preventing the program from
			  accurately processing data. Note that one
			  can also point to registries and
			  semaphores.

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

Consequences:
  - Confidentiality: Read Files or Directories
  - Integrity: Modify Files or Directories
  - Availability: Modify Files or Directories

Mitigations:
  - [Architecture and Design] When designing software that will have different rights than the executer, the software should check that files that it is interacting with are not improper hard links or mount points.  One way to do this in Windows is to use the functionality embedded in the following command: "dir /al /s /b" or, i

Real-world examples:
  - CVE-2021-26426: Privileged service allows attackers to delete unauthorized files using a directory junction, leading to arbitrary code execution as SYSTEM.
  - CVE-2020-0863: By creating a mount point and hard links, an attacker can abuse a service to allow users arbitrary file read permissions.
  - CVE-2019-1161: Chain: race condition (CWE-362) in anti-malware product allows deletion of files by creating a junction (CWE-1386) and using hard links during the time window in which a temporary file is created and 
  - CVE-2014-0568: Escape from sandbox for document reader by using a mountpoint [REF-1264]
CWE-1390: Weak Authentication

Description:
The product uses an authentication mechanism to restrict access to specific users or identities, but the mechanism does not sufficiently prove that the claimed identity is correct.

Extended Description:
Attackers may be able to bypass weak authentication faster and/or with less effort than expected.

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

Consequences:
  - Integrity: Read Application Data

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.
Multiple OT products used weak authentication.

Real-world examples:
  - CVE-2024-48445: Chain: e-commerce app relies on an easily-guessable timestamp (CWE-341) in a weak authentication algorithm (CWE-1390)
  - CVE-2022-30034: Chain: Web UI for a Python RPC framework does not use regex anchors to validate user login emails (CWE-777), potentially allowing bypass of OAuth (CWE-1390).
  - CVE-2022-35248: Chat application skips validation when Central Authentication Service
		  (CAS) is enabled, effectively removing the second factor from
		  two-factor authentication
  - CVE-2021-3116: Chain: Python-based HTTP Proxy server uses the wrong boolean operators (CWE-480) causing an  incorrect comparison (CWE-697) that identifies an authN failure if all three conditions are met instead of 
  - CVE-2022-29965: Distributed Control System (DCS) uses a deterministic algorithm to generate utility passwords
CWE-1391: Use of Weak Credentials

Description:
The product uses weak credentials (such as a default key or hard-coded password) that can be calculated, derived, reused, or guessed by an attacker.

Extended Description:
By design, authentication protocols try to ensure that attackers must perform brute force attacks if they do not know the credentials such as a key or password. However, when these credentials are easily predictable or even fixed (as with default or hard-coded passwords and keys), then the attacker can defeat the mechanism without relying on brute force. 
	 Credentials may be weak for different reasons, such as: 
	 
	   Hard-coded (i.e., static and unchangeable by the administrator) 
	   Default (i.e., the same static value across different deployments/installations, but able to be changed by the administrator) 
	   Predictable (i.e., generated in a way that produces unique credentials across deployments/installations, but can still be guessed with reasonable efficiency) 
	   Previously Compromised (i.e., "leaked" credentials that were published as part of a data breach) 
	 
	 Even if a new, unique credential is intended to be generated for each product installation, if the generation 

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] When the user changes or sets a password, check
	  the password against a database of already compromised or
	  breached passwords. These passwords are likely to be used in
	  password guessing attacks.

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.
Multiple OT products used weak credentials.

Real-world examples:
  - [REF-1374]: Chain: JavaScript-based cryptocurrency library can fall back to the insecure Math.random() function instead of reporting a failure (CWE-392), thus reducing the entropy (CWE-332) and leading to generat
  - CVE-2022-30270: Remote Terminal Unit (RTU) uses default credentials for some SSH accounts
  - CVE-2022-29965: Distributed Control System (DCS) uses a deterministic algorithm to generate utility passwords
  - CVE-2022-30271: Remote Terminal Unit (RTU) uses a hard-coded SSH private key that is likely to be used in typical deployments
  - CVE-2021-38759: microcontroller board has default password, allowing admin access