CVE-2017-16028

What it actually does

The affected OAuth-related token generation relies on a non-cryptographically secure pseudo-random number generator, specifically Math.random(), to create random tokens. Because Math.random() is not designed to resist prediction, an attacker who can observe or infer enough token-generation behavior may be able to reduce the search space or predict future tokens. The primary technical impact is weakened confidentiality of authentication or authorization tokens, potentially allowing token guessing or session/account access where those tokens are trusted as secrets.

Why it matters to the business

Applications that depend on these generated tokens for OAuth login or session security may expose users to unauthorized account access. The issue is not known to be listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad active exploitation is not indicated; however, the age of the vulnerability means any remaining use likely reflects unmaintained dependency risk and should be remediated as part of dependency hygiene.

How an attack unfolds

An attacker first identifies an application using the vulnerable token-generation logic for OAuth or login-related flows. The attacker then collects samples of generated tokens where possible, such as through repeated login attempts, passwordless links, OAuth redirects, invitation flows, or other token-bearing responses. Because the tokens are generated with Math.random() rather than a cryptographically secure source of randomness, the attacker may attempt to model or brute-force the token space more efficiently than would be possible with a proper cryptographic random number generator. If the application accepts a guessed or predicted token as proof of authentication or authorization, the attacker may gain access to another user’s session, OAuth flow, or protected account function. Successful exploitation depends heavily on how the consuming application uses the token, token length, token lifetime, rate limiting, logging, and whether additional validation is enforced.

How to fix it

Replace the vulnerable token-generation implementation with one that uses a cryptographically secure random number generator, such as Node.js crypto.randomBytes(), Web Crypto getRandomValues(), or a maintained library that explicitly uses CSPRNG-backed randomness. If the affected package is present only as a transitive dependency, update the top-level package that introduces it or override/replace the dependency. No fixed version was provided in the input, so teams should verify whether a maintained upstream release exists; if not, remove or fork the dependency and patch token generation directly. Rotate any secrets or long-lived tokens generated by the vulnerable implementation, invalidate outstanding OAuth/session tokens where feasible, and ensure token validation endpoints enforce short expirations, single use, sufficient token length, and rate limiting.

How to confirm the fix worked

Confirm that the vulnerable package or code path is no longer present by reviewing package manifests and lockfiles, such as package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, and bundled mobile application dependencies. Search source and built artifacts for token generation using Math.random() in authentication, OAuth, session, invitation, reset, or verification flows. Validate the replacement implementation uses a CSPRNG, and add tests or static analysis checks that fail builds when Math.random() is used to generate security-sensitive tokens. Exercise OAuth/login flows after remediation to confirm tokens remain unique, sufficiently long, expire as expected, and cannot be reused.

Typical attack path

1. Identify an application or mobile flow that uses the affected OAuth/token-generation library or vulnerable dependency.
2. Trigger workflows that generate OAuth, login, session, invitation, or verification tokens.
3. Collect observable token values from responses, redirects, logs, emails, or client-side application behavior.
4. Analyze token format, entropy, length, and generation patterns for predictability caused by Math.random().
5. Attempt token guessing or prediction against token validation endpoints.
6. Use a valid guessed token to complete an OAuth/login flow or access a protected user action.

How to detect it

Because this vulnerability is a weak-randomness design flaw rather than a payload-based exploit, there are usually no definitive file, process, or network indicators that prove exploitation. Detection should focus on authentication and application telemetry. Review OAuth callback logs, token validation endpoints, password reset or invitation redemption logs, mobile API gateway logs, WAF logs, and identity provider logs for signs of token guessing: high volumes of invalid token submissions, sequential or patterned token attempts, repeated failures followed by success, many token validation requests from the same IP or user agent, and access to accounts without the expected preceding user-driven login steps. Compare successful token redemptions against token issuance events; a successful redemption with no corresponding issuance record, from an unexpected geography, ASN, device, or user agent, should be investigated. If application logs store token prefixes or hashes, look for repeated attempts against similar token values. Also review source repositories, package lockfiles, and built mobile bundles for Math.random() usage in authentication-related token generation.

What your security team should do

• Inventory applications and mobile clients that include the affected dependency or any OAuth/login token generation based on Math.random().
• Prioritize remediation for internet-facing authentication flows, mobile login flows, password reset flows, invitation links, and any workflow where generated tokens grant account access.
• Replace vulnerable token generation with a cryptographically secure random source and redeploy affected applications.
• Invalidate or expire outstanding tokens generated by the vulnerable implementation, especially long-lived OAuth, session, invitation, verification, and password reset tokens.
• Add dependency scanning and code scanning rules that flag Math.random() usage in security-sensitive contexts.
• Review authentication logs for abnormal token validation failures, high-volume token guessing, repeated OAuth callback attempts, or unusual account access patterns.
• Ensure token endpoints have rate limiting, lockout or throttling, short token lifetimes, single-use semantics, and monitoring for brute-force behavior.