deardaniel/secdata-raw huggingface dataset:
CWE-257: Storing Passwords in a Recoverable Format

Description:
The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. In fact, it should be noted that recoverable encrypted passwords provide no significant benefit over plaintext passwords since they are subject not only to reuse by malicious attackers but also by malicious insiders. If a system administrator can recover a password directly, or use a brute force search on the available information, the administrator can use the password on other accounts.

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

Consequences:
  - Confidentiality: Gain Privileges or Assume Identity
  - 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

Mitigations:
  - [Architecture and Design] Use strong, non-reversible encryption to protect stored passwords.

Demonstrative examples:
Both of these examples verify a password by comparing it to a stored compressed version.
Because a compression algorithm is used instead of a one way hashing algorithm, an attacker can recover compressed passwords stored in the database.
int VerifyAdmin(char *password) { if (strcmp(compress(password), compressed_password)) { printf("Incorrect Password!\n"); return(0); } printf("Entering Diagnostic Mode...\n"); return(1); }
int VerifyAdmin(String password) { if (passwd.Equals(compress(password), compressed_password)) { return(0); } 
                         //Diagnostic Mode 
                         return(1); }

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-2022-30018: A messaging platform serializes all elements of User/Group objects, making private information available to adversaries
CWE-258: Empty Password in Configuration File

Description:
Using an empty string as a password is insecure.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-260, CWE-521

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [System Configuration] Passwords should be at least eight characters long -- the longer the better. Avoid passwords that are in any way similar to other passwords you have. Avoid using words that may be found in a dictionary, names book, on a map, etc. Consider incorporating numbers and/or punctuation into your password. 

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 the password is provided as an empty string.
This Java example shows a properties file with an empty password string.
# Java Web App ResourceBundle properties file 
                      ... webapp.ldap.username=secretUsername webapp.ldap.password= ...
... <connectionStrings> <add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=; dbalias=uDB;" providerName="System.Data.Odbc" /> </connectionStrings> ...

Real-world examples:
  - CVE-2022-26117: Network access control (NAC) product has a configuration file with an empty password
CWE-26: 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" 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 checks for "../" at the beginning of the input, so a "/../" can bypass that check.

Affected languages: Not Language-Specific
Affected technologies: Web Server
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-2025-25295: Python SDK checks if a URL starts with "/data/upload/" but allows "/data/upload/../../" path traversal sequences that are converted using os.path.join
  - CVE-2023-25802: web interface allows reading arbitrary files via manipulations such as /etc/nginx/../passwd
CWE-260: Password in Configuration File

Description:
The product stores a password in a configuration file that might be accessible to actors who do not know the password.

Extended Description:
This can result in compromise of the system for which the password is used. An attacker could gain access to this file and learn the stored password or worse yet, change the password to one of their choosing.

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

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

Mitigations:
  - [Architecture and Design] Avoid storing passwords in easily accessible locations.
  - [Architecture and Design] Consider storing cryptographic hashes of passwords as an alternative to storing in plaintext.

Demonstrative examples:
Below is a snippet from a Java properties file.
Because the LDAP credentials are stored in plaintext, anyone with access to the file can gain access to the resource.
webapp.ldap.username = secretUsername webapp.ldap.[CREDENTIAL_REDACTED]

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-2022-38665: A continuous delivery pipeline management tool stores an unencypted password in a configuration file.
CWE-261: Weak Encoding for Password

Description:
Obscuring a password with a trivial encoding does not protect the password.

Extended Description:
Password management issues occur when a password is stored in plaintext in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base 64 encoding, but this effort does not adequately protect the password.

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

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

Mitigations:
  - Passwords should be encrypted with keys that are at least 128 bits in length for adequate security.

Demonstrative examples:
The following code reads a password from a properties file and uses the password to connect to a database.
This code will run successfully, but anyone with access to config.properties can read the value of password and easily determine that the value has been base 64 encoded. If a devious employee has access to this information, they can use it to break into the system.
... Properties prop = new Properties(); prop.load(new FileInputStream("config.properties")); String [CREDENTIAL_REDACTED].decode(prop.getProperty("password")); DriverManager.getConnection(url, usr, password); ...

