deardaniel/secdata-raw huggingface dataset:
CWE-1392: Use of Default Credentials

Description:
The product uses default credentials (such as passwords or cryptographic keys) for potentially critical functionality.

Extended Description:
It is common practice for products to be designed to use
	default keys, passwords, or other mechanisms for
	authentication.  The rationale is to simplify the
	manufacturing process or the system administrator's task of
	installation and deployment into an enterprise. However, if
	admins do not change the defaults, it is easier for attackers
	to bypass authentication quickly across multiple
	organizations.

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

Consequences:
  - Authentication: Gain Privileges or Assume Identity

Mitigations:
  - [Requirements] Prohibit use of default, hard-coded, or other values that do not vary for each installation of the product - especially for separate organizations.
  - [Architecture and Design] Force the administrator to change the credential upon installation.
  - [Installation] The product administrator could change the defaults upon installation or during operation.

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.
At least one OT product used default credentials.

Real-world examples:
  - CVE-2022-30270: Remote Terminal Unit (RTU) uses default credentials for some SSH accounts
  - CVE-2021-41192: data visualization/sharing package uses default secret keys or cookie values if they are not specified in environment variables
  - CVE-2021-38759: microcontroller board has default password, allowing admin access
  - CVE-2018-3825: cloud cluster management product has a default master encryption key
  - CVE-2010-2306: Intrusion Detection System (IDS) uses the same static, private SSL keys for multiple devices and installations, allowing decryption of SSL traffic
CWE-1393: Use of Default Password

Description:
The product uses default passwords for potentially critical functionality.

Extended Description:
It is common practice for products to be designed to use
	default passwords for authentication.  The rationale is to
	simplify the manufacturing process or the system
	administrator's task of installation and deployment into an
	enterprise. However, if admins do not change the defaults,
	then it makes it easier for attackers to quickly bypass
	authentication across multiple organizations. There are many
	lists of default passwords and default-password scanning tools
	that are easily available from the World Wide Web.

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

Consequences:
  - Authentication: Gain Privileges or Assume Identity

Mitigations:
  - [Requirements] Prohibit use of default, hard-coded, or other values that do not vary for each installation of the product - especially for separate organizations.
  - [Documentation] Ensure that product documentation clearly emphasizes the presence of default passwords and provides steps for the administrator to change them.
  - [Architecture and Design] Force the administrator to change the credential upon installation.
  - [Installation] The product administrator could change the defaults upon installation or during operation.

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 OT products used default credentials.

Real-world examples:
  - CVE-2022-30270: Remote Terminal Unit (RTU) uses default credentials for some SSH accounts
  - CVE-2022-2336: OPC Unified Architecture (OPC UA) industrial automation product has a default password
  - CVE-2021-38759: microcontroller board has default password, allowing admin access
  - CVE-2021-44480: children's smart watch has default passwords allowing attackers to send SMS commands and listen to the device's surroundings
  - CVE-2020-11624: surveillance camera has default password for the admin account
CWE-1394: Use of Default Cryptographic Key

Description:
The product uses a default cryptographic key for potentially critical functionality.

Extended Description:
It is common practice for products to be designed to use
	default keys.  The rationale is to simplify the manufacturing
	process or the system administrator's task of installation and
	deployment into an enterprise. However, if admins do not
	change the defaults, it is easier for attackers to bypass
	authentication quickly across multiple organizations.

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

Consequences:
  - Authentication: Gain Privileges or Assume Identity

Mitigations:
  - [Requirements] Prohibit use of default, hard-coded, or other values that do not vary for each installation of the product - especially for separate organizations.
  - [Architecture and Design] Force the administrator to change the credential upon installation.
  - [Installation] The product administrator could change the defaults upon installation or during operation.

Real-world examples:
  - CVE-2018-3825: cloud cluster management product has a default master encryption key
  - CVE-2016-1561: backup storage product has a default SSH public key in the authorized_keys file, allowing root access
  - CVE-2010-2306: Intrusion Detection System (IDS) uses the same static, private SSL keys for multiple devices and installations, allowing decryption of SSL traffic
