A GitHub repository with 57,000 stars uses Math.random() to generate API keys. The problem is predictable: Math.random() is a pseudorandom number generator, not a cryptographically secure one. An attacker who observes roughly 20 API tokens can reconstruct the internal state of the generator and predict every future token. The fix is a single line of code - crypto.randomBytes() - but the vulnerability is already out there, copied and deployed across thousands of projects.
The developer who found this ran an ESLint rule that flags Math.random() in security-sensitive contexts. The rule caught it immediately. The question is why a repository with that many stars - meaning thousands of developers have read and used the code - never caught it before. The answer is that code review doesn't scale, and most developers trust popular repositories without auditing them line by line.
Why Math.random() Breaks Security
Math.random() uses a linear congruential generator or similar algorithm under the hood. These are deterministic: given the internal state, you can predict all future outputs. The state is typically a 32-bit or 64-bit integer, which means the entire keyspace is small enough to brute-force if you have enough observations.
Here's how the attack works. An attacker requests API keys from the service until they have a sample set - 20 tokens is usually enough. They then reverse-engineer the state of Math.random() by testing which initial seed would produce that sequence. Once they have the seed, they can generate every token the server will issue in the future, including tokens for other users.
This isn't theoretical. The maths is straightforward, and the tools exist. A motivated attacker with access to a few tokens can compromise the entire key generation system in minutes. The attack surface is any application that generates secrets using Math.random(), which includes API keys, session tokens, password reset codes, and OAuth state parameters.
The Correct Fix
Use crypto.randomBytes() in Node.js or the equivalent in other languages: crypto.getRandomValues() in browsers, secrets module in Python, SecureRandom in Java. These are cryptographically secure pseudorandom number generators (CSPRNGs), which are designed to be unpredictable even if an attacker knows part of the output.
The code change is minimal. Instead of Math.random().toString(36), you use crypto.randomBytes(16).toString('hex'). Same number of lines, negligible performance difference, but the security properties are fundamentally different. One is predictable; the other is not.
The ESLint rule that caught this is no-insecure-random, part of the eslint-plugin-security package. It flags Math.random() in any context where it might be used for security purposes. Adding the plugin to your linting pipeline takes five minutes and catches an entire class of vulnerabilities automatically. The rule isn't perfect - it can't know for certain whether a given Math.random() call is security-critical - but it catches obvious cases and prompts developers to think twice.
Why This Keeps Happening
Developers reach for Math.random() because it's built-in, well-known, and seems to do the job. If you're generating a random colour for a UI element or shuffling a deck of cards in a game, Math.random() is fine. The problem is that the same function gets copied into security-critical code paths without anyone stopping to ask whether it's appropriate.
Popular repositories amplify the problem. When a high-star repo uses Math.random() for token generation, thousands of developers see that code and assume it's correct. They copy it into their own projects, and the vulnerability spreads. Code review might catch it in a security-focused team, but most teams don't have dedicated security reviewers, and Math.random() doesn't look obviously wrong to someone who isn't thinking about cryptographic guarantees.
The other issue is documentation. The MDN page for Math.random() includes a warning that it's not cryptographically secure, but warnings are easy to miss. The function doesn't throw an error or log a warning when used in a security context - it just quietly produces predictable output. A better API design would make the unsafe behaviour harder to stumble into, but changing core language features is difficult once they're widely deployed.
What to Do If You're Using This Code
First, audit your codebase for Math.random() calls. Grep for it, or add the ESLint rule and let automation find it for you. For every instance, ask whether the output is security-sensitive. If it's generating tokens, keys, salts, nonces, or anything that an attacker could exploit if predicted, replace it with a CSPRNG.
Second, rotate any secrets that might have been generated using Math.random(). API keys, session tokens, password reset codes - if they were created with a predictable generator, assume they're compromised. Regenerate them using a secure method and invalidate the old ones. This is disruptive, but less disruptive than an attacker predicting your tokens and accessing user accounts.
Third, add linting rules to catch this in future. The eslint-plugin-security package includes several rules that flag common security mistakes, not just Math.random(). It won't catch everything, but it raises the baseline and makes it harder to introduce obvious vulnerabilities through copy-paste errors.
The Bigger Lesson
High star counts don't guarantee security. A repository can be popular, widely used, and actively maintained, and still contain critical vulnerabilities. The responsibility for security doesn't stop at the library boundary - if you're using third-party code in a security-critical context, you need to audit it or accept the risk.
The good news is that many of these issues are automatable. Linters, static analysis tools, and dependency scanners can catch low-hanging fruit like Math.random() in token generation. They won't find everything, but they catch the mistakes that are easy to miss in code review and expensive to fix after deployment.
For this specific case, the fix is trivial. One line of code, no performance impact, no API changes. The hard part is finding all the places where the mistake was made and deployed. That's the real cost of insecure defaults - not the fix itself, but the scale of the cleanup.