The following code reads a password from the registry and uses the password to create a new network credential.
This code will run successfully, but anyone who has access to the registry key used to store the password can read the value of password. If a devious employee has access to this information, they can use it to break into the system.
... string value = regKey.GetValue(passKey).ToString(); byte[] decVal = Convert.FromBase64String(value); NetworkCredential netCred = newNetworkCredential(username,decVal.toString(),domain); ...

Real-world examples:
  - CVE-2022-45099: network attached storage (NAS) product uses weak encoding for a password
CWE-262: Not Using Password Aging

Description:
The product does not have a mechanism in place for managing password aging.

Extended Description:
Password aging (or password rotation) is a policy that forces users to change their passwords after a defined time period passes, such as every 30 or 90 days. Without mechanisms such as aging, users might not change their passwords in a timely manner. 
	  Note that while password aging was once considered an important security feature, it has since fallen out of favor by many, because it is not as effective against modern threats compared to other mechanisms such as slow hashes. In addition, forcing frequent changes can unintentionally encourage users to select less-secure passwords. However, password aging is still in use due to factors such as compliance requirements, e.g., Payment Card Industry Data Security Standard (PCI DSS).

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

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] As part of a product's design, require users to change their passwords regularly and avoid reusing previous passwords.
  - [Implementation] Developers might disable clipboard paste operations into password fields as a way to discourage users from pasting a password into a clipboard. However, this might encourage users to choose less-secure passwords that are easier to type, and it can reduce the usability of password managers [REF-1294]

Demonstrative examples:
A system does not enforce the changing of passwords every certain period.
CWE-263: Password Aging with Long Expiration

Description:
The product supports password aging, but the expiration period is too long.

Extended Description:
Password aging (or password rotation) is a policy that forces users to change their passwords after a defined time period passes, such as every 30 or 90 days. A long expiration provides more time for attackers to conduct password cracking before users are forced to change to a new password. 
	    Note that while password aging was once considered an important security feature, it has since fallen out of favor by many, because it is not as effective against modern threats compared to other mechanisms such as slow hashes. In addition, forcing frequent changes can unintentionally encourage users to select less-secure passwords. However, password aging is still in use due to factors such as compliance requirements, e.g., Payment Card Industry Data Security Standard (PCI DSS).

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

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Implementation] Previously, "password expiration" was
			   widely advocated as a defense-in-depth approach to
			   minimize the risk of weak passwords, and it has become
			   a common practice.  Password expiration requires a
			   password to be changed within a fixed time window (such
			   as every 90 days). 
  - [Architecture and Design] Ensure that password aging is limited so that there is a defined maximum age for passwords. Note that if the expiration window is too short, it can cause users to generate poor or predictable passwords.
  - [Architecture and Design] Ensure that the user is notified several times leading up to the password expiration.
  - [Architecture and Design] Create mechanisms to prevent users from reusing passwords or creating similar passwords.

Demonstrative examples:
A system requires the changing of passwords every five years.
CWE-266: Incorrect Privilege Assignment

Description:
A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.

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

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  - [Architecture and Design] Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the s

Demonstrative examples:
The following example demonstrates the weakness.

seteuid(0); 
                      /* do some stuff */ 
                      
                      seteuid(getuid());

The following example demonstrates the weakness.

