deardaniel/secdata-raw huggingface dataset:
CWE-547: Use of Hard-coded, Security-relevant Constants

Description:
The product uses hard-coded constants instead of symbolic names for security-critical values, which increases the likelihood of mistakes during code maintenance or security policy change.

Extended Description:
If the developer does not find all occurrences of the hard-coded constants, an incorrect policy decision may be made if one of the constants is not changed. Making changes to these values will require code changes that may be difficult or impossible once the system is released to the field. In addition, these hard-coded values may become available to attackers if the code is ever disclosed.

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

Consequences:
  - Other: Varies by Context

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

Mitigations:
  - [Implementation] Avoid using hard-coded constants. Configuration files offer a more flexible solution.

Demonstrative examples:
The usage of symbolic names instead of hard-coded constants is preferred.
The following is an example of using a hard-coded constant instead of a symbolic name.
char buffer[1024]; ... fgets(buffer, 1024, stdin);
enum { MAX_BUFFER_SIZE = 1024 }; ... char buffer[MAX_BUFFER_SIZE]; ... fgets(buffer, MAX_BUFFER_SIZE, stdin);
CWE-548: Exposure of Information Through Directory Listing

Description:
The product inappropriately exposes a directory listing with an index of all the resources located inside of the directory.

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

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:
  - [Architecture and Design] Recommendations include restricting access to important directories or files by adopting a need to know requirement for both the document and server root, and turning off features such as Automatic Directory Listings that could expose private files and provide information that could be utilized by a

Real-world examples:
  - CVE-2023-37599: web interface is configured to allow directory listing of a module path
CWE-549: Missing Password Field Masking

Description:
The product does not mask passwords during entry, increasing the potential for attackers to observe and capture passwords.

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

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

Mitigations:
  - [Implementation] Recommendations include requiring all password fields in your web application be masked to prevent other users from seeing this information.

Real-world examples:
  - CVE-2025-0148: Jenkins plugin for a video meeting product does not mask passwords
CWE-55: Path Equivalence: '/./' (Single Dot Directory)

Description:
The product accepts path input in the form of single dot directory exploit ('/./') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.

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

Consequences:
  - Confidentiality: Read Files or Directories

Mitigations:
  - [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-2024-6091: Chain: AI agent platform does not restrict pathnames containing internal "/./" sequences (CWE-55), leading to an incomplete denylist (CWE-184) that does not prevent OS command injection (CWE-78)
  - CVE-2000-0004: Server allows remote attackers to read source code for executable files by inserting a . (dot) into the URL.
  - CVE-2002-0304: Server allows remote attackers to read password-protected files via a /./ in the HTTP request.
  - CVE-1999-1083: Possibly (could be a cleansing error)
  - CVE-2004-0815: "/./////etc" cleansed to ".///etc" then "/etc"
CWE-550: Server-generated Error Message Containing Sensitive Information

Description:
Certain conditions, such as network failure, will cause a server error message to be displayed.

Extended Description:
While error messages in and of themselves are not dangerous, per se, it is what an attacker can glean from them that might cause eventual problems.

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

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Architecture and Design] Recommendations include designing and adding consistent error handling mechanisms which are capable of handling any user input to your web application, providing meaningful detail to end-users, and preventing error messages that might provide information useful to an attacker from being displayed.
CWE-551: Incorrect Behavior Order: Authorization Before Parsing and Canonicalization

Description:
If a web server does not fully parse requested URLs before it examines them for authorization, it may be possible for an attacker to bypass authorization protection.

Extended Description:
For instance, the character strings /./ and / both mean current directory. If /SomeDirectory is a protected directory and an attacker requests /./SomeDirectory, the attacker may be able to gain access to the resource if /./ is not converted to / before the authorization check is performed.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Web Based, Web Server
Parent weaknesses: CWE-863, CWE-696

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] URL Inputs should be decoded and canonicalized to the application's current internal representation before being validated and processed for authorization. Make sure that your application does not decode the same input twice. Such errors could be used to bypass allowlist schemes by introducing dange
CWE-552: Files or Directories Accessible to External Parties

Description:
The product makes files or directories accessible to unauthorized actors, even though they should not be.

Extended Description:
Web servers, FTP servers, and similar servers may store a set of files underneath a "root" directory that is accessible to the server's users.  Applications may store sensitive files underneath this root without also using access control to limit which users may request those files, if any.  Alternately, an application might package multiple files or directories into an archive file (e.g., ZIP or tar), but the application might not exclude sensitive files that are underneath those directories. 
	    In cloud technologies and containers, this weakness might present itself in the form of misconfigured storage accounts that can be read or written by a public or anonymous user.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Cloud Computing
Parent weaknesses: CWE-668, CWE-668, CWE-285

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] When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.