CWE-1395: Dependency on Vulnerable Third-Party Component

Description:
The product has a dependency on a third-party component that contains one or more known vulnerabilities.

Extended Description:
Many products are large enough or complex enough that part of their functionality uses libraries, modules, or other intellectual property developed by third parties who are not the product creator. For example, even an entire operating system might be from a third-party supplier in some hardware products. Whether open or closed source, these components may contain publicly known vulnerabilities or hidden functionality such as malware that could be exploited by adversaries to compromise the product.

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

Consequences:
  - Confidentiality: Varies by Context

Detection methods:
  - Automated Analysis: For software, use Software Composition Analysis (SCA) tools, which automatically analyze products to identify third-party dependencies. Often, SCA tools can be used to link with known vulnerabilities 

Mitigations:
  - [Requirements] In some industries such as healthcare [REF-1320] [REF-1322] or technologies such as the cloud [REF-1321], it might be unclear about who is responsible for applying patches for third-party vulnerabilities: the vendor, the operator/customer, or a separate service. Clarifying roles and responsibilities
  - [Requirements] Require a Bill of Materials for all components and sub-components of the product. For software, require a Software Bill of Materials (SBOM) [REF-1247] [REF-1311].
  - [Architecture and Design] Maintain a Bill of Materials for all components and sub-components of the product. For software, maintain a Software Bill of Materials (SBOM). According to [REF-1247], "An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and th
  - [Operation] Actively monitor when a third-party component vendor announces vulnerability patches; fix the third-party component as soon as possible; and make it easy for operators/customers to obtain and apply the patch.

Demonstrative examples:
The "SweynTooth" vulnerabilities in Bluetooth Low Energy (BLE) software development kits (SDK) were found to affect multiple Bluetooth System-on-Chip (SoC) manufacturers. These SoCs were used by many products such as medical devices, Smart Home devices, wearables, and other IoT devices. [REF-1314] [REF-1315]

log4j, a Java-based logging framework, is used in a large number of products, with estimates in the range of 3 billion affected devices [REF-1317]. When the "log4shell" (CVE-2021-44228) vulnerability was initially announced, it was actively exploited for remote code execution, requiring urgent mitigation in many organizations. However, it was unclear how many products were affected, as Log4j would sometimes be part of a long sequence of transitive dependencies. [REF-1316]

Real-world examples:
  - CVE-2025-45612: product uses a vulnerable version of an authentication framework, allowing authentication bypass
CWE-14: Compiler Removal of Code to Clear Buffers

Description:
Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."

Extended Description:
This compiler optimization error occurs when: 
             
                Secret data are stored in memory. 
                The secret data are scrubbed from memory by overwriting its contents. 
                The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently.

Affected languages: C, C++, Compiled
Parent weaknesses: CWE-733

Consequences:
  - Confidentiality: Read Memory

Detection methods:
  - Black Box: This specific weakness is impossible to detect using black box methods. While an analyst could examine memory to see that it has not been scrubbed, an analysis of the executable would not be successfu
  - White Box: This weakness is only detectable using white box methods (see black box detection factor). Careful analysis is required to determine if the code is likely to be removed by the compiler.

Mitigations:
  - [Implementation] Store the sensitive data in a "volatile" memory location if available.
  - [Build and Compilation] If possible, configure your compiler so that it does not remove dead stores.
  - [Architecture and Design] Where possible, encrypt sensitive data that are used by a software system.

Demonstrative examples:
The following code reads a password from the
              user, uses the password to connect to a back-end
              mainframe, and then attempts to scrub the password from
              memory using memset().
The code in the example will behave
               correctly if it is executed verbatim, but if the code
               is compiled using an optimizing compiler, then the call to
               memset() might be removed as a dead store, because the
               buffer pwd is not used after its value is overwritten.
               Because the buffer pwd contains a sensitive
               value, the application may be vulnerable to attack if
               the data are left memory resident. If attackers are
               able to access the correct region of memory, they may
CWE-140: Improper Neutralization of Delimiters

Description:
The product does not neutralize or incorrectly neutralizes delimiters.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - [Implementation] Developers should anticipate that delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2003-0307: Attacker inserts field separator into input to specify admin privileges.
  - CVE-2000-0293: Multiple internal space, insufficient quoting - program does not use proper delimiter between values.
  - CVE-2001-0527: Attacker inserts carriage returns and "|" field separator characters to add new user/privileges.
  - CVE-2002-0267: Linebreak in field of PHP script allows admin privileges when written to data file.
CWE-141: Improper Neutralization of Parameter/Argument Delimiters

Description:
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as parameter or argument delimiters when they are sent to a downstream component.

Extended Description:
As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - Developers should anticipate that parameter/argument delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2003-0307: Attacker inserts field separator into input to specify admin privileges.
CWE-142: Improper Neutralization of Value Delimiters

Description:
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as value delimiters when they are sent to a downstream component.

Extended Description:
As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - Developers should anticipate that value delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2000-0293: Multiple internal space, insufficient quoting - program does not use proper delimiter between values.
CWE-1426: Improper Validation of Generative AI Output

Description:
The product invokes a generative AI/ML
			component whose behaviors and outputs cannot be directly
			controlled, but the product does not validate or
			insufficiently validates the outputs to ensure that they
			align with the intended security, content, or privacy
			policy.

Affected languages: Not Language-Specific
Affected technologies: AI/ML, Not Technology-Specific
Parent weaknesses: CWE-707

Consequences:
  - Integrity: Execute Unauthorized Code or Commands

Detection methods:
  - Dynamic Analysis with Manual Results Interpretation: Use known techniques for prompt injection
			 and other attacks, and adjust the attacks to be more
			 specific to the model or system.
  - Dynamic Analysis with Automated Results Interpretation: Use known techniques for prompt injection
			 and other attacks, and adjust the attacks to be more
			 specific to the model or system.
  - Architecture or Design Review: Review of the product design can be
			 effective, but it works best in conjunction with dynamic
			 analysis.

Mitigations:
  - [Architecture and Design] Since the output from a generative AI component (such as an LLM) cannot be trusted, ensure that it operates in an untrusted or non-privileged space.
  - [Operation] Use "semantic comparators," which are mechanisms that
					provide semantic comparison to identify objects that might appear
					different but are semantically similar.
  - [Operation] Use components that operate
					externally to the system to monitor the output and
					act as a moderator. These components are called
					different terms, such as supervisors or
					guardrails.
  - [Build and Compilation] During model training, use an appropriate variety of good
				  and bad examples to guide preferred outputs.

Real-world examples:
  - CVE-2024-3402: chain: GUI for ChatGPT API performs
					input validation but does not properly "sanitize"
					or validate model output data (CWE-1426), leading
					to XSS (CWE-79).
CWE-1428: Reliance on HTTP instead of HTTPS

Description:
The product provides or relies on use of HTTP communications when HTTPS is available.

Extended Description:
Because HTTP communications are not encrypted, HTTP is subject to various attacks against confidentiality, integrity, and authenticity. However, unlike many other protocols, HTTPS is widely available as a more secure alternative, because it uses encryption.

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

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Architecture and Design] Explicitly require HTTPS or another mechanism that ensures that communication is encrypted [REF-1464].
  - [Implementation] Avoid using "mixed content," i.e., serving a web page over HTTPS in which the page includes elements that use "http:" URLs [REF-1466] [REF-1467]. This is often done for images or other resources that do not seem to have privacy or security implications.
  - [Implementation] Perform "HTTPS forcing," that is, redirecting HTTP requests to HTTPS.
  - [Operation] If the product supports multiple protocols, ensure that encrypted protocols (such as HTTPS) are required, and remove any unencrypted protocols (such as HTTP).
CWE-143: Improper Neutralization of Record Delimiters

Description:
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as record delimiters when they are sent to a downstream component.

Extended Description:
As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - Developers should anticipate that record delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2004-1982: Carriage returns in subject field allow adding new records to data file.
  - CVE-2001-0527: Attacker inserts carriage returns and "|" field separator characters to add new user/privileges.