CVE-2026-115933 in postiz-app
Summary
by MITRE • 10/24/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/24/2026
The vulnerability described constitutes a critical authentication and authorization flaw rooted in improper cryptographic implementation within the Postiz application. At its core, the issue stems from the use of a single shared secret to sign multiple distinct types of tokens, including session identifiers, organization invitations, password reset links, and enterprise provisioning data. This design violates fundamental security principles regarding token separation and context binding. By relying on one universal signing key without implementing any mechanism to distinguish between token types, such as embedding specific type markers or using separate keys for different purposes, the application creates a scenario where cryptographic validity is decoupled from semantic intent. An attacker can exploit this lack of differentiation by crafting tokens with arbitrary claims that are mathematically valid according to the signature verification process but semantically invalid within the business logic context.
The operational impact of this flaw is severe because it allows for complete authentication bypass and privilege escalation through token forgery. The vulnerability is exacerbated by a specific route designed to refresh credentials for browser-extension channels, which accepts signed data directly from the request body and stores the resulting refreshed tokens in a location accessible to the requesting user. This creates a direct vector for abuse where an authenticated or potentially unauthenticated actor can manipulate input parameters to generate new tokens with elevated privileges. Since the application does not validate that the claims within these newly generated tokens align with legitimate session states or intended roles, an attacker can simply inject custom payloads into this endpoint. The system will sign these malicious inputs and store them in a readable location, effectively handing over valid administrative credentials, unlimited invitation capabilities, or password reset access to the adversary without requiring knowledge of the underlying secret key.
This flaw maps directly to CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity as defined by industry standards. The failure to bind token types to their respective cryptographic contexts aligns with ATT&CK technique T1078 Valid Accounts, specifically the aspect of account manipulation or impersonation through credential theft or forgery. Furthermore, the ability to generate organization invitations with chosen roles represents a significant authorization bypass, falling under CWE-269 Improper Privilege Management. The narrow route for team invitations further extends this risk by allowing attackers to sign extra fields from the request body in the same manner, thereby enabling the creation of fraudulent membership requests that grant unauthorized access to organizational resources.
Mitigation strategies must focus on strict separation of concerns and robust cryptographic practices. First, distinct signing keys should be implemented for each token type, ensuring that a key used for session management cannot be repurposed to generate invitations or reset tokens. Second, every signed payload must include explicit metadata fields indicating its intended purpose, which the application must verify before accepting any action based on those claims. This prevents cross-protocol attacks where one token format is misinterpreted as another. Additionally, input validation should be enforced at all entry points, particularly for endpoints that handle credential refreshing or invitation generation, ensuring that only expected and authorized fields are processed. Implementing these controls will restore the integrity of the authentication flow and prevent attackers from forging valid tokens to compromise system security.