Demonstrative examples:
The following Azure command updates the settings for a storage account:
However, "Allow Blob Public Access" is set to true, meaning that anonymous/public users can access blobs.
az storage account update --name <storage-account> --resource-group <resource-group> --allow-blob-public-access true
az storage account update --name <storage-account> --resource-group <resource-group> --allow-blob-public-access false

The following Google Cloud Storage command gets the settings for a storage account named 'BUCKET_NAME':
Suppose the command returns the following result:
gsutil iam get gs://BUCKET_NAME
{ 
		      
		       "bindings":[{ 
		        
			 "members":[ 
			  
			   "projectEditor: PROJECT-ID", 
			   "projectOwner: PROJECT-ID"
			  
			 ], 
			 "role":"roles/storage.legacyBucketOwner" 
		        
		       }, 
		       { 
		        
			 "members":[
			  
			   "allUsers", 
			   "projectViewer: PROJECT-ID" 
			   ], 
			   "role":"roles/storage.legacyBucketReader" 
			  
			 } 
		        
		       ] 
		      
		     }

Real-world examples:
  - CVE-2005-1835: Data file under web root.
CWE-553: Command Shell in Externally Accessible Directory

Description:
A possible shell file exists in /cgi-bin/ or other accessible directories. This is extremely dangerous and can be used by an attacker to execute commands on the web server.

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

Consequences:
  - Confidentiality: Execute Unauthorized Code or Commands

Mitigations:
  - [Installation] Remove any Shells accessible under the web root folder and children directories.
CWE-554: ASP.NET Misconfiguration: Not Using Input Validation Framework

Description:
The ASP.NET application does not use an input validation framework.

Affected languages: ASP.NET
Parent weaknesses: CWE-1173

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - [Architecture and Design] Use the ASP.NET validation framework to check all program input before it is processed by the application. Example uses of the validation framework include checking to ensure that: 
                      
                         Phone number fields contain only valid characters in phone numbers
CWE-555: J2EE Misconfiguration: Plaintext Password in Configuration File

Description:
The J2EE application stores a plaintext password in a configuration file.

Extended Description:
Storing a plaintext password in a configuration file allows anyone who can read the file to access the password-protected resource, making it an easy target for attackers.

Affected languages: Java
Parent weaknesses: CWE-260

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Do not hardwire passwords into your software.
  - [Architecture and Design] Use industry standard libraries to encrypt passwords before storage in configuration files.

Demonstrative examples:
Below is a snippet from a Java properties file in which the LDAP server password is stored in plaintext.

webapp.ldap.username=secretUsername webapp.ldap.[CREDENTIAL_REDACTED]
CWE-556: ASP.NET Misconfiguration: Use of Identity Impersonation

Description:
Configuring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges.

Extended Description:
The use of impersonated credentials allows an ASP.NET application to run with either the privileges of the client on whose behalf it is executing or with arbitrary privileges granted in its configuration.

Affected languages: ASP.NET
Parent weaknesses: CWE-266

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Use the least privilege principle.
CWE-558: Use of getlogin() in Multithreaded Application

Description:
The product uses the getlogin() function in a multithreaded context, potentially causing it to return incorrect values.

Extended Description:
The getlogin() function returns a pointer to a string that contains the name of the user associated with the calling process. The function is not reentrant, meaning that if it is called from another process, the contents are not locked out and the value of the string can be changed by another process. This makes it very risky to use because the username can be changed by other processes, so the results of the function cannot be trusted.

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

Consequences:
  - Integrity: Modify Application Data

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

Mitigations:
  - [Architecture and Design] Using names for security purposes is not advised. Names are easy to forge and can have overlapping user IDs, potentially causing confusion or impersonation.
  - [Implementation] Use getlogin_r() instead, which is reentrant, meaning that other processes are locked out from changing the username.

Demonstrative examples:
The following code relies on getlogin() to determine whether or not a user is trusted. It is easily subverted.

[CREDENTIAL_REDACTED](getlogin()); if (isTrustedGroup(pwd->pw_gid)) { allow(); } else { deny(); }
CWE-56: Path Equivalence: 'filedir*' (Wildcard)

Description:
The product accepts path input in the form of asterisk wildcard ('filedir*') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-41, CWE-155

Consequences:
  - Confidentiality: Read Files or Directories

