CVE-2026-94456 in postiz-app
Summary
by MITRE • 09/22/2026
Postiz generates security-sensitive credentials using `Math.random()` instead of a cryptographically secure source. The same helper is used for OAuth access tokens, authorization codes, client secrets, organization API keys, and PKCE verifiers, meaning these credentials depend entirely on V8’s deterministic xorshift128+ PRNG state.
An unauthenticated OAuth dynamic client registration endpoint exposes freshly generated client credentials, giving attackers enough consecutive PRNG output to reconstruct that internal state. Once recovered, they can deterministically derive past and future values produced by the same generator, potentially compromising credentials belonging to other users and organizations.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in Postiz represents a critical failure in cryptographic key management due to the misuse of pseudo-random number generators for security-sensitive operations. The core technical flaw lies in the application's reliance on JavaScript's native Math.random() function, which is designed primarily for general-purpose randomness such as simulations or games, rather than for generating secrets that require unpredictability and resistance to prediction. This implementation detail affects multiple critical authentication mechanisms within the system, including OAuth access tokens, authorization codes, client secrets, organization API keys, and PKCE verifiers. Because Math.random() in V8 engines utilizes a deterministic xorshift128+ algorithm, its output is entirely dependent on an internal seed state that can be mathematically reconstructed if sufficient consecutive outputs are observed by an adversary.
The operational impact of this flaw is severe because it undermines the fundamental assumption of secrecy for all credentials generated through these pathways. An attacker does not need to exploit a complex injection or buffer overflow; instead, they only require access to an unauthenticated OAuth dynamic client registration endpoint that exposes freshly generated client credentials in plaintext. By capturing multiple consecutive instances of these exposed secrets, which are direct outputs from the PRNG, an adversary can perform statistical analysis and reverse-engineering techniques to deduce the internal state of the xorshift128+ generator. Once this internal state is recovered, it becomes possible to deterministically calculate both past and future values produced by that specific instance of the random number generator. This capability allows for the reconstruction of valid authentication tokens and API keys belonging not only to the attacker but potentially to other users and organizations sharing the same server-side PRNG context or seed initialization logic.
This vulnerability aligns with CWE-330, which classifies the use of insufficiently random values in security contexts, as well as CWE-798, involving the use of hardcoded default credentials when those defaults are derived from predictable sources rather than truly unique secrets. From a threat modeling perspective using the MITRE ATT&CK framework, this scenario facilitates Credential Access through techniques such as Valid Accounts and potentially Account Manipulation if an attacker uses reconstructed tokens to maintain persistent access without detection. The predictability of the cryptographic material effectively nullifies any security controls relying on token secrecy, including OAuth flows that depend on PKCE for public clients or API keys used for service-to-service authentication.
Mitigation strategies must prioritize immediate remediation at both the code and infrastructure levels. Developers should replace all instances of Math.random() with a cryptographically secure pseudo-random number generator (CSPRNG) provided by the operating system or language runtime, such as crypto.getRandomValues in JavaScript environments or equivalent APIs like os.urandom in Python or SecureRandom in Java. It is imperative to audit the entire codebase for any other uses of non-cryptographic randomness that might impact security boundaries. Furthermore, existing credentials generated with Math.random() must be considered compromised and rotated immediately across all affected systems. To prevent future occurrences, static analysis tools should be configured to flag calls to known insecure random number generation functions during the software development lifecycle. Additionally, implementing strict rate limiting on registration endpoints can reduce the window of opportunity for attackers to gather sufficient samples needed to reconstruct the PRNG state, although this is a secondary control that does not replace the need for proper cryptographic randomness.