deardaniel/secdata-raw huggingface dataset:
CWE-346: Origin Validation Error

Description:
The product does not properly verify that the source of data or communication is valid.

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

Consequences:
  - Access Control: 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

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-2000-1218: DNS server can accept DNS updates from hosts that it did not query, leading to cache poisoning
  - CVE-2018-6074: Browser does not set Mark-of-the-Web (MotW) for a downloaded .EXE file if the name is close to the maximum path length, preventing recording of a zone identifier in the filename
  - CVE-2025-0411: Zip file extraction program does not propagate Mark-of-the-Web (MotW) metadata to files that are extracted from an Internet-downloaded Zip file
  - CVE-2025-46652: Zip file extraction program does not propagate Mark-of-the-Web (MotW) metadata to files that are extracted from an Internet-downloaded Zip file
  - CVE-2005-0877: DNS server can accept DNS updates from hosts that it did not query, leading to cache poisoning
CWE-347: Improper Verification of Cryptographic Signature

Description:
The product does not verify, or incorrectly verifies, the cryptographic signature for data.

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

Consequences:
  - Access Control: 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

Demonstrative examples:
In the following code, a JarFile object is created from a downloaded file.
The JAR file that was potentially downloaded from an untrusted source is created without verifying the signature (if present). An alternate constructor that accepts a boolean verify parameter should be used instead.
File f = new File(downloadedFilePath); JarFile jf = new JarFile(f);

Real-world examples:
  - CVE-2002-1796: Does not properly verify signatures for "trusted" entities.
  - CVE-2005-2181: Insufficient verification allows spoofing.
  - CVE-2005-2182: Insufficient verification allows spoofing.
  - CVE-2002-1706: Accepts a configuration file without a Message Integrity Check (MIC) signature.
CWE-348: Use of Less Trusted Source

Description:
The product has two different sources of the same data or information, but it uses the source that has less support for verification, is less trusted, or is less resistant to attack.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Demonstrative examples:
This code attempts to limit the access of a page to certain IP Addresses. It checks the 'HTTP_X_FORWARDED_FOR' header in case an authorized user is sending the request through a proxy.
The 'HTTP_X_FORWARDED_FOR' header can be user controlled and so should never be trusted. An attacker can falsify the header to gain access to the page.
$requestingIP = '0.0.0.0'; if (array_key_exists('HTTP_X_FORWARDED_FOR', $_SERVER)) { $requestingIP = $_SERVER['HTTP_X_FORWARDED_FOR']; 
                      else{ $requestingIP = $_SERVER['REMOTE_ADDR']; } 
                      if(in_array($requestingIP,$ipAllowlist)){ generatePage(); return; } else{ echo "You are not authorized to view this page"; return; }
$requestingIP = '0.0.0.0'; if (array_key_exists('HTTP_X_FORWARDED_FOR', $_SERVER)) { echo "This appl

Real-world examples:
  - CVE-2001-0860: Product uses IP address provided by a client, instead of obtaining it from the packet headers, allowing easier spoofing.
  - CVE-2004-1950: Web product uses the IP address in the X-Forwarded-For HTTP header instead of a server variable that uses the connecting IP address, allowing filter bypass.
  - CVE-2001-0908: Product logs IP address specified by the client instead of obtaining it from the packet headers, allowing information hiding.
  - CVE-2006-1126: PHP application uses IP address from X-Forwarded-For HTTP header, instead of REMOTE_ADDR.
CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data

Description:
The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Real-world examples:
  - CVE-2002-0018: Does not verify that trusted entity is authoritative for all entities in its response.
  - CVE-2006-5462: use of extra data in a signature allows certificate signature forging
CWE-35: Path Traversal: '.../...//'

Description:
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '.../...//' (doubled triple dot slash) sequences that can resolve to a location that is outside of that directory.

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

Consequences:
  - Confidentiality: Read Files or Directories

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] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. 
                   When pe
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Demonstrative examples:
Suppose the product serves files from a specific "public" directory -- /home/product/public/ -- and has an algorithm that attempts to protect against common path traversal attacks. The algorithm works by sequentially scanning through a requested filename and removes each occurrence of "../" that it encounters, then appending the filename to the public directory.
If an attacker provides this filename:
../secret.dat
/home/product/public/secret.dat

Real-world examples:
  - CVE-2005-2169: chain: ".../...//" bypasses protection mechanism using regexp's that remove "../" resulting in collapse into an unsafe value "../" (CWE-182) and resultant path traversal.
  - CVE-2005-0202: ".../....///" bypasses regexp's that remove "./" and "../"
CWE-351: Insufficient Type Distinction

Description:
The product does not properly distinguish between different types of elements in a way that leads to insecure behavior.

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

Consequences:
  - Other: Other

Real-world examples:
  - CVE-2005-2260: Browser user interface does not distinguish between user-initiated and synthetic events.
  - CVE-2005-2801: Product does not compare all required data in two separate elements, causing it to think they are the same, leading to loss of ACLs. Similar to Same Name error.
CWE-353: Missing Support for Integrity Check

Description:
The product uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.

Extended Description:
If integrity check values or "checksums" are omitted from a protocol, there is no way of determining if data has been corrupted in transmission. The lack of checksum functionality in a protocol removes the first application-level check of data that can be used. The end-to-end philosophy of checks states that integrity checks should be performed at the lowest level that they can be completely implemented. Excluding further sanity checks and input validation performed by applications, the protocol's checksum is the most important level of checksum, since it can be performed more completely than at any previous level and takes into account entire messages, as opposed to single packets.

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

Consequences:
  - Integrity: Other
  - Non-Repudiation: Hide Activities

Mitigations:
  - [Architecture and Design] Add an appropriately sized checksum to the protocol, ensuring that data received may be simply validated before it is parsed and used.
  - [Implementation] Ensure that the checksums present in the protocol design are properly implemented and added to each message before it is sent.

Demonstrative examples:
In this example, a request packet is received, and privileged information is sent to the requester:
The response containing secret data has no integrity check associated with it, allowing an attacker to alter the message without detection.
while(true) { DatagramPacket rp = new DatagramPacket(rData,rData.length); outSock.receive(rp); InetAddress IPAddress = rp.getAddress(); int port = rp.getPort(); out = secret.getBytes(); DatagramPacket sp =new DatagramPacket(out, out.length, IPAddress, port); outSock.send(sp); }

Real-world examples:
  - CVE-2025-32890: Mesh device uses a cryptographic algorithm without integrity checking, allowing modification of messages
CWE-354: Improper Validation of Integrity Check Value

Description:
The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.

Extended Description:
Improper validation of checksums before use results in an unnecessary risk that can easily be mitigated. The protocol specification describes the algorithm used for calculating the checksum. It is then a simple matter of implementing the calculation and verifying that the calculated checksum and the received checksum match. Improper verification of the calculated checksum and the received checksum can lead to far greater consequences.

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

Consequences:
  - Integrity: Modify Application Data
  - Integrity: Other
  - Non-Repudiation: Hide Activities

Mitigations:
  - [Implementation] Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.

Demonstrative examples:
The following example demonstrates the weakness.

sd = socket(AF_INET, SOCK_DGRAM, 0); serv.sin_family = AF_INET; serv.sin_addr.s_addr = htonl(INADDR_ANY); servr.sin_port = htons(1008); bind(sd, (struct sockaddr *) & serv, sizeof(serv)); while (1) { 
                         
                            memset(msg, 0x0, MAX_MSG); clilen = sizeof(cli); if (inet_ntoa(cli.sin_addr)==...) n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen); 
                      }