Mitigations:
  - [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-2004-0696: List directories using desired path and "*"
  - CVE-2002-0433: List files in web server using "*.ext"
CWE-560: Use of umask() with chmod-style Argument

Description:
The product calls umask() with an incorrect argument that is specified as if it is an argument to chmod().

Affected languages: C
Parent weaknesses: CWE-687

Consequences:
  - Confidentiality: Read Files or Directories

Detection methods:
  - Automated Static Analysis: If you suspect misuse of umask(), you can use grep to spot call instances of umask().

Mitigations:
  - [Implementation] Use umask() with the correct argument.
CWE-561: Dead Code

Description:
The product contains dead code, which can never be executed.

Extended Description:
Dead code is code that can never be executed in a running program. The surrounding code makes it impossible for a section of code to ever be executed.

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

Consequences:
  - Other: Quality Degradation
  - Other: Reduce Maintainability

Detection methods:
  - Architecture or Design Review: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                           
  - Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                           
  - Dynamic Analysis with Manual Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Automated Static Analysis: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             

Mitigations:
  - [Implementation] Remove dead code before deploying the application.

Demonstrative examples:
The condition for the second if statement is impossible to satisfy. It requires that the variables be non-null. However, on the only path where s can be assigned a non-null value, there is a return statement.

String s = null; if (b) { s = "Yes"; return; } 
                      if (s != null) { Dead(); }

In the following class, two private methods call each other, but since neither one is ever invoked from anywhere else, they are both dead code.
(In this case it is a good thing that the methods are dead: invoking either one would cause an infinite loop.)
public class DoubleDead { private void doTweedledee() { doTweedledumb(); } private void doTweedledumb() { doTweedledee(); } public static void main(String[] args) { System.out.println("running DoubleDead"); } }

Real-world examples:
  - CVE-2014-1266: Chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-56
CWE-562: Return of Stack Variable Address

Description:
A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.

Extended Description:
Because local variables are allocated on the stack, when a program returns a pointer to a local variable, it is returning a stack address. A subsequent function call is likely to re-use this same stack address, thereby overwriting the value of the pointer, which no longer corresponds to the same variable since a function's stack frame is invalidated when it returns. At best this will cause the value of the pointer to change unexpectedly. In many cases it causes the program to crash the next time the pointer is dereferenced.

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

Consequences:
  - Availability: Read Memory

Detection methods:
  - Fuzzing: Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with rand
  - 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
  - Automated Dynamic Analysis: Use tools that are integrated during
	     compilation to insert runtime error-checking mechanisms
	     related to memory safety errors, such as AddressSanitizer
	     (ASan) for C/C++ [REF-1518].

Mitigations:
  - [Implementation] Fix the code so that it does not return a stack address.

Demonstrative examples:
The following function returns a stack address.

char* getName() { char name[STR_MAX]; fillInName(name); return name; }

Real-world examples:
  - CVE-2024-33045: product returns stack variable address, leading to memory corruption
CWE-563: Assignment to Variable without Use

Description:
The variable's value is assigned but never used, making it a dead store.

Extended Description:
After the assignment, the variable is either assigned another value or goes out of scope. It is likely that the variable is simply vestigial, but it is also possible that the unused variable points out a bug.

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

Consequences:
  - Other: Quality Degradation

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] Remove unused variables from the code.

Demonstrative examples:
The following code excerpt assigns to the variable r and then overwrites the value without using it.

r = getName(); r = getNewBuffer(buf);
CWE-564: SQL Injection: Hibernate

Description:
Using Hibernate to execute a dynamic SQL statement built with user-controlled input can allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.

Affected languages: SQL
Affected technologies: Database Server
Parent weaknesses: CWE-89, CWE-89, CWE-89

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Requirements] A non-SQL style database which is not subject to this flaw may be chosen.
  - [Architecture and Design] Follow the principle of least privilege when creating user accounts to a SQL database. Users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot r
  - [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-s
  - [Implementation] Implement SQL strings using prepared statements that bind variables. Prepared statements that do not bind variables can be vulnerable to attack.

Demonstrative examples:
The following code excerpt uses Hibernate's HQL syntax to build a dynamic query that's vulnerable to SQL injection.

String street = getStreetFromUser(); Query query = session.createQuery("from Address a where a.street='" + street + "'");
CWE-565: Reliance on Cookies without Validation and Integrity Checking

Description:
The product relies on the existence or values of cookies when performing security-critical operations, but it does not properly ensure that the setting is valid for the associated user.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-642, CWE-669, CWE-602

Consequences:
  - Confidentiality: Modify Application Data
  - 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 using cookie data for a security-related decision.
  - [Implementation] Perform thorough input validation (i.e.: server side validation) on the cookie data if you're going to use it for a security related decision.
  - [Architecture and Design] Add integrity checks to detect tampering.
  - [Architecture and Design] Protect critical cookies from replay attacks, since cross-site scripting or other attacks may allow attackers to steal a strongly-encrypted cookie that also passes integrity checks. This mitigation applies to cookies that should only be valid during a single transaction or session. By enforcing time

Demonstrative examples:
The following code excerpt reads a value from a browser cookie to determine the role of the user.
It is easy for an attacker to modify the "role" value found in the locally stored cookie, allowing privilege escalation.
Cookie[] cookies = request.getCookies(); for (int i =0; i< cookies.length; i++) { Cookie c = cookies[i]; if (c.getName().equals("role")) { userRole = c.getValue(); } }

Real-world examples:
  - CVE-2008-5784: e-dating application allows admin privileges by setting the admin cookie to 1.