deardaniel/secdata-raw huggingface dataset:
CWE-58: Path Equivalence: Windows 8.3 Filename

Description:
The product contains a protection mechanism that restricts access to a long filename on a Windows operating system, but it does not properly restrict access to the equivalent short "8.3" filename.

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

Consequences:
  - Confidentiality: Read Files or Directories

Mitigations:
  - [System Configuration] Disable Windows from supporting 8.3 filenames by editing the Windows registry. Preventing 8.3 filenames will not remove previously generated 8.3 filenames.

Real-world examples:
  - CVE-1999-0012: Multiple web servers allow restriction bypass using 8.3 names instead of long names
  - CVE-2001-0795: Source code disclosure using 8.3 file name.
  - CVE-2005-0471: Multi-Factor Vulnerability. Product generates temporary filenames using long filenames, which become predictable in 8.3 format.
CWE-580: clone() Method Without super.clone()

Description:
The product contains a clone() method that does not call super.clone() to obtain the new object.

Extended Description:
All implementations of clone() should obtain the new object by calling super.clone(). If a class does not follow this convention, a subclass's clone() method will return an object of the wrong type.

Affected languages: Java
Parent weaknesses: CWE-664, CWE-573

Consequences:
  - Integrity: Unexpected State

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] Call super.clone() within your clone() method, when obtaining a new object.
  - [Implementation] In some cases, you can eliminate the clone method altogether and use copy constructors.

Demonstrative examples:
The following two classes demonstrate a bug introduced by not calling super.clone(). Because of the way Kibitzer implements clone(), FancyKibitzer's clone method will return an object of type Kibitzer instead of FancyKibitzer.

public class Kibitzer { 
                         public Object clone() throws CloneNotSupportedException { 
                               
                                  Object returnMe = new Kibitzer(); ... 
                            } 
                      } 
                      public class FancyKibitzer extends Kibitzer{ 
                         public Object clone() throws CloneNotSupportedException { 
                               
                                  Object returnMe = super.clone(); ... 
                            }
CWE-581: Object Model Violation: Just One of Equals and Hashcode Defined

Description:
The product does not maintain equal hashcodes for equal objects.

Extended Description:
Java objects are expected to obey a number of invariants related to equality. One of these invariants is that equal objects must have equal hashcodes. In other words, if a.equals(b) == true then a.hashCode() == b.hashCode().

Affected languages: Java
Parent weaknesses: CWE-573, CWE-697

Consequences:
  - Integrity: 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] Both Equals() and Hashcode() should be defined.
CWE-582: Array Declared Public, Final, and Static

Description:
The product declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified.

Extended Description:
Because arrays are mutable objects, the final constraint requires that the array object itself be assigned only once, but makes no guarantees about the values of the array elements. Since the array is public, a malicious program can change the values stored in the array. As such, in most cases an array declared public, final and static is a bug.

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] In most situations the array should be made private.

Demonstrative examples:
The following Java Applet code mistakenly declares an array public, final and static.

public final class urlTool extends Applet { public final static URL[] urls; ... }
CWE-583: finalize() Method Declared Public

Description:
The product violates secure coding principles for mobile code by declaring a finalize() method public.

Extended Description:
A product should never call finalize explicitly, except to call super.finalize() inside an implementation of finalize(). In mobile code situations, the otherwise error prone practice of manual garbage collection can become a security threat if an attacker can maliciously invoke a finalize() method because it is declared with public access.

Affected languages: Java
Parent weaknesses: CWE-668

Consequences:
  - Confidentiality: Alter Execution Logic

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

Mitigations:
  - [Implementation] If you are using finalize() as it was designed, there is no reason to declare finalize() with anything other than protected access.

Demonstrative examples:
The following Java Applet code mistakenly declares a public finalize() method.
Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your
CWE-584: Return Inside Finally Block

Description:
The code has a return statement inside a finally block, which will cause any thrown exception in the try block to be discarded.

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

Consequences:
  - Other: Alter Execution Logic

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

Mitigations:
  - [Implementation] Do not use a return statement inside the finally block. The finally block should have "cleanup" code.

Demonstrative examples:
In the following code excerpt, the IllegalArgumentException will never be delivered to the caller. The finally block will cause the exception to be discarded.

