deardaniel/secdata-raw huggingface dataset:
CWE-30: Path Traversal: '\dir\..\filename'

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

Extended Description:
This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. 
             This is similar to CWE-26, except using "\" instead of "/". The '\dir\..\filename' manipulation is useful for bypassing some path traversal protection schemes. Sometimes a program only checks for "..\" at the beginning of the input, so a "\..\" can bypass that check.

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

Real-world examples:
  - CVE-2002-1987: Protection mechanism checks for "/.." but doesn't account for Windows-specific "\.." allowing read of arbitrary files.
CWE-301: Reflection Attack in an Authentication Protocol

Description:
Simple authentication protocols are subject to reflection attacks if a malicious user can use the target machine to impersonate a trusted user.

Extended Description:
A mutual authentication protocol requires each party to respond to a random challenge by the other party by encrypting it with a pre-shared key. Often, however, such protocols employ the same pre-shared key for communication with a number of different entities. A malicious user or an attacker can easily compromise this protocol without possessing the correct key by employing a reflection attack on the protocol. 
             Reflection attacks capitalize on mutual authentication schemes in order to trick the target into revealing the secret shared between it and another valid user. In a basic mutual-authentication scheme, a secret is known to both the valid user and the server; this allows them to authenticate. In order that they may verify this shared secret without sending it plainly over the wire, they utilize a Diffie-Hellman-style scheme in which they each pick a value, then request the hash of that value as keyed by the shared secret. In a reflection attack, the attacker claims t

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

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Use different keys for the initiator and responder or of a different type of challenge for the initiator and responder.
  - [Architecture and Design] Let the initiator prove its identity before proceeding.

Demonstrative examples:
The following example demonstrates the weakness.

unsigned char *simple_digest(char *alg,char *buf,unsigned int len, int *olen) { const EVP_MD *m; EVP_MD_CTX ctx; unsigned char *ret; OpenSSL_add_all_digests(); if (!(m = EVP_get_digestbyname(alg))) return NULL; if (!(ret = (unsigned char*)malloc(EVP_MAX_MD_SIZE))) return NULL; EVP_DigestInit(&ctx, m); EVP_DigestUpdate(&ctx,buf,len); EVP_DigestFinal(&ctx,ret,olen); return ret; } unsigned char *generate_password_and_cmd(char *password_and_cmd) { simple_digest("sha1",password,strlen(password_and_cmd) ... ); }
String command = new String("some cmd to execute & the password") MessageDigest encer = MessageDigest.getInstance("SHA"); encer.update(command.getBytes("UTF-8")); byte[] digest = encer.digest();

Real-world examples:
  - CVE-2024-11022: web server includes the nonce in its challenge/response mechanism, allowing a replay attack
  - CVE-2005-3435: product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.
CWE-302: Authentication Bypass by Assumed-Immutable Data

Description:
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Web Based
Parent weaknesses: CWE-1390, CWE-807

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Implement proper protection for immutable data (e.g. environment variable, hidden form fields, etc.)

Demonstrative examples:
In the following example, an "authenticated" cookie is used to determine whether or not a user should be granted access to a system.
Modifying the value of a cookie on the client-side is trivial, but many developers assume that cookies are essentially immutable.
boolean authenticated = new Boolean(getCookieValue("authenticated")).booleanValue(); if (authenticated) { ... }

Real-world examples:
  - CVE-2002-0367: DebPloit
  - CVE-2004-0261: Web auth
  - CVE-2002-1730: Authentication bypass by setting certain cookies to "true".
  - CVE-2002-1734: Authentication bypass by setting certain cookies to "true".
  - CVE-2002-2064: Admin access by setting a cookie.
CWE-303: Incorrect Implementation of Authentication Algorithm

Description:
The requirements for the product dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect.

Extended Description:
This incorrect implementation may allow authentication to be bypassed.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Real-world examples:
  - CVE-2003-0750: Conditional should have been an 'or' not an 'and'.
CWE-304: Missing Critical Step in Authentication

Description:
The product implements an authentication technique, but it skips a step that weakens the technique.

Extended Description:
Authentication techniques should follow the algorithms that define them exactly, otherwise authentication can be bypassed or more easily subjected to brute force attacks.

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

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

Real-world examples:
  - CVE-2004-2163: Shared secret not verified in a RADIUS response packet, allowing authentication bypass by spoofing server replies.
  - CVE-2005-3327: Chain: Authentication bypass by skipping the first startup step as required by the protocol.
CWE-305: Authentication Bypass by Primary Weakness

