deardaniel/secdata-raw huggingface dataset:
CWE-595: Comparison of Object References Instead of Object Contents

Description:
The product compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.

Extended Description:
For example, in Java, comparing objects using == usually produces deceptive results, since the == operator compares object references rather than values; often, this means that using == for strings is actually comparing the strings' references, not their values.

Affected languages: Java, JavaScript, PHP, Not Language-Specific
Parent weaknesses: CWE-1025

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] In Java, use the equals() method to compare objects instead of the == operator. If using ==, it is important for performance reasons that your objects are created by a static factory, not by a constructor.

Demonstrative examples:
In the example below, two Java String objects are declared and initialized with the same string values. An if statement is used to determine if the strings are equivalent.
However, the if statement will not be executed as the strings are compared using the "==" operator. For Java objects, such as String objects, the "==" operator compares object references, not object values. While the two String objects above contain the same string values, they refer to different object references, so the System.out.println statement will not be executed. To compare object values, the previous code could be modified to use the equals method:
String str1 = new String("Hello"); String str2 = new String("Hello"); if (str1 == str2) { System.out.println("str1 == str2"); }
if (str1.equals(str2)) { System.out.p

In the following Java example, two BankAccount objects are compared in the isSameAccount method using the == operator.
Using the == operator to compare objects may produce incorrect or deceptive results by comparing object references rather than values. The equals() method should be used to ensure correct results or objects should contain a member variable that uniquely identifies the object.
public boolean isSameAccount(BankAccount accountA, BankAccount accountB) { return accountA == accountB; }
public boolean isSameAccount(BankAccount accountA, BankAccount accountB) { return accountA.equals(accountB); }
CWE-597: Use of Wrong Operator in String Comparison

Description:
The product uses the wrong operator when comparing a string, such as using "==" when the .equals() method should be used instead.

Extended Description:
In Java, using == or != to compare two strings for equality actually compares two objects for equality rather than their string values for equality. Chances are good that the two references will never be equal. While this weakness often only affects program correctness, if the equality is used for a security decision, the unintended comparison result could be leveraged to affect program security.

Affected languages: Not Language-Specific, Java, JavaScript, PHP
Parent weaknesses: CWE-595, CWE-595, CWE-480

Consequences:
  - Other: Other

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] Within Java, use .equals() to compare string values. 
               Within JavaScript, use == to compare string values. 
               Within PHP, use == to compare a numeric value to a string value. (PHP converts the string to a number.)

