Krutikp/ComplianceLLM huggingface dataset:
CWE-1236: Improper Neutralization of Formula Elements in a CSV File (Base)

Description: The product saves user-provided information into a Comma-Separated Value (CSV) file, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as a command when the file is opened by a spreadsheet product.

Extended Description: User-provided data is often saved to traditional databases. This data can be exported to a CSV file, which allows users to read the data using spreadsheet software such as Excel, Numbers, or Calc. This software interprets entries beginning with '=' as formulas, which are then executed by the spreadsheet software. The software's formula language often allows methods to access hyperlinks or the local command line, and frequently allows enough characters to invoke an entire script. Attackers can populate data fields which, when saved to a CSV file, may attempt information exfiltration or other malicious activity when automatically executed by the spreadsheet software.


Alternate Terms: ::TERM:CSV Injection::TERM:Formula Injection::TERM:Excel Macro Injection::

Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Other:TECHNOLOGY PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation:NOTE:The weakness is in the implementation of a software's CSV export feature, in particular how it formats formula entries as the output gets flattened into a text file.::



Common Consequences: ::SCOPE:Confidentiality:IMPACT:Read Application Data:IMPACT:Execute Unauthorized Code or Commands:LIKELIHOOD:Low:NOTE:Current versions of Excel warn users of untrusted content.::


Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:When generating CSV output, ensure that formula-sensitive metacharacters are effectively escaped or removed from all data before storage in the resultant CSV. Risky characters include '=' (equal), '+' (plus), '-' (minus), and '@' (at).:EFFECTIVENESS:Moderate::PHASE:Implementation:DESCRIPTION:If a field starts with a formula character, prepend it with a ' (single apostrophe), which prevents Excel from executing the formula.:EFFECTIVENESS:Moderate::PHASE:Architecture and Design:DESCRIPTION:Certain implementations of spreadsheet software might disallow formulas from executing if the file is untrusted, or if the file is not authored by the current user.:EFFECTIVENESS:Limited::

Observed Examples: ::REFERENCE:CVE-2019-12134:DESCRIPTION:Low privileged user can trigger CSV injection through a contact form field value:LINK:https://www.cve.org/CVERecord?id=CVE-2019-12134::REFERENCE:CVE-2019-4521:DESCRIPTION:Cloud management product allows arbitrary command execution via CSV injection:LINK:https://www.cve.org/CVERecord?id=CVE-2019-4521::REFERENCE:CVE-2019-17661:DESCRIPTION:CSV injection in content management system via formula code in a first or last name:LINK:https://www.cve.org/CVERecord?id=CVE-2019-17661::
CWE-1241: Use of Predictable Algorithm in Random Number Generator (Base)

Description: The device uses an algorithm that is predictable and generates a pseudo-random number.

Extended Description: Pseudo-random number generator algorithms are predictable because their registers have a finite number of possible states, which eventually lead to repeating patterns. As a result, pseudo-random number generators (PRNGs) can compromise their randomness or expose their internal state to various attacks, such as reverse engineering or tampering. It is highly recommended to use hardware-based true random number generators (TRNGs) to ensure the security of encryption schemes. TRNGs generate unpredictable, unbiased, and independent random numbers because they employ physical phenomena, e.g., electrical noise, as sources to generate random numbers.



Applicable Platforms: ::TECHNOLOGY CLASS:System on Chip:TECHNOLOGY PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Architecture and Design::PHASE:Implementation:NOTE:In many cases, the design originally defines a cryptographically secure random number generator, but is then changed during implementation due to unforeseen constraints.::



Common Consequences: ::SCOPE:Confidentiality:IMPACT:Read Application Data:LIKELIHOOD:High::


Potential Mitigations: ::PHASE:Architecture and Design:DESCRIPTION:A true random number generator should be specified for cryptographic algorithms.::PHASE:Implementation:DESCRIPTION:A true random number generator should be implemented for cryptographic algorithms.::

Observed Examples: ::REFERENCE:CVE-2021-3692:DESCRIPTION:PHP framework uses mt_rand() function (Marsenne Twister) when generating tokens:LINK:https://www.cve.org/CVERecord?id=CVE-2021-3692::



Notes: ::TYPE:Maintenance:NOTE:As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, randomness is used heavily. However, within cryptography, entropy is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.::
CWE-1284: Improper Validation of Specified Quantity in Input (Base)

Description: The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties.

