POSTIZ / CVE-2026-115933 / AUTHORITY MAP
A genuine signature grants the wrong purpose
The user controls claims; Postiz signs them. The user does not possess its signing secret.
Prerequisite: registered account Dashed boundary = missing purpose marker
01 / INPUT
A user supplies token claims
Route
Channel credential refreshThe request contains claims chosen by that user.
What mattersA separate team-invite route is narrower.
User claims via channel refresh. Team invite also signs fields.
02 / SIGNER
Postiz signs and stores a token
Service behaviour
Signed with a shared secretThe user can read the stored token back.
What mattersSession, invite and reset tokens share the key.
Postiz signs and stores token. Session, invite, reset share key.
03 / BOUNDARY
The token has no purpose marker
Validation gap
Signature ≠ intended useOther flows check a valid signature.
What mattersIt does not identify the issuing purpose.
Valid signature. No issuing-purpose marker.
04 / ACCEPTANCE
Other workflows accept the claims
Vendor-described uses
Session · invite · resetEnterprise provisioning is also listed.
What mattersThe flaw can cross user and organisation boundaries.
Session, invite, reset and enterprise flows accept claims.
BROKEN BOUNDARY: a valid signature is accepted across token purposes.
Controlled result
In the vendor test, a second account became another organisation's super administrator and read its API key.
In the vendor test, a second account became another organisation's super administrator and read its API key.
Evidence limit
Controlled validation is not evidence of a customer incident.
Controlled validation is not evidence of a customer incident.