Postiz has fixed a critical token-forgery vulnerability that can turn an ordinary account into access to other users and organizations. CVE-2026-115933 affects versions 2.15.0 before 2.25.3. The October 24 vendor advisory rates it 9.9 under CVSS 3.1; the 2.25.3 release recommends immediate upgrading.

When a valid signature grants the wrong authority

The advisory describes requester-controlled claims signed through extension refresh, then accepted for other token purposes. A narrower invitation-signing route also exists.

Demonstrated impacts include cross-user sessions, password resets, organization takeover, API-key access and connected-account publishing. No in-the-wild exploitation is asserted.

Prerequisites and temporary limits

An ordinary account and Skool API reachability are prerequisites for the main route. Registration defaults open. Billing limits do not protect session/reset paths. Closing registration or blocking extension refresh only partially mitigates exposure; the invitation route remains.

Bulwark response priorities

  • Upgrade the running deployment. Deploy 2.25.3 or a newer release containing the fix, following vendor guidance. Verify the actual backend version after rollout; changing a desired image tag does not prove old instances stopped.
  • Contain unnecessary access. While patching, review whether public registration and browser-extension channels are needed. Apply only compatible temporary restrictions and record what remains exposed.
  • Review organization authority. Check unexpected members, elevated roles, invitations and API access. Reconcile connected channels and scheduled posts with an authorized owner, especially for customer-facing or government-contractor communications.
  • Plan credential and session recovery. Ask the vendor how to invalidate previously issued forged tokens after patching. Review session invalidation, signing-key rotation and API-key replacement under a coordinated recovery plan; a password change alone should not be assumed to revoke every token.
  • Preserve evidence. Retain available access, membership, password-reset and publishing records before cleanup. Treat unexpected activity as a lead requiring investigation, not proof that every connected account was compromised.

Bulwark assessment

A signed token is only trustworthy when the issuer controls its claims and the receiver checks its intended purpose. For lean teams, Postiz should be managed as a privileged publishing system: one application can control several organizations' public channels. Patch the signing flaw and separately verify that access and queued content remain authorized.

This vulnerability is distinct from the earlier Postiz provider file-read issue, CVE-2026-115931. Do not assume a fix for that separate flaw establishes remediation of this one.

Original sources

Postiz vendor advisory PSA-2026-YT2HMH; Postiz CNA record; Postiz 2.25.3 release.