Extended Description: Specified quantities include size, length, frequency, price, rate, number of operations, time, and others. Code may rely on specified quantities to allocate resources, perform calculations, control iteration, etc. When the quantity is not properly validated, then attackers can specify malicious quantities to cause excessive resource allocation, trigger unexpected failures, enable buffer overflows, etc.



Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Often::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Other:IMPACT:Varies by Context:NOTE:Since quantities are used so often to affect resource allocation or process financial data, they are often present in many places in the code.::


Potential Mitigations: ::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.:EFFECTIVENESS:High::

Observed Examples: ::REFERENCE:CVE-2022-21668:DESCRIPTION:Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).:LINK:https://www.cve.org/CVERecord?id=CVE-2022-21668::REFERENCE:CVE-2008-1440:DESCRIPTION:lack of validation of length field leads to infinite loop:LINK:https://www.cve.org/CVERecord?id=CVE-2008-1440::REFERENCE:CVE-2008-2374:DESCRIPTION:lack of validation of string length fields allows memory consumption or buffer over-read:LINK:https://www.cve.org/CVERecord?id=CVE-2008-2374::



Notes: ::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::
CWE-1285: Improper Validation of Specified Index, Position, or Offset in Input (Base)

Description: The product receives input that is expected to specify an index, position, or offset into an indexable resource such as a buffer or file, but it does not validate or incorrectly validates that the specified index/position/offset has the required properties.

Extended Description: Often, indexable resources such as memory buffers or files can be accessed using a specific position, index, or offset, such as an index for an array or a position for a file. When untrusted input is not properly validated before it is used as an index, attackers could access (or attempt to access) unauthorized portions of these resources. This could be used to cause buffer overflows, excessive resource allocation, or trigger unexpected failures.



Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Often::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Other:IMPACT:Varies by Context::


Potential Mitigations: ::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.:EFFECTIVENESS:High::

Observed Examples: ::REFERENCE:CVE-2005-0369:DESCRIPTION:large ID in packet used as array index:LINK:https://www.cve.org/CVERecord?id=CVE-2005-0369::REFERENCE:CVE-2001-1009:DESCRIPTION:negative array index as argument to POP LIST command:LINK:https://www.cve.org/CVERecord?id=CVE-2001-1009::



Notes: ::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::
CWE-1286: Improper Validation of Syntactic Correctness of Input (Base)

Description: The product receives input that is expected to be well-formed - i.e., to comply with a certain syntax - but it does not validate or incorrectly validates that the input complies with the syntax.

Extended Description: Often, complex inputs are expected to follow a particular syntax, which is either assumed by the input itself, or declared within metadata such as headers. The syntax could be for data exchange formats, markup languages, or even programming languages. When untrusted input is not properly validated for the expected syntax, attackers could cause parsing failures, trigger unexpected errors, or expose latent vulnerabilities that might not be directly exploitable if the input had conformed to the syntax.



Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Often::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Other:IMPACT:Varies by Context::


Potential Mitigations: ::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.:EFFECTIVENESS:High::

Observed Examples: ::REFERENCE:CVE-2016-4029:DESCRIPTION:Chain: incorrect validation of intended decimal-based IP address format (CWE-1286) enables parsing of octal or hexadecimal formats (CWE-1389), allowing bypass of an SSRF protection mechanism (CWE-918).:LINK:https://www.cve.org/CVERecord?id=CVE-2016-4029::REFERENCE:CVE-2007-5893:DESCRIPTION:HTTP request with missing protocol version number leads to crash:LINK:https://www.cve.org/CVERecord?id=CVE-2007-5893::



Notes: ::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::
CWE-1287: Improper Validation of Specified Type of Input (Base)

Description: The product receives input that is expected to be of a certain type, but it does not validate or incorrectly validates that the input is actually of the expected type.

Extended Description: When input does not comply with the expected type, attackers could trigger unexpected errors, cause incorrect actions to take place, or exploit latent vulnerabilities that would not be possible if the input conformed with the expected type. This weakness can appear in type-unsafe programming languages, or in programming languages that support casting or conversion of an input to another type.



Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Often::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Other:IMPACT:Varies by Context::


Potential Mitigations: ::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.:EFFECTIVENESS:High::

Observed Examples: ::REFERENCE:CVE-2008-2223:DESCRIPTION:SQL injection through an ID that was supposed to be numeric.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-2223::



Notes: ::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::
CWE-1288: Improper Validation of Consistency within Input (Base)