while(true) { DatagramPacket packet = new DatagramPacket(data,data.length,IPAddress, port); socket.send(sendPacket); }

Real-world examples:
  - CVE-2024-47573: network analysis tool does not properly validate an integrity check value, allowing installation of malicious firmware
CWE-356: Product UI does not Warn User of Unsafe Actions

Description:
The product's user interface does not warn the user before undertaking an unsafe action on behalf of that user. This makes it easier for attackers to trick users into inflicting damage to their system.

Extended Description:
Product systems should warn users that a potentially dangerous action may occur if the user proceeds. For example, if the user downloads a file from an unknown source and attempts to execute the file on their machine, then the application's GUI can indicate that the file is unsafe.

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

Consequences:
  - Non-Repudiation: Hide Activities

Real-world examples:
  - CVE-1999-1055: Product does not warn user when document contains certain dangerous functions or macros.
  - CVE-1999-0794: Product does not warn user when document contains certain dangerous functions or macros.
  - CVE-2000-0277: Product does not warn user when document contains certain dangerous functions or macros.
  - CVE-2000-0517: Product does not warn user about a certificate if it has already been accepted for a different site. Possibly resultant.
  - CVE-2005-0602: File extractor does not warn user if setuid/setgid files could be extracted. Overlaps privileges/permissions.
CWE-357: Insufficient UI Warning of Dangerous Operations

Description:
The user interface provides a warning to a user regarding dangerous or sensitive operations, but the warning is not noticeable enough to warrant attention.

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

Consequences:
  - Non-Repudiation: Hide Activities

Real-world examples:
  - CVE-2007-1099: User not sufficiently warned if host key mismatch occurs
CWE-358: Improperly Implemented Security Check for Standard