AccessController.doPrivileged(new PrivilegedAction() { 
                         public Object run() { 
                                  // privileged code goes here, for example: 
                                  System.loadLibrary("awt"); return null; 
                                  // nothing to return 
                                  
                            }

Real-world examples:
  - CVE-1999-1193: untrusted user placed in unix "wheel" group
  - CVE-2005-2741: Product allows users to grant themselves certain rights that can be used to escalate privileges.
  - CVE-2005-2496: Product uses group ID of a user instead of the group, causing it to run with different privileges. This is resultant from some other unknown issue.
  - CVE-2004-0274: Product mistakenly assigns a particular status to an entity, leading to increased privileges.
CWE-267: Privilege Defined With Unsafe Actions

Description:
A particular privilege, role, capability, or right can be used to perform unsafe actions that were not intended, even when it is assigned to the correct entity.

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

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  - [Architecture and Design] Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the s

Demonstrative examples:
This code intends to allow only Administrators to print debug information about a system.
While the intention was to only allow Administrators to print the debug information, the code as written only excludes those with the role of "GUEST". Someone with the role of "ADMIN" or "USER" will be allowed access, which goes against the original intent. An attacker may be able to use this debug information to craft an attack on the system.
public enum Roles { ADMIN,USER,GUEST } 
                      public void printDebugInfo(User requestingUser){ 
                         if(isAuthenticated(requestingUser)){ 
                               switch(requestingUser.role){ 
                                     case GUEST: System.out.println("You are not authorized to perform this command"); break; 
 

Real-world examples:
  - CVE-2002-1981: Roles have access to dangerous procedures (Accessible entities).
  - CVE-2002-1671: Untrusted object/method gets access to clipboard (Accessible entities).
  - CVE-2004-2204: Gain privileges using functions/tags that should be restricted (Accessible entities).
  - CVE-2000-0315: Traceroute program allows unprivileged users to modify source address of packet (Accessible entities).
  - CVE-2004-0380: Bypass domain restrictions using a particular file that references unsafe URI schemes (Accessible entities).
CWE-268: Privilege Chaining

Description:
Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination.

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

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
  - [Architecture and Design] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  - [Architecture and Design] Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the s

Demonstrative examples:
This code allows someone with the role of "ADMIN" or "OPERATOR" to reset a user's password. The role of "OPERATOR" is intended to have less privileges than an "ADMIN", but still be able to help users with small issues such as forgotten passwords.
This code does not check the role of the user whose password is being reset. It is possible for an Operator to gain Admin privileges by resetting the password of an Admin account and taking control of that account.
public enum Roles { ADMIN,OPERATOR,USER,GUEST } 
                      public void resetPassword(User requestingUser, User user, String password ){ 
                         if(isAuthenticated(requestingUser)){ 
                               switch(requestingUser.role){ 
                                     case GUEST: System.out.print

Real-world examples:
  - CVE-2005-1736: Chaining of user rights.
  - CVE-2002-1772: Gain certain rights via privilege chaining in alternate channel.
  - CVE-2005-1973: Application is allowed to assign extra permissions to itself.
  - CVE-2003-0640: "operator" user can overwrite usernames and passwords to gain admin privileges.
CWE-269: Improper Privilege Management

Description:
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

Affected languages: Not Language-Specific
Parent weaknesses: 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

Mitigations:
  - [Architecture and Design] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  - [Architecture and Design] Follow the principle of least privilege when assigning access rights to entities in a software system.
  - [Architecture and Design] Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

Demonstrative examples:
This code temporarily raises the program's privileges to allow creation of a new user folder.
While the program only raises its privilege level to create the folder and immediately lowers it again, if the call to os.mkdir() throws an exception, the call to lowerPrivileges() will not occur. As a result, the program is indefinitely operating in a raised privilege state, possibly allowing further exploitation to occur.
def makeNewUserDir(username): 
                         if invalidUsername(username): 
                               
                                  
                                  #avoid CWE-22 and CWE-78 
                                  print('Usernames cannot contain invalid characters') return False 
                            
                            try: rai

The following example demonstrates the weakness.

seteuid(0); 
                      /* do some stuff */ 
                      
                      seteuid(getuid());

Real-world examples:
  - CVE-2001-1555: Terminal privileges are not reset when a user logs out.
  - CVE-2001-1514: Does not properly pass security context to child processes in certain cases, allows privilege escalation.
  - CVE-2001-0128: Does not properly compute roles.
  - CVE-1999-1193: untrusted user placed in unix "wheel" group
  - CVE-2005-2741: Product allows users to grant themselves certain rights that can be used to escalate privileges.