CVE-2026-115933: Forged signed tokens let any registered user take over other users and organizations
Postiz signs its session, invitation and password reset tokens with one shared secret and without any marker of what a token is for. A route that refreshes the credentials of a browser-extension channel signed data taken from the request itself and stored the result where the requesting user can read it back. A user could therefore obtain a validly signed token containing any claims they choose, which the application accepts as a session, as an organization invitation with a chosen role, as a password reset or as an enterprise provisioning token.
A second, narrower route that creates team invitations signs extra fields from the request body in the same way.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
Any registered Postiz user can exploit it. The attacker does not need interaction from another user and can forge claims that the application accepts for other users or organizations.
What access could an attacker gain?
A forged token can be accepted as a session token, an organization invitation with an attacker-chosen role, a password-reset token, or an enterprise provisioning token. This can enable takeover of other users and organizations.
Are default deployments affected?
The issue is in the shared signing design and in routes that sign request-supplied data; the provided information does not identify a configuration prerequisite. A deployment with registered users should be treated as exposed unless it has the referenced fix.
How can I tell whether exploitation may have occurred?
Review authentication, password-reset, invitation, organization-membership, and enterprise-provisioning activity for unexpected tokens, resets, invitations, role assignments, or account access. The provided information does not specify token formats or log indicators that would uniquely identify forged tokens.
What can be done if patching cannot happen immediately?
The provided information does not document a workaround. Restricting access by untrusted registered users and closely reviewing privileged account, invitation, and organization changes may reduce exposure while the referenced fix is deployed.