Description:
The product does not implement or incorrectly implements one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Real-world examples:
  - CVE-2002-0862: Browser does not verify Basic Constraints of a certificate, even though it is required, allowing spoofing of trusted certificates.
  - CVE-2002-0970: Browser does not verify Basic Constraints of a certificate, even though it is required, allowing spoofing of trusted certificates.
  - CVE-2002-1407: Browser does not verify Basic Constraints of a certificate, even though it is required, allowing spoofing of trusted certificates.
  - CVE-2005-0198: Logic error prevents some required conditions from being enforced during Challenge-Response Authentication Mechanism with MD5 (CRAM-MD5).
  - CVE-2004-2163: Shared secret not verified in a RADIUS response packet, allowing authentication bypass by spoofing server replies.
CWE-360: Trust of System Event Data

Description:
Security based on event locations are insecure and can be spoofed.

Extended Description:
Events are a messaging system which may provide control data to programs listening for events. Events often do not have any type of authentication framework to allow them to be verified from a trusted source. Any application, in Windows, on a given desktop can send a message to any window on the same desktop. There is no authentication framework for these messages. Therefore, any message can be used to manipulate any process on the desktop if the process does not check the validity and safeness of those messages.

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

Consequences:
  - Integrity: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Never trust or rely any of the information in an Event for security.

Demonstrative examples:
This example code prints out secret information when an authorized user activates a button:
This code does not attempt to prevent unauthorized users from activating the button. Even if the button is rendered non-functional to unauthorized users in the application UI, an attacker can easily send a false button press event to the application window and expose the secret information.
public void actionPerformed(ActionEvent e) { if (e.getSource() == button) { System.out.println("print out secret information"); } }

Real-world examples:
  - CVE-2004-0213: Attacker uses Shatter attack to bypass GUI-enforced protection for CVE-2003-0908.
CWE-363: Race Condition Enabling Link Following

Description:
The product checks the status of a file or directory before accessing it, which produces a race condition in which the file can be replaced with a link before the access is performed, causing the product to access the wrong file.

Extended Description:
While developers might expect that there is a very narrow time window between the time of check and time of use, there is still a race condition. An attacker could cause the product to slow down (e.g. with memory consumption), causing the time window to become larger. Alternately, in some situations, the attacker could win the race by performing a large number of attacks.

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

Consequences:
  - Confidentiality: Read Files or Directories

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 prints the contents of a file if a user has permission.
This code attempts to resolve symbolic links before checking the file and printing its contents. However, an attacker may be able to change the file from a real file to a symbolic link between the calls to is_link() and file_get_contents(), allowing the reading of arbitrary files. Note that this code fails to log the attempted access (CWE-778).
function readFile($filename){ 
                         $user = getCurrentUser(); 
                            
                            //resolve file if its a symbolic link 
                            if(is_link($filename)){ $filename = readlink($filename); } 
                            if(fileowner($filename) == $user){ echo file_get_contents($realFile); return; } else{ echo '
CWE-366: Race Condition within a Thread

Description:
If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.

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

Consequences:
  - Integrity: Alter Execution Logic

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Architecture and Design] Use locking functionality. This is the recommended solution. Implement some form of locking mechanism around code which alters or reads persistent data in a multithreaded environment.
  - [Architecture and Design] Create resource-locking validation checks. If no inherent locking mechanisms exist, use flags and signals to enforce your own blocking scheme when resources are being used by other threads of execution.

Demonstrative examples:
The following example demonstrates the weakness.

int foo = 0; int storenum(int num) { static int counter = 0; counter++; if (num > foo) foo = num; return foo; }
public classRace { 
                         static int foo = 0; public static void main() { 
                               
                                  new Threader().start(); foo = 1; 
                            } public static class Threader extends Thread { 
                               
                                  public void run() { System.out.println(foo); } 
                            } 
                      }

Real-world examples:
  - CVE-2022-2621: Chain: two threads in a web browser use the same resource (CWE-366), but one of those threads can destroy the resource before the other has completed (CWE-416).
CWE-368: Context Switching Race Condition

Description:
A product performs a series of non-atomic actions to switch between contexts that cross privilege or other security boundaries, but a race condition allows an attacker to modify or misrepresent the product's behavior during the switch.

Extended Description:
This is commonly seen in web browser vulnerabilities in which the attacker can perform certain actions while the browser is transitioning from a trusted to an untrusted domain, or vice versa, and the browser performs the actions on one domain using the trust level and resources of the other domain.

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

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

Real-world examples:
  - CVE-2009-1837: Chain: race condition (CWE-362) from improper handling of a page transition in web client while an applet is loading (CWE-368) leads to use after free (CWE-416)
  - CVE-2004-2260: Browser updates address bar as soon as user clicks on a link instead of when the page has loaded, allowing spoofing by redirecting to another page using onUnload method. ** this is one example of the 
  - CVE-2004-0191: XSS when web browser executes Javascript events in the context of a new page while it's being loaded, allowing interaction with previous page in different domain.
  - CVE-2004-2491: Web browser fills in address bar of clicked-on link before page has been loaded, and doesn't update afterward.