Demonstrative examples:
In the example below, two Java String objects are declared and initialized with the same string values. An if statement is used to determine if the strings are equivalent.
However, the if statement will not be executed as the strings are compared using the "==" operator. For Java objects, such as String objects, the "==" operator compares object references, not object values. While the two String objects above contain the same string values, they refer to different object references, so the System.out.println statement will not be executed. To compare object values, the previous code could be modified to use the equals method:
String str1 = new String("Hello"); String str2 = new String("Hello"); if (str1 == str2) { System.out.println("str1 == str2"); }
if (str1.equals(str2)) { System.out.p

In the example below, three JavaScript variables are declared and initialized with the same values. Note that JavaScript will change a value between numeric and string as needed, which is the reason an integer is included with the strings. An if statement is used to determine whether the values are the same.
However, the body of the if statement will not be executed, as the "===" compares both the type of the variable AND the value. As the types of the first comparison are number and string, it fails. The types in the second are int and reference, so this one fails as well. The types in the third are reference and string, so it also fails. 
                While the variables above contain the same values, they are contained in different types, so the document.getElementById... statement w
CWE-598: Use of HTTP Request With Sensitive Query String

Description:
The web application uses an HTTP method to process a request, but the request includes sensitive information in the query string.

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

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 sending sensitive information, only
               include it in the request body or request headers
               instead of the query string. This may require avoiding
               use of GET requests.

Real-world examples:
  - CVE-2025-1738: Security camera includes a password in its query string
  - CVE-2025-31954: ML/NLP-based automation product calls a GET method with sensitive information in the query string.
  - CVE-2024-31842: Web-based communication product includes an access token in the query string of a GET request
  - CVE-2022-23546: A discussion platform leaks private information in GET requests.
CWE-599: Missing Validation of OpenSSL Certificate

Description:
The product uses OpenSSL and trusts or uses a certificate without using the SSL_get_verify_result() function to ensure that the certificate satisfies all necessary security requirements.

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

Consequences:
  - Confidentiality: Read Application Data
  - Access Control: Bypass Protection Mechanism
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Ensure that proper authentication is included in the system design.
  - [Implementation] Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications.

Demonstrative examples:
The following OpenSSL code ensures that the host has a certificate.
Note that the code does not call SSL_get_verify_result(ssl), which effectively disables the validation step that checks the certificate.
if (cert = SSL_get_peer_certificate(ssl)) { 
                         
                            
                            // got certificate, host can be trusted 
                            
                            
                            //foo=SSL_get_verify_result(ssl); 
                            
                            
                            //if (X509_V_OK==foo) ... 
                            
                         
                      }
CWE-6: J2EE Misconfiguration: Insufficient Session-ID Length

Description:
The J2EE application is configured to use an insufficient session ID length.

Extended Description:
If an attacker can guess or steal a session ID, then they may be able to take over the user's session (called session hijacking). The number of possible session IDs increases with increased session ID length, making it more difficult to guess or steal a session ID.

Affected languages: Java
Affected technologies: Web Based, Web Server
Parent weaknesses: CWE-334

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Implementation] Session identifiers should be at least 128 bits long to prevent brute-force session guessing. A shorter session identifier leaves the application open to brute-force session guessing attacks.
  - [Implementation] A lower bound on the number of valid session identifiers that are available to be guessed is the number of users that are active on a site at any given moment. However, any users that abandon their sessions without logging out will increase this number. (This is one of many good reasons to have a sh

Demonstrative examples:
The following XML example code is a deployment descriptor for a Java web application deployed on a Sun Java Application Server. This deployment descriptor includes a session configuration property for configuring the session ID length.
This deployment descriptor has set the session ID length for this Java web application to 8 bytes (or 64 bits). The session ID length for Java web applications should be set to 16 bytes (128 bits) to prevent attackers from guessing and/or stealing a session ID and taking over a user's session.
<sun-web-app> 
                         ... <session-config> 
                               <session-properties> <property name="idLengthBytes" value="8"> <description>The number of bytes in this web module's session ID.</description> </property> </session-properties>
CWE-600: Uncaught Exception in Servlet

Description:
The Servlet does not catch all exceptions, which may reveal sensitive debugging information.

Extended Description:
When a Servlet throws an exception, the default error response the Servlet container sends back to the user typically includes debugging information. This information is of great value to an attacker. For example, a stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.

Affected languages: Java
Affected technologies: Web Server
Parent weaknesses: CWE-248

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Implementation] Implement Exception blocks to handle all types of Exceptions.

Demonstrative examples:
The following example attempts to resolve a hostname.
A DNS lookup failure will cause the Servlet to throw an exception.
protected void doPost (HttpServletRequest req, HttpServletResponse res) throws IOException { String ip = req.getRemoteAddr(); InetAddress addr = InetAddress.getByName(ip); ... out.println("hello " + addr.getHostName()); }
CWE-603: Use of Client-Side Authentication

Description:
A client/server product performs authentication within client code but not in server code, allowing server-side authentication to be bypassed via a modified client that omits the authentication check.

Extended Description:
Client-side authentication is extremely weak and may be breached easily. Any attacker may read the source code and reverse-engineer the authentication mechanism to access parts of the application which would otherwise be protected.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Do not rely on client side data. Always perform server side authentication.

Demonstrative examples:
In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.
Multiple vendors used client-side authentication in their OT products.

Real-world examples:
  - CVE-2022-33139: SCADA system only uses client-side authentication, allowing adversaries to impersonate other users.
  - CVE-2006-0230: Client-side check for a password allows access to a server using crafted XML requests from a modified client.
CWE-605: Multiple Binds to the Same Port

Description:
When multiple sockets are allowed to bind to the same port, other services on that port may be stolen or spoofed.

Extended Description:
On most systems, a combination of setting the SO_REUSEADDR socket option, and a call to bind() allows any process to bind to a port to which a previous process has bound with INADDR_ANY. This allows a user to bind to the specific address of a server bound to INADDR_ANY on an unprivileged port, and steal its UDP packets/TCP connection.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-675, CWE-666

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:
  - [Policy] Restrict server socket address to known local addresses.

Demonstrative examples:
This code binds a server socket to port 21, allowing the server to listen for traffic on that port.
This code may result in two servers binding a socket to same port, thus receiving each other's traffic. This could be used by an attacker to steal packets meant for another process, such as a secure FTP server.
void bind_socket(void) { 
                         
                            int server_sockfd; int server_len; struct sockaddr_in server_address; 
                            
                            /*unlink the socket if already bound to avoid an error when bind() is called*/ 
                            
                            unlink("server_socket"); server_sockfd = socket(AF_INET, SOCK_STREAM, 0); 
                            server_address.sin_family = AF_INET; serv
CWE-606: Unchecked Input for Loop Condition

Description:
The product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service or other consequences because of excessive looping.

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

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

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] Do not use user-controlled data for loop conditions.
  - [Implementation] Perform input validation.

