deardaniel/secdata-raw huggingface dataset:
CWE-622: Improper Validation of Function Hook Arguments

Description:
The product adds hooks to user-accessible API functions, but it does not properly validate the arguments. This could lead to resultant vulnerabilities.

Extended Description:
Such hooks can be used in defensive software that runs with privileges, such as anti-virus or firewall, which hooks kernel calls. When the arguments are not validated, they could be used to bypass the protection scheme or attack the product itself.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - [Architecture and Design] Ensure that all arguments are verified, as defined by the API you are protecting.
  - [Architecture and Design] Drop privileges before invoking such functions, if possible.

Real-world examples:
  - CVE-2007-0708: DoS in firewall using standard Microsoft functions
  - CVE-2006-7160: DoS in firewall using standard Microsoft functions
  - CVE-2007-1376: function does not verify that its argument is the proper type, leading to arbitrary memory write
  - CVE-2007-1220: invalid syscall arguments bypass code execution limits
  - CVE-2006-4541: DoS in IDS via NULL argument
CWE-623: Unsafe ActiveX Control Marked Safe For Scripting

Description:
An ActiveX control is intended for restricted use, but it has been marked as safe-for-scripting.

Extended Description:
This might allow attackers to use dangerous functionality via a web page that accesses the control, which can lead to different resultant vulnerabilities, depending on the control's behavior.

Affected languages: Not Language-Specific
Affected technologies: Web Based
Parent weaknesses: CWE-267

Consequences:
  - Confidentiality: Execute Unauthorized Code or Commands

Mitigations:
  - [Architecture and Design] During development, do not mark it as safe for scripting.
  - [System Configuration] After distribution, you can set the kill bit for the control so that it is not accessible from Internet Explorer.

Real-world examples:
  - CVE-2007-0617: control allows attackers to add malicious email addresses to bypass spam limits
  - CVE-2007-0219: web browser uses certain COM objects as ActiveX
  - CVE-2006-6510: kiosk allows bypass to read files
CWE-624: Executable Regular Expression Error

Description:
The product uses a regular expression that either (1) contains an executable component with user-controlled inputs, or (2) allows a user to enable execution by inserting pattern modifiers.

Extended Description:
Case (2) is possible in the PHP preg_replace() function, and possibly in other languages when a user-controlled input is inserted into a string that is later parsed as a regular expression.

Affected languages: PHP, Perl
Parent weaknesses: CWE-77, CWE-77, CWE-77

Consequences:
  - Confidentiality: Execute Unauthorized Code or Commands

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] The regular expression feature in some languages allows inputs to be quoted or escaped before insertion, such as \Q and \E in Perl.

Real-world examples:
  - CVE-2006-2059: Executable regexp in PHP by inserting "e" modifier into first argument to preg_replace
  - CVE-2005-3420: Executable regexp in PHP by inserting "e" modifier into first argument to preg_replace
  - CVE-2006-2878: Complex curly syntax inserted into the replacement argument to PHP preg_replace(), which uses the "/e" modifier
  - CVE-2006-2908: Function allows remote attackers to execute arbitrary PHP code via the username field, which is used in a preg_replace function call with a /e (executable) modifier.
CWE-625: Permissive Regular Expression

Description:
The product uses a regular expression that does not sufficiently restrict the set of allowed values.

Extended Description:
This effectively causes the regexp to accept substrings that match the pattern, which produces a partial comparison to the target. In some cases, this can lead to other weaknesses. Common errors include: 
                
                   not identifying the beginning and end of the target string 
                   using wildcards instead of acceptable character ranges 
                   others

Affected languages: Perl, PHP
Parent weaknesses: CWE-185

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] When applicable, ensure that the regular expression marks beginning and ending string patterns, such as "/^string$/" for Perl.

Demonstrative examples:
The following code takes phone numbers as input, and uses a regular expression to reject invalid phone numbers.
An attacker could provide an argument such as: "; ls -l ; echo 123-456" This would pass the check, since "123-456" is sufficient to match the "\d+-\d+" portion of the regular expression.
$phone = GetPhoneNumber(); if ($phone =~ /\d+-\d+/) { 
                            # looks like it only has hyphens and digits 
                            system("lookup-phone $phone"); }
                      else { error("malformed number!"); }

