Summary
CVE-2026-94456 is a critical (CVSS 9.1) weakness in Postiz, an open-source social media scheduling and management platform, in which security-sensitive credentials are generated using Math.random() instead of a cryptographically secure random source. Because OAuth access tokens, authorization codes, client secrets, organization API keys, and PKCE verifiers are all produced by the same insecure generator, an attacker who can observe enough of its output can reconstruct the underlying PRNG state and predict other credentials it produces.
Technical details
- Root cause: Postiz relies on JavaScript’s non-cryptographic
Math.random()(V8’s deterministic xorshift128+ PRNG) to generate OAuth access tokens, authorization codes, client secrets, organization API keys, and PKCE verifiers. - Trigger condition: An unauthenticated OAuth dynamic client registration endpoint returns freshly generated client credentials to any caller, giving an attacker a stream of consecutive PRNG outputs.
- Attack vector: Network-based, no authentication or user interaction required (AV:N/AC:L/PR:N/UI:N). By collecting outputs from the exposed endpoint, an attacker can mathematically recover the PRNG’s internal state.
- Impact: Once the PRNG state is recovered, an attacker can deterministically derive past and future credential values generated by the same instance — enabling prediction/forgery of OAuth access tokens, authorization codes, client secrets, API keys, and PKCE verifiers belonging to other users and organizations, potentially leading to account and organization takeover. The vulnerability affects confidentiality and integrity but not availability.
Affected software
- GitroomHQ Postiz (
postiz-app): all versions prior to 2.24.0 (releases from 2.4.0 through 2.23.0 are confirmed affected).
Severity
- CVSS v3.1 Base Score: 9.1 (Critical)
- Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Mitigation and recommended actions
- Immediate: Upgrade Postiz to version 2.24.0 or later, which addresses this issue.
- If immediate patching is not possible:
- Restrict or disable public access to the OAuth dynamic client registration endpoint at the network or reverse-proxy layer until the upgrade can be applied.
- Rotate all existing OAuth tokens, authorization codes, client secrets, API keys, and PKCE verifiers after upgrading, since values generated prior to the patch may have been predictable.
- Monitor for anomalous OAuth client registrations or token usage originating from unexpected sources.