Description: The product receives a complex input with multiple elements or fields that must be consistent with each other, but it does not validate or incorrectly validates that the input is actually consistent.

Extended Description: Some input data can be structured with multiple elements or fields that must be consistent with each other, e.g. a number-of-items field that is followed by the expected number of elements. When such complex inputs are inconsistent, attackers could trigger unexpected errors, cause incorrect actions to take place, or exploit latent vulnerabilities.



Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Often::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Other:IMPACT:Varies by Context::


Potential Mitigations: ::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.:EFFECTIVENESS:High::

Observed Examples: ::REFERENCE:CVE-2018-16733:DESCRIPTION:product does not validate that the start block appears before the end block:LINK:https://www.cve.org/CVERecord?id=CVE-2018-16733::REFERENCE:CVE-2006-3790:DESCRIPTION:size field that is inconsistent with packet size leads to buffer over-read:LINK:https://www.cve.org/CVERecord?id=CVE-2006-3790::REFERENCE:CVE-2008-4114:DESCRIPTION:system crash with offset value that is inconsistent with packet size:LINK:https://www.cve.org/CVERecord?id=CVE-2008-4114::



Notes: ::TYPE:Maintenance:NOTE:This entry is still under development and will continue to see updates and content improvements.::
CWE-1322: Use of Blocking Code in Single-threaded, Non-blocking Context (Base)

Description: The product uses a non-blocking model that relies on a single threaded process for features such as scalability, but it contains code that can block when it is invoked.

Extended Description: When an attacker can directly invoke the blocking code, or the blocking code can be affected by environmental conditions that can be influenced by an attacker, then this can lead to a denial of service by causing unexpected hang or freeze of the code. Examples of blocking code might be an expensive computation or calling blocking library calls, such as those that perform exclusive file operations or require a successful network operation. Due to limitations in multi-thread models, single-threaded models are used to overcome the resource constraints that are caused by using many threads. In such a model, all code should generally be non-blocking. If blocking code is called, then the event loop will effectively be stopped, which can be undesirable or dangerous. Such models are used in Python asyncio, Vert.x, and Node.js, or other custom event loop code.




Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Availability:IMPACT:DoS: Resource Consumption (CPU):NOTE:An unexpected call to blocking code can trigger an infinite loop, or a large loop that causes the software to pause and wait indefinitely.::


Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:Generally speaking, blocking calls should be replaced with non-blocking alternatives that can be used asynchronously. Expensive computations should be passed off to worker threads, although the correct approach depends on the framework being used.::PHASE:Implementation:DESCRIPTION:For expensive computations, consider breaking them up into multiple smaller computations. Refer to the documentation of the framework being used for guidance.::
CWE-1327: Binding to an Unrestricted IP Address (Base)

Description: The product assigns the address 0.0.0.0 for a database server, a cloud service/instance, or any computing resource that communicates remotely.

Extended Description: When a server binds to the address 0.0.0.0, it allows connections from every IP address on the local machine, effectively exposing the server to every possible network. This might be much broader access than intended by the developer or administrator, who might only be expecting the server to be reachable from a single interface/network.



Applicable Platforms: ::LANGUAGE NAME:Other:LANGUAGE PREVALENCE:Undetermined::OPERATING SYSTEM CLASS:Not OS-Specific:OPERATING SYSTEM PREVALENCE:Undetermined::ARCHITECTURE CLASS:Not Architecture-Specific:ARCHITECTURE PREVALENCE:Undetermined::TECHNOLOGY NAME:Web Server:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Client Server:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Cloud Computing:TECHNOLOGY PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:System Configuration::



Common Consequences: ::SCOPE:Availability:IMPACT:DoS: Amplification:LIKELIHOOD:High::


Potential Mitigations: ::PHASE:System Configuration:DESCRIPTION:Assign IP addresses that are not 0.0.0.0.:EFFECTIVENESS:High::PHASE:System Configuration:STRATEGY:Firewall:DESCRIPTION:Unwanted connections to the configured server may be denied through a firewall or other packet filtering measures.:EFFECTIVENESS:High::

Observed Examples: ::REFERENCE:CVE-2022-21947:DESCRIPTION:Desktop manager for Kubernetes and container management binds a service to 0.0.0.0, allowing users on the network to make requests to a dashboard API.:LINK:https://www.cve.org/CVERecord?id=CVE-2022-21947::