This code uses a regular expression to validate an IP string prior to using it in a call to the "ping" command.
Since the regular expression does not have anchors (CWE-777), i.e. is unbounded without ^ or $ characters, then prepending a 0 or 0x to the beginning of the IP address will still result in a matched regex pattern. Since the ping command supports octal and hex prepended IP addresses, it will use the unexpectedly valid IP address (CWE-1389). For example, "0x63.63.63.63" would be considered equivalent to "99.63.63.63". As a result, the attacker could potentially ping systems that the attacker cannot reach directly.
import subprocess 
		  import re 
		   
		  def validate_ip_regex(ip: str): 
		   
		    ip_validator = re.compile(r"((25[0-5]|(2[0-4]|1\d|[1-9]|)\d)\.?\b){4}") 
		    if

Real-world examples:
  - CVE-2021-22204: Chain: regex in EXIF processor code does not correctly determine where a string ends (CWE-625), enabling eval injection (CWE-95), as exploited in the wild per CISA KEV.
  - CVE-2006-1895: ".*" regexp leads to static code injection
  - CVE-2002-2175: insertion of username into regexp results in partial comparison, causing wrong database entry to be updated when one username is a substring of another.
  - CVE-2006-4527: regexp intended to verify that all characters are legal, only checks that at least one is legal, enabling file inclusion.
  - CVE-2005-1949: Regexp for IP address isn't anchored at the end, allowing appending of shell metacharacters.
CWE-626: Null Byte Interaction Error (Poison Null Byte)

Description:
The product does not properly handle null bytes or NUL characters when passing data between different representations or components.

Extended Description:
A null byte (NUL character) can have different meanings across representations or languages. For example, it is a string terminator in standard C libraries, but Perl and PHP strings do not treat it as a terminator. When two representations are crossed - such as when Perl or PHP invokes underlying C functionality - this can produce an interaction error with unexpected results. Similar issues have been reported for ASP. Other interpreters written in C might also be affected. 
             The poison null byte is frequently useful in path traversal attacks by terminating hard-coded extensions that are added to a filename. It can play a role in regular expression processing in PHP.

Affected languages: PHP, Perl, ASP.NET
Parent weaknesses: CWE-147, CWE-436

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] Remove null bytes from all incoming strings.

Real-world examples:
  - CVE-2005-4155: NUL byte bypasses PHP regular expression check
  - CVE-2005-3153: inserting SQL after a NUL byte bypasses allowlist regexp, enabling SQL injection
CWE-627: Dynamic Variable Evaluation

Description:
In a language where the user can influence the name of a variable at runtime, if the variable names are not controlled, an attacker can read or write to arbitrary variables, or access arbitrary functions.

Extended Description:
The resultant vulnerabilities depend on the behavior of the application, both at the crossover point and in any control/data flow that is reachable by the related variables or functions.

Affected languages: PHP, Perl
Parent weaknesses: CWE-914

Consequences:
  - Confidentiality: Modify Application Data

Mitigations:
  - [Implementation] Refactor the code to avoid dynamic variable evaluation whenever possible.
  - [Implementation] Use only allowlists of acceptable variable or function names.
  - [Implementation] For function names, ensure that you are only calling functions that accept the proper number of arguments, to avoid unexpected null arguments.

Real-world examples:
  - CVE-2009-0422: Chain: Dynamic variable evaluation allows resultant remote file inclusion and path traversal.
  - CVE-2007-2431: Chain: dynamic variable evaluation in PHP program used to modify critical, unexpected $_SERVER variable for resultant XSS.
  - CVE-2006-4904: Chain: dynamic variable evaluation in PHP program used to conduct remote file inclusion.
  - CVE-2006-4019: Dynamic variable evaluation in mail program allows reading and modifying attachments and preferences of other users.
CWE-628: Function Call with Incorrectly Specified Arguments

Description:
The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.

Extended Description:
There are multiple ways in which this weakness can be introduced, including: 
                
                   the wrong variable or reference; 
                   an incorrect number of arguments; 
                   incorrect order of arguments; 
                   wrong type of arguments; or 
                   wrong value.

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

Consequences:
  - Other: Quality Degradation