Description:
The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Real-world examples:
  - CVE-2002-1374: The provided password is only compared against the first character of the real password.
  - CVE-2000-0979: The password is not properly checked, which allows remote attackers to bypass access controls by sending a 1-byte password that matches the first character of the real password.
  - CVE-2001-0088: Chain: Forum software does not properly initialize an array, which inadvertently sets the password to a single character, allowing remote attackers to easily guess the password and gain administrative
CWE-308: Use of Single-factor Authentication

Description:
The product uses an authentication algorithm that uses a single factor (e.g., a password) in a security context that should require more than one factor.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Use multiple independent authentication schemes, which ensures that -- if one of the methods is compromised -- the system itself is still likely safe from compromise. For this reason, if multiple schemes are possible, they should be implemented and required -- especially if they are easy to use.

Demonstrative examples:
In both of these examples, a user is logged in if their given password matches a stored password:
This code relies exclusively on a password mechanism (CWE-309) using only one factor of authentication (CWE-308). If an attacker can steal or guess a user's password, they are given full access to their account. Note this code also uses SHA-1, which is a weak hash (CWE-328).  It also does not use a salt (CWE-759).
unsigned char *check_passwd(char *plaintext) { ctext = simple_digest("sha1",plaintext,strlen(plaintext), ... ); 
                         //Login if hash matches stored hash 
                         if (equal(ctext, secret_password())) { login_user(); } }
String plainText = new String(plainTextIn); MessageDigest encer = MessageDigest.getInstance("SHA"); encer.update(plainTextIn); by

Real-world examples:
  - CVE-2022-35248: Chat application skips validation when Central Authentication Service
			 (CAS) is enabled, effectively removing the second factor from
			 two-factor authentication
CWE-309: Use of Password System for Primary Authentication

Description:
The use of password systems as the primary means of authentication may be subject to several flaws or shortcomings, each reducing the effectiveness of the mechanism.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] In order to protect password systems from compromise, the following should be noted: 
                      
                         Passwords should be stored safely to prevent insider attack and to ensure that -- if a system is compromised -- the passwords are not retrievable. Due to password reu
  - [Architecture and Design] Use a zero-knowledge password protocol, such as SRP.
  - [Architecture and Design] Ensure that passwords are stored safely and are not reversible.
  - [Architecture and Design] Implement password aging functionality that requires passwords be changed after a certain point.

Demonstrative examples:
In both of these examples, a user is logged in if their given password matches a stored password:
This code relies exclusively on a password mechanism (CWE-309) using only one factor of authentication (CWE-308). If an attacker can steal or guess a user's password, they are given full access to their account. Note this code also uses SHA-1, which is a weak hash (CWE-328).  It also does not use a salt (CWE-759).
unsigned char *check_passwd(char *plaintext) { ctext = simple_digest("sha1",plaintext,strlen(plaintext), ... ); 
                         //Login if hash matches stored hash 
                         if (equal(ctext, secret_password())) { login_user(); } }
String plainText = new String(plainTextIn); MessageDigest encer = MessageDigest.getInstance("SHA"); encer.update(plainTextIn); by
CWE-31: Path Traversal: 'dir\..\..\filename'

Description:
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize 'dir\..\..\filename' (multiple internal backslash dot dot) sequences that can resolve to a location that is outside of that directory.

Extended Description:
This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. 
             The 'dir\..\..\filename' manipulation is useful for bypassing some path traversal protection schemes. Sometimes a program only removes one "..\" sequence, so multiple "..\" can bypass that check. Alternately, this manipulation could be used to bypass a check for "..\" at the beginning of the pathname, moving up more than one directory level.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-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

Real-world examples:
  - CVE-2002-0160: The administration function in Access Control Server allows remote attackers to read HTML, Java class, and image files outside the web root via a "..\.." sequence in the URL to port 2002.
CWE-312: Cleartext Storage of Sensitive Information

Description:
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

Affected languages: Not Language-Specific
Affected technologies: Cloud Computing, ICS/OT, Mobile
Parent weaknesses: CWE-311, CWE-311, CWE-922

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] When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]
  - [Implementation] In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.

