Summary
Postiz uses the predictable Math.random() generator to create OAuth credentials, API keys, client secrets, authorization codes, and PKCE verifiers. Because unauthenticated dynamic client registration can expose consecutive generated values, an attacker may reconstruct the generator state and derive credentials issued to other users or organizations.
Affected context
The vulnerability affects Postiz deployments where security-sensitive credentials are generated through a shared helper backed by Math.random(). Risk is increased when the OAuth dynamic client registration endpoint is publicly accessible and returns newly generated credentials, because observed output can provide information about the deterministic pseudorandom generator state.
Exploit preconditions
- Attack surface: OAuth dynamic client registration endpoint and other flows using the shared credential-generation helper
- Required access: Typically no authentication for the exposed dynamic registration endpoint
- Trigger point: Generation and disclosure of client credentials or other values derived from the same pseudorandom stream
- Why exploitation is possible: V8's deterministic
xorshift128+state can be reconstructed from sufficient consecutive outputs, allowing related past or future values to be predicted
Why this happens
The underlying bug is the use of a non-cryptographic pseudorandom number generator for secrets that require unpredictability. Math.random() is designed for general-purpose simulation and application behavior, not credential generation; its deterministic internal state can become predictable when enough output is observed. This maps primarily to CWE-330: Use of Insufficiently Random Values, with related characteristics covered by CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator and CWE-341: Predictable from Observable State.
Potential impact
- Attackers may predict OAuth client secrets, authorization codes, access tokens, API keys, or PKCE verifiers
- Unauthorized users may gain access to accounts, organizations, or connected services
- Previously issued credentials may be reconstructed if the generator state is recovered
- Future credentials generated by the shared helper may be compromised
- Attackers could impersonate clients or access organization-level resources
General mitigation guidance
Mitigation generally focuses on replacing non-cryptographic randomness wherever generated values provide authentication, authorization, or secrecy.
Common defensive patterns include:
- Use a platform-backed cryptographically secure random source for every security-sensitive value
- Separate credential-generation utilities from ordinary application randomness
- Ensure generated tokens, secrets, codes, and verifiers have sufficient entropy and appropriate lifetimes
- Avoid exposing unnecessary generated credentials through unauthenticated registration responses
- Rotate potentially exposed credentials and invalidate affected sessions or authorization artifacts
- Apply least privilege to OAuth clients, API keys, and organization integrations
- Enforce automated policies that prohibit
Math.random()and similar weak generators in security-sensitive code paths
How teams detect issues like this
Organizations can identify this weakness through:
- Static analysis rules for
Math.random()or other non-cryptographic generators used near token, secret, key, code, or verifier creation - Code review checks for shared helpers that generate both ordinary identifiers and security credentials
- Data-flow analysis tracing generated values into OAuth responses, authorization decisions, headers, or API authentication
- Tests that verify security-sensitive values originate from approved cryptographic randomness APIs
- API monitoring for unusually frequent dynamic client registrations or repeated credential-generation activity
- Policy enforcement in CI and automated code review tools that flag weak randomness in authentication and authorization components