Demonstrative examples:
The following example demonstrates the weakness.

void iterate(int n){ int i; for (i = 0; i < n; i++){ foo(); } } void iterateFoo() { unsigned int num; scanf("%u",&num); iterate(num); }

In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing.
However, the message length variable (msgLength) from the structure is used as the condition for ending the for loop without validating that msgLength accurately reflects the actual length of the message body (CWE-606). If msgLength indicates a length that is longer than the size of a message body (CWE-130), then this can result in a buffer over-read by reading past the end of the buffer (CWE-126).
int processMessageFromSocket(i

Real-world examples:
  - CVE-2025-32399: Chain: library for implementing Profinet devices does not check an input for a loop condition (CWE-606), allowing an infinite loop (CWE-835) via a crafted RPC packet
CWE-607: Public Static Final Field References Mutable Object

Description:
A public or protected static final field references a mutable object, which allows the object to be changed by malicious code, or accidentally from another package.

Affected languages: Java
Parent weaknesses: CWE-471

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:
  - [Implementation] Protect mutable objects by making them private. Restrict access to the getter and setter as well.

Demonstrative examples:
Here, an array (which is inherently mutable) is labeled public static final.

public static final String[] USER_ROLES;
CWE-608: Struts: Non-private Field in ActionForm Class

Description:
An ActionForm class contains a field that has not been declared private, which can be accessed without using a setter or getter.

Affected languages: Java
Parent weaknesses: CWE-668

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:
  - [Implementation] Make all fields private. Use getter to get the value of the field. Setter should be used only by the framework; setting an action form field from other actions is bad practice and should be avoided.

Demonstrative examples:
In the following Java example the class RegistrationForm is a Struts framework ActionForm Bean that will maintain user input data from a registration webpage for a online business site. The user will enter registration data and through the Struts framework the RegistrationForm bean will maintain the user data.
However, within the RegistrationForm the member variables for the registration form input data are declared public not private. All member variables within a Struts framework ActionForm class must be declared private to prevent the member variables from being modified without using the getter and setter methods. The following example shows the member variables being declared private and getter and setter methods declared for accessing the member variables.
public class RegistrationFo
CWE-609: Double-Checked Locking

Description:
The product uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.

Extended Description:
Double-checked locking refers to the situation where a programmer checks to see if a resource has been initialized, grabs a lock, checks again to see if the resource has been initialized, and then performs the initialization if it has not occurred yet. This should not be done, as it is not guaranteed to work in all languages and on all architectures. In summary, other threads may not be operating inside the synchronous block and are not guaranteed to see the operations execute in the same order as they would appear inside the synchronous block.

Affected languages: Java
Parent weaknesses: CWE-667

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:
  - [Implementation] While double-checked locking can be achieved in some languages, it is inherently flawed in Java before 1.5, and cannot be achieved without compromising platform independence. Before Java 1.5, only use of the synchronized keyword is known to work. Beginning in Java 1.5, use of the "volatile" keyword 

Demonstrative examples:
It may seem that the following bit of code achieves thread safety while avoiding unnecessary synchronization...
The programmer wants to guarantee that only one Helper() object is ever allocated, but does not want to pay the cost of synchronization every time this code is called.
if (helper == null) { 
                         synchronized (this) { if (helper == null) { helper = new Helper(); } } 
                      } return helper;
helper = new Helper();
CWE-61: UNIX Symbolic Link (Symlink) Following

Description:
The product, when opening a file or directory, does not sufficiently account for when the file is a symbolic link that resolves to a target outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.

Extended Description:
A product that allows UNIX symbolic links (symlink) as part of paths whether in internal code or through user input can allow an attacker to spoof the symbolic link and traverse the file system to unintended locations or access arbitrary files. The symbolic link can permit an attacker to read/write/corrupt a file that they originally did not have permissions to access.

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

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] Symbolic link attacks often occur when a program creates a tmp directory that stores files/links. Access to the directory should be restricted to the program as to prevent attackers from manipulating the files.
  - [Architecture and Design] Follow the principle of least privilege when assigning access rights to entities in a software system. 
                   Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected ar

Real-world examples:
  - CVE-1999-1386: Some versions of Perl follow symbolic links when running with the -e option, which allows local users to overwrite arbitrary files via a symlink attack.
  - CVE-2000-1178: Text editor follows symbolic links when creating a rescue copy during an abnormal exit, which allows local users to overwrite the files of other users.
  - CVE-2004-0217: Antivirus update allows local users to create or append to arbitrary files via a symlink attack on a logfile.
  - CVE-2003-0517: Symlink attack allows local users to overwrite files.
  - CVE-2004-0689: Possible interesting example