Demonstrative examples:
The following code excerpt stores a plaintext user account ID in a browser cookie.
Because the account ID is in plaintext, the user's account information is exposed if their computer is compromised by an attacker.
response.addCookie( new Cookie("userAccountID", acctID);

This code writes a user's login information to a cookie so the user does not have to login again later.
The code stores the user's username and password in plaintext in a cookie on the user's machine. This exposes the user's login information if their computer is compromised by an attacker. Even if the user's machine is not compromised, this weakness combined with cross-site scripting (CWE-79) could allow an attacker to remotely copy the cookie.
function persistLogin($username, $password){ $data = array("username" => $username, "password"=> $password); setcookie ("userdata", $data); }

Real-world examples:
  - CVE-2022-26390: wireless battery product stores credentials and Personal Health Information (PHI) without encryption
  - CVE-2022-30275: Remote Terminal Unit (RTU) uses a driver that relies on a password stored in plaintext.
  - CVE-2009-2272: password and username stored in cleartext in a cookie
  - CVE-2009-1466: password stored in cleartext in a file with insecure permissions
  - CVE-2009-0152: chat program disables SSL in some circumstances even when the user says to use SSL.
CWE-313: Cleartext Storage in a File or on Disk

Description:
The product stores sensitive information in cleartext in a file, or on disk.

Extended Description:
The sensitive information could be read by attackers with access to the file, or with physical or administrator access to the raw disk. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

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

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

Demonstrative examples:
The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in cleartext.
This Java example shows a properties file with a cleartext username / password pair.
# Java Web App ResourceBundle properties file 
                      ... webapp.ldap.username=secretUsername webapp.ldap.[CREDENTIAL_REDACTED] ...
... <connectionStrings> <add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; [CREDENTIAL_REDACTED]; dbalias=uDB;" providerName="System.Data.Odbc" /> </connectionStrings> ...

Real-world examples:
  - CVE-2001-1481: Cleartext credentials in world-readable file.
  - CVE-2005-1828: Password in cleartext in config file.
  - CVE-2005-2209: Password in cleartext in config file.
  - CVE-2002-1696: Decrypted copy of a message written to disk given a combination of options and when user replies to an encrypted message.
  - CVE-2004-2397: Cleartext storage of private key and passphrase in log file when user imports the key.
CWE-314: Cleartext Storage in the Registry

Description:
The product stores sensitive information in cleartext in the registry.

Extended Description:
Attackers can read the information by accessing the registry key. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

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

Consequences:
  - Confidentiality: Read Application Data

Real-world examples:
  - CVE-2005-2227: Cleartext passwords in registry key.
CWE-315: Cleartext Storage of Sensitive Information in a Cookie

Description:
The product stores sensitive information in cleartext in a cookie.

Extended Description:
Attackers can use widely-available tools to view the cookie and read the sensitive information. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

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

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

Demonstrative examples:
The following code excerpt stores a plaintext user account ID in a browser cookie.
Because the account ID is in plaintext, the user's account information is exposed if their computer is compromised by an attacker.
response.addCookie( new Cookie("userAccountID", acctID) );

Real-world examples:
  - CVE-2002-1800: Admin password in cleartext in a cookie.
  - CVE-2001-1537: Default configuration has cleartext usernames/passwords in cookie.
  - CVE-2001-1536: Usernames/passwords in cleartext in cookies.
  - CVE-2005-2160: Authentication information stored in cleartext in a cookie.
CWE-316: Cleartext Storage of Sensitive Information in Memory

Description:
The product stores sensitive information in cleartext in memory.

Extended Description:
The sensitive memory might be saved to disk, stored in a core dump, or remain uncleared if the product crashes, or if the programmer does not properly clear the memory before freeing it. 
             It could be argued that such problems are usually only exploitable by those with administrator privileges. However, swapping could cause the memory to be written to disk and leave it accessible to physical attack afterwards. Core dump files might have insecure permissions or be stored in archive files that are accessible to untrusted people. Or, uncleared sensitive memory might be inadvertently exposed to attackers due to another weakness.

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

Consequences:
  - Confidentiality: Read Memory

Real-world examples:
  - CVE-2025-24870: GUI for a desktop client stores credentials in program memory, allowing privilege escalation
  - CVE-2001-1517: Sensitive authentication information in cleartext in memory.
  - CVE-2001-0984: Password protector leaves passwords in memory when window is minimized, even when "clear password when minimized" is set.
  - CVE-2003-0291: SSH client does not clear credentials from memory.
CWE-317: Cleartext Storage of Sensitive Information in GUI

Description:
The product stores sensitive information in cleartext within the GUI.

Extended Description:
An attacker can often obtain data from a GUI, even if hidden, by using an API to directly access GUI objects such as windows and menus. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

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

Consequences:
  - Confidentiality: Read Memory

Real-world examples:
  - CVE-2002-1848: Unencrypted passwords stored in GUI dialog may allow local users to access the passwords.
CWE-318: Cleartext Storage of Sensitive Information in Executable

Description:
The product stores sensitive information in cleartext in an executable.

Extended Description:
Attackers can reverse engineer binary code to obtain secret data. This is especially easy when the cleartext is plain ASCII. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

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

Consequences:
  - Confidentiality: Read Application Data

Real-world examples:
  - CVE-2005-1794: Product stores RSA private key in a DLL and uses it to sign a certificate, allowing spoofing of servers and Adversary-in-the-Middle (AITM) attacks.
  - CVE-2001-1527: administration passwords in cleartext in executable