try { ... throw IllegalArgumentException(); } finally { return r; }
CWE-585: Empty Synchronized Block

Description:
The product contains an empty synchronized block.

Extended Description:
An empty synchronized block does not actually accomplish any synchronization and may indicate a troubled section of code. An empty synchronized block can occur because code no longer needed within the synchronized block is commented out without removing the synchronized block.

Affected languages: Java
Parent weaknesses: CWE-1071

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] When you come across an empty synchronized statement, or a synchronized statement in which the code has been commented out, try to determine what the original intentions were and whether or not the synchronized block is still necessary.

Demonstrative examples:
The following code attempts to synchronize on an object, but does not execute anything in the synchronized block. This does not actually accomplish anything and may be a sign that a programmer is wrestling with synchronization but has not yet achieved the result they intend.
Instead, in a correct usage, the synchronized statement should contain procedures that access or modify data that is exposed to multiple threads. For example, consider a scenario in which several threads are accessing student records at the same time. The method which sets the student ID to a new value will need to make sure that nobody else is accessing this data at the same time and will require synchronization.
synchronized(this) { }
public void setID(int ID){ synchronized(this){ this.ID = ID; } }
CWE-586: Explicit Call to Finalize()

Description:
The product makes an explicit call to the finalize() method from outside the finalizer.

Extended Description:
While the Java Language Specification allows an object's finalize() method to be called from outside the finalizer, doing so is usually a bad idea. For example, calling finalize() explicitly means that finalize() will be called more than once: the first time will be the explicit call and the last time will be the call that is made after the object is garbage collected.

Affected languages: Java
Parent weaknesses: CWE-1076

Consequences:
  - Integrity: Unexpected State

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 make explicit calls to finalize().

Demonstrative examples:
The following code fragment calls finalize() explicitly:

// time to clean up 
                      widget.finalize();
CWE-587: Assignment of a Fixed Address to a Pointer

Description:
The product sets a pointer to a specific address other than NULL or 0.

Extended Description:
Using a fixed address is not portable, because that address will probably not be valid in all environments or platforms.

Affected languages: Memory-Unsafe, C, C++, C#, Assembly
Parent weaknesses: CWE-344, CWE-758

Consequences:
  - Integrity: Execute Unauthorized Code or Commands
  - Availability: DoS: Crash, Exit, or Restart
  - Confidentiality: Read Memory

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
  - 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] Never set a pointer to a fixed address.

Demonstrative examples:
This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function.
The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.
int (*pt2Function) (float, char, char)=0x08040000; int result2 = (*pt2Function) (12, 'a', 'b'); 
                      // Here we can inject code to execute.
CWE-588: Attempt to Access Child of a Non-structure Pointer

Description:
Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption.

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

Consequences:
  - Integrity: Modify Memory
  - Availability: DoS: Crash, Exit, or Restart

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:
  - [Requirements] The choice could be made to use a language that is not susceptible to these issues.
  - [Implementation] Review of type casting operations can identify locations where incompatible types are cast.

Demonstrative examples:
The following example demonstrates the weakness.

struct foo { int i; } ... int main(int argc, char **argv) { *foo = (struct foo *)main; foo->i = 2; return foo->i; }

Real-world examples:
  - CVE-2021-3510: JSON decoder accesses a C union using an invalid offset to an object
CWE-589: Call to Non-ubiquitous API

Description:
The product uses an API function that does not exist on all versions of the target platform. This could cause portability problems or inconsistencies that allow denial of service or other consequences.

Extended Description:
Some functions that offer security features supported by the OS are not available on all versions of the OS in common use. Likewise, functions are often deprecated or made obsolete for security reasons and should not be used.

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

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] Always test your code on any platform on which it is targeted to run on.
  - [Testing] Test your code on the newest and oldest platform on which it is targeted to run on.
  - [Testing] Develop a system to test for API functions that are not portable.
CWE-59: Improper Link Resolution Before File Access ('Link Following')

Description:
The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.

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

Consequences:
  - Confidentiality: Read Files or Directories
  - Other: Execute Unauthorized Code or Commands

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

Mitigations:
  - [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: Window manager does not properly handle when certain symbolic links point to "stale" locations, which could allow local users to create or truncate arbitrary files.
CWE-591: Sensitive Data Storage in Improperly Locked Memory

Description:
The product stores sensitive data in memory that is not locked, or that has been incorrectly locked, which might cause the memory to be written to swap files on disk by the virtual memory manager. This can make the data more accessible to external actors.

Extended Description:
On Windows systems the VirtualLock function can lock a page of memory to ensure that it will remain present in memory and not be swapped to disk. However, on older versions of Windows, such as 95, 98, or Me, the VirtualLock() function is only a stub and provides no protection. On POSIX systems the mlock() call ensures that a page will stay resident in memory but does not guarantee that the page will not appear in the swap. Therefore, it is unsuitable for use as a protection mechanism for sensitive data. Some platforms, in particular Linux, do make the guarantee that the page will not be swapped, but this is non-standard and is not portable. Calls to mlock() also require supervisor privilege. Return values for both of these calls must be checked to ensure that the lock operation was actually successful.

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

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Architecture and Design] Identify data that needs to be protected from swapping and choose platform-appropriate protection mechanisms.
  - [Implementation] Check return values to ensure locking operations are successful.

Real-world examples:
  - CVE-2024-38106: OS kernel stores sensitive data in improperly locked memory, allowing local users to gain privileges by winning a race condition
CWE-593: Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created

Description:
The product modifies the SSL context after connection creation has begun.

Extended Description:
If the program modifies the SSL_CTX object after creating SSL objects from it, there is the possibility that older SSL objects created from the original context could all be affected by that change.

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

Consequences:
  - Access Control: Bypass Protection Mechanism
  - Confidentiality: Read Application Data

Mitigations:
  - [Architecture and Design] Use a language or a library that provides a cryptography framework at a higher level of abstraction.
  - [Implementation] Most SSL_CTX functions have SSL counterparts that act on SSL-type objects.
  - [Implementation] Applications should set up an SSL_CTX completely, before creating SSL objects from it.

Demonstrative examples:
The following example demonstrates the weakness.

#define CERT "secret.pem" #define CERT2 "secret2.pem" 
                      int main(){ 
                         SSL_CTX *ctx; SSL *ssl; init_OpenSSL(); seed_prng(); 
                            ctx = SSL_CTX_new(SSLv23_method()); 
                            if (SSL_CTX_use_certificate_chain_file(ctx, CERT) != 1) int_error("Error loading certificate from file"); 
                            
                            if (SSL_CTX_use_PrivateKey_file(ctx, CERT, SSL_FILETYPE_PEM) != 1) int_error("Error loading private key from file"); 
                            
                            if (!(ssl = SSL_new(ctx))) int_error("Error creating an SSL context"); 
                            
                            if ( SSL_CTX_set_def
CWE-594: J2EE Framework: Saving Unserializable Objects to Disk

Description:
When the J2EE container attempts to write unserializable objects to disk there is no guarantee that the process will complete successfully.

Extended Description:
In heavy load conditions, most J2EE application frameworks flush objects to disk to manage memory requirements of incoming requests. For example, session scoped objects, and even application scoped objects, are written to disk when required. While these application frameworks do the real work of writing objects to disk, they do not enforce that those objects be serializable, thus leaving the web application vulnerable to crashes induced by serialization failure. An attacker may be able to mount a denial of service attack by sending enough requests to the server to force the web application to save objects to disk.

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

Consequences:
  - Integrity: Modify Application Data
  - Availability: DoS: Crash, Exit, or Restart

Mitigations:
  - [Architecture and Design] All objects that become part of session and application scope must implement the java.io.Serializable interface to ensure serializability of containing objects.

Demonstrative examples:
In the following Java example, a Customer Entity JavaBean provides access to customer information in a database for a business application. The Customer Entity JavaBean is used as a session scoped object to return customer information to a Session EJB.
However, the Customer Entity JavaBean is an unserialized object which can cause serialization failure and crash the application when the J2EE container attempts to write the object to the system. Session scoped objects must implement the Serializable interface to ensure that the objects serialize properly.
@Entity public class Customer { 
                      
                         private String id; private String firstName; private String lastName; private Address address; 
                            public Customer() { }