Detection methods:
  - Other: Since these bugs typically introduce incorrect behavior that is obvious to users, they are found quickly, unless they occur in rarely-tested code paths. Managing the correct number of arguments can be

Mitigations:
  - [Build and Compilation] Once found, these issues are easy to fix. Use code inspection tools and relevant compiler features to identify potential violations. Pay special attention to code that is not likely to be exercised heavily during QA.
  - [Architecture and Design] Make sure your API's are stable before you use them in production code.

Demonstrative examples:
The following PHP method authenticates a user given a username/password combination but is called with the parameters in reverse order.

function authenticate($username, $password) { 
                         
                            
                            // authenticate user 
                            ... 
                      } 
                      authenticate($_POST['password'], $_POST['username']);

This Perl code intends to record whether a user authenticated successfully or not, and to exit if the user fails to authenticate. However, when it calls ReportAuth(), the third argument is specified as 0 instead of 1, so it does not exit.

sub ReportAuth { my ($username, $result, $fatal) = @_; PrintLog("auth: username=%s, result=%d", $username, $result); if (($result ne "success") && $fatal) { die "Failed!\n"; } } 
                      sub PrivilegedFunc { my $result = CheckAuth($username); ReportAuth($username, $result, 0); DoReallyImportantStuff(); }

Real-world examples:
  - CVE-2006-7049: The method calls the functions with the wrong argument order, which allows remote attackers to bypass intended access restrictions.
CWE-636: Not Failing Securely ('Failing Open')

Description:
When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.

Extended Description:
By entering a less secure state, the product inherits the weaknesses associated with that state, making it easier to compromise. At the least, it causes administrators to have a false sense of security. This weakness typically occurs as a result of wanting to "fail functional" to minimize administration and support costs, instead of "failing safe."

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, ICS/OT
Parent weaknesses: CWE-657, CWE-755

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Subdivide and allocate resources and components so that a failure in one part does not affect the entire product.

Demonstrative examples:
Switches may revert their functionality to that of hubs when the table used to map ARP information to the switch interface overflows, such as when under a spoofing attack. This results in traffic being broadcast to an eavesdropper, instead of being sent only on the relevant switch interface. To mitigate this type of problem, the developer could limit the number of ARP entries that can be recorded for a given switch interface, while other interfaces may keep functioning normally. Configuration options can be provided on the appropriate actions to be taken in case of a detected failure, but safe defaults should be used.

Real-world examples:
  - CVE-2007-5277: The failure of connection attempts in a web browser resets DNS pin restrictions. An attacker can then bypass the same origin policy by rebinding a domain name to a different IP address. This was an at
  - CVE-2006-4407: Incorrect prioritization leads to the selection of a weaker cipher. Although it is not known whether this issue occurred in implementation or design, it is feasible that a poorly designed algorithm co
CWE-637: Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism')

Description:
The product uses a more complex mechanism than necessary, which could lead to resultant weaknesses when the mechanism is not correctly understood, modeled, configured, implemented, or used.

Extended Description:
Security mechanisms should be as simple as possible. Complex security mechanisms may engender partial implementations and compatibility problems, with resulting mismatches in assumptions and implemented security. A corollary of this principle is that data specifications should be as simple as possible, because complex data specifications result in complex validation code. Complex tasks and systems may also need to be guarded by complex security checks, so simple systems should be preferred.

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

Consequences:
  - Other: Other

Mitigations:
  - [Architecture and Design] Avoid complex security mechanisms when simpler ones would meet requirements. Avoid complex data models, and unnecessarily complex operations. Adopt architectures that provide guarantees, simplify understanding through elegance and abstraction, and that can be implemented similarly. Modularize, isola

Demonstrative examples:
The IPSEC specification is complex, which resulted in bugs, partial implementations, and incompatibilities between vendors.

HTTP Request Smuggling (CWE-444) attacks are feasible because there are not stringent requirements for how illegal or inconsistent HTTP headers should be handled. This can lead to inconsistent implementations in which a proxy or firewall interprets the same data stream as a different set of requests than the end points in that stream.

