Threadlinqs IntelligenceStart free

Weakness · ClassCWE-330

CWE-330: Use of Insufficiently Random Values

Likelihood of exploit: HighClass

As of 2026-11-04, CWE-330 (Use of Insufficiently Random Values) underlies 3 CVEs tracked by Threadlinqs, none of them in the CISA Known Exploited Vulnerabilities catalog, and is cited by 22 tracked threats. MITRE rates its likelihood of exploit as High.

CVEs
3Mapped to CWE-330
CISA KEV
0None listed yet
Critical
1CVSS v3 critical CVEs
Threats
22Tracked campaigns citing it
Likelihood
HighMITRE likelihood of exploit

Last updated:

What is CWE-330?

The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.

CWE-330 is a class-level weakness in MITRE’s Common Weakness Enumeration, with a MITRE likelihood of exploit of High. Applicable platforms: Language: Not Language-Specific; Technology: Not Technology-Specific.

Source: MITRE CWE (CWE-330 definition, reproduced verbatim). Counts and linkage below are Threadlinqs data.

Consequences

  • Confidentiality, Other — Other. When a protection mechanism relies on random values to restrict access to a sensitive resource, such as a session ID or a seed for generating a cryptographic key, then the resource being protected could be accessed by guessing the ID or key.
  • Access Control, Other — Bypass Protection Mechanism, Other. If product relies on unique, unguessable IDs to identify a resource, an attacker might be able to guess an ID for a resource that is owned by another user. The attacker could then read the resource, or pre-create a resource with the same ID to prevent the legitimate program from properly sending the resource to the intended user. For example, a product might maintain session information in a file whose name is based on a username. An attacker could pre-create this file for a victim user, then…
  • Access Control — Bypass Protection Mechanism, Gain Privileges or Assume Identity. When an authorization or authentication mechanism relies on random values to restrict access to restricted functionality, such as a session ID or a seed for generating a cryptographic key, then an attacker may access the restricted functionality by guessing the ID or key.

Source: MITRE CWE, common consequences.

How CWE-330 is exploited in the wild

Threadlinqs maps 3 CVEs to CWE-330, published between 2026-06-23 and 2026-10-23. None of them is in the CISA KEV catalog yet. By CVSS v3 severity the set splits into 1 critical, 1 high, 1 medium. The highest EPSS score in the set is 1.9% (CVE-2026-11374), the modelled probability of exploitation in the next 30 days. 22 tracked threats reference CWE-330 directly or through a CVE it covers; the most recent is “Node.js October 2026 Security Releases Fix 10 Vulnerabilities Including Brotli Decoder RCE and TLS Hostname Verification Bypasses (CVE-2026-111497, CVE-2026-105483, CVE-2026-106069, CVE-2026-105482)” (2026-10-21). Affected products concentrate in Dell (1), nodejs (1), zohocorp (1).

Vulnerabilities (CVEs)

All 3 CVEs mapped to CWE-330, CISA KEV first, then by CVSS score.

Affected vendors

Threat activity

22 tracked threats cite CWE-330:

Mitigations

  • Architecture and Design: Use a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations with adequate length seeds. In general, if a pseudo-random number generator is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts. Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 256-bit seed is a good starting point for producing a "random enough" number.
  • Implementation: Consider a PRNG that re-seeds itself as needed from high quality pseudo-random output sources, such as hardware devices.
  • Testing: Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.
  • Architecture and Design, Requirements / Libraries or Frameworks: Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").
  • Testing: Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Source: MITRE CWE, potential mitigations.

Detection methods (MITRE CWE)

  • Black Box: Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon…
  • Automated Static Analysis - Binary or Bytecode (effectiveness: SOAR Partial): According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis
  • Manual Static Analysis - Binary or Bytecode (effectiveness: SOAR Partial): According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
  • Dynamic Analysis with Manual Results Interpretation (effectiveness: SOAR Partial): According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Man-in-the-middle attack tool
  • Manual Static Analysis - Source Code (effectiveness: High): According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections)
  • Automated Static Analysis - Source Code (effectiveness: SOAR Partial): According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer
  • Architecture or Design Review (effectiveness: High): According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Source: MITRE CWE, detection methods. Threadlinqs detection rules for the threats above are Blue tier and higher.