Automated Vulnerability Discovery and the Weak-PRNG Risk Class

The weak-PRNG risk class (CWE-338)

Every programming runtime ships a fast, general-purpose random number generator for everyday work: shuffling a list, jittering a retry, picking a sample. In the V8 engine that powers Node.js, that generator is Math.random(), implemented with an algorithm called xorshift128+ [SecurityWeek]. It is excellent at being fast and statistically uniform. It is not designed to be unpredictable to an adversary, and that is the whole point of the risk class.

CWE-338 describes exactly this: using a cryptographically weak PRNG where security depends on the output being unguessable [NVD / NIST]. The danger is not that the numbers "look random", they do. The danger is that a general-purpose PRNG is built to be reproducible and analysable, which is the opposite of what a secret needs to be. When such output is used, directly or indirectly, to produce session tokens, signing keys, password-reset tokens, API keys or nonces, the security of the whole system rests on a value an attacker can anticipate.

Where it went wrong in HFS

In CVE-2026-61500, the signing material behind HFS's session cookies traced back to Math.random() rather than a cryptographically secure source [SecurityWeek]. Once signing material is predictable, the attacker does not need a password: they can produce a cookie the server will accept as a legitimate administrator, and administrative access to HFS leads on to code execution [Horizon3.ai]. The chain is shown in the attack-chain diagram above, at a conceptual level, with the defensive control that breaks each link.

How to find this pattern in your own code and dependencies

• Grep for the smell. In JavaScript/TypeScript, searches for Math.random() near words like token, secret, key, session, nonce, password or reset are high-value. The equivalents in other ecosystems are java.util.Random, C's rand(), Python's random module and PHP's rand()/mt_rand().
• Prefer the CSPRNG. The fix is to generate secrets from a cryptographically secure generator: crypto.randomBytes() or the Web Crypto API in Node, secrets in Python, java.security.SecureRandom in Java, random_bytes() in PHP.
• Use static analysis. Most SAST tools and linters have a rule for insecure randomness (CWE-338); turn it on and treat it as a blocker in CI, not a warning.
• Check your dependencies, not just your code. The weak value is often several layers down in a library. This is where a bill of materials earns its keep, see the remediation view.

This section describes a general weakness class and how to remediate it. It is not a guide to attacking any specific system.

AI-assisted discovery and what it changes for defenders

CVE-2026-61500 was surfaced by Anthropic's Mythos model under Project Glasswing, a programme Anthropic launched in April 2026 to apply the model to critical open-source software, reportedly finding a large number of flaws across widely used projects [Anthropic]. Horizon3.ai's researchers took the finding through validation and coordinated disclosure [Horizon3.ai]. Reporting on the case highlighted that the discovery leaned on the kind of mathematical reasoning that makes weak-randomness bugs hard for humans to spot by eye [The Register].

For a defender, the model that found the bug matters less than the operational shift it represents:

The same class of programme that found this bug, AI reasoning over code at scale, is also what makes a continuously maintained, queryable inventory of your software components valuable: when the next finding lands, the question "where do we run this?" needs an answer in minutes, not weeks.

Remediation and defensive checklist

If you run Rejetto HFS

• Upgrade to HFS 3.2.1 or later [Rejetto]. This is the vendor fix and the primary action.
• Treat any 3.0.0 to 3.2.0 instance exposed before upgrade as suspect. Rotate credentials and secrets, review admin activity and configuration changes, and check for unexpected scheduled tasks or outbound connections.
• Reduce exposure. Put the server behind authentication and, where possible, off the public internet; restrict the admin interface by source IP.
• Watch for the behaviour, not just the version. Alert on administrator sessions that never performed a login, and on admin access from new networks or geographies, the reported activity came from China Telecom IP space against US and Japan targets [VulnCheck].

For the weak-PRNG class generally

• Enable and enforce the insecure-randomness (CWE-338) rule in your SAST/linters.
• Audit your own code for general-purpose PRNGs used to generate secrets, and replace them with a CSPRNG.
• Prefer well-reviewed framework primitives for session management over hand-rolled signing.

The SBOM and governance angle

This is where continuous bill-of-materials governance pays off, and why IntelliXBOM is publishing the analysis. When a finding like CVE-2026-61500 lands:

• A current SBOM answers "do we run this component, and at what version?" across the estate in minutes, which is the difference between patching inside the one-day window and missing it.
• Correlating the SBOM with vulnerability feeds turns a new CVE into a specific, ranked worklist of affected systems rather than an all-hands scramble.
• Recording the upgrade as timestamped evidence demonstrates, to auditors and regulators, that the exposure window was closed and when.

IntelliXBOM helps organisations generate and validate SBOMs, correlate components with vulnerabilities and known-exploited lists, and produce that evidence. It does not certify compliance; it maps inventory to the controls and frameworks you report against.

This summarises public guidance and is not legal advice. Always follow the vendor advisory and your own change-management process.