Real-world examples:
  - CVE-2007-6067: Support for complex regular expressions leads to a resultant algorithmic complexity weakness (CWE-407).
  - CVE-2007-1552: Either a filename extension and a Content-Type header could be used to infer the file type, but the developer only checks the Content-Type, enabling unrestricted file upload (CWE-434).
  - CVE-2007-6479: In Apache environments, a "filename.php.gif" can be redirected to the PHP interpreter instead of being sent as an image/gif directly to the user. Not knowing this, the developer only checks the last e
  - CVE-2005-2148: The developer cleanses the $_REQUEST superglobal array, but PHP also populates $_GET, allowing attackers to bypass the protection mechanism and conduct SQL injection attacks against code that uses $_G
CWE-638: Not Using Complete Mediation

Description:
The product does not perform access checks on a resource every time the resource is accessed by an entity, which can create resultant weaknesses if that entity's rights or privileges change over time.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-657, CWE-862

Consequences:
  - Integrity: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Invalidate cached privileges, file handles or descriptors, or other access credentials whenever identities, processes, policies, roles, capabilities or permissions change. Perform complete authentication checks before accepting, caching and reusing data, dynamic content and code (scripts). Avoid cac
  - [Architecture and Design] Identify all possible code paths that might access sensitive resources. If possible, create and use a single interface that performs the access checks, and develop code standards that require use of this interface.

Demonstrative examples:
When executable library files are used on web servers, which is common in PHP applications, the developer might perform an access check in any user-facing executable, and omit the access check from the library file itself. By directly requesting the library file (CWE-425), an attacker can bypass this access check.

When a developer begins to implement input validation for a web application, often the validation is performed in each area of the code that uses externally-controlled input. In complex applications with many inputs, the developer often misses a parameter here or a cookie there. One frequently-applied solution is to centralize all input validation, store these validated inputs in a separate data structure, and require that all access of those inputs must be through that data structure. An alternate approach would be to use an external input validation framework such as Struts, which performs the validation before the inputs are ever processed by the code.

Real-world examples:
  - CVE-2007-0408: Server does not properly validate client certificates when reusing cached connections.
CWE-64: Windows Shortcut Following (.LNK)

Description:
The product, when opening a file or directory, does not sufficiently handle when the file is a Windows shortcut (.LNK) whose target is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.

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

Consequences:
  - Confidentiality: Read Files or Directories

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-2019-19793: network access control service executes program with high privileges and allows symlink to invoke another executable or perform DLL injection.
  - CVE-2000-0342: Mail client allows remote attackers to bypass the user warning for executable attachments such as .exe, .com, and .bat by using a .lnk file that refers to the attachment, aka "Stealth Attachment."
  - CVE-2001-1042: FTP server allows remote attackers to read arbitrary files and directories by uploading a .lnk (link) file that points to the target file.
  - CVE-2001-1043: FTP server allows remote attackers to read arbitrary files and directories by uploading a .lnk (link) file that points to the target file.
  - CVE-2005-0587: Browser allows remote malicious web sites to overwrite arbitrary files by tricking the user into downloading a .LNK (link) file twice, which overwrites the file that was referenced in the first .LNK f
CWE-641: Improper Restriction of Names for Files and Other Resources

Description:
The product constructs the name of a file or other resource using input from an upstream component, but it does not restrict or incorrectly restricts the resulting name.

Extended Description:
This may produce resultant weaknesses. For instance, if the names of these resources contain scripting characters, it is possible that a script may get executed in the client's browser if the application ever displays the name of the resource on a dynamically generated web page. Alternately, if the resources are consumed by some application parser, a specially crafted name can exploit some vulnerability internal to the parser, potentially resulting in execution of arbitrary code on the server machine. The problems will vary based on the context of usage of such malformed resource names and whether vulnerabilities are present in or assumptions are made by the targeted technology that would make code execution possible.

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

Consequences:
  - Integrity: Execute Unauthorized Code or Commands
  - Confidentiality: Read Application Data

Mitigations:
  - [Architecture and Design] Do not allow users to control names of resources used on the server side.
  - [Architecture and Design] Perform allowlist input validation at entry points and also before consuming the resources. Reject bad file names rather than trying to cleanse them.
  - [Architecture and Design] Make sure that technologies consuming the resources are not vulnerable (e.g. buffer overflow, format string, etc.) in a way that would allow code execution if the name of the resource is malformed.