CVE-2026-94455 in postiz-app
Summary
by MITRE • 09/22/2026
An HTTP endpoint intended for provisioning enterprise and reseller organisations is reachable without any session. The authentication middleware is bound only to an explicit list of controllers, and the enterprise controller is not on that list, so no authentication runs for these routes.
The endpoint's only check is that the request body carries a token bearing a valid signature from the instance secret. It does not check what that token was issued for. Login tokens are signed with the same secret and carry no purpose, audience or expiry claim, so an ordinary user's own session token satisfies the check.
Presented with such a token, the endpoint creates a new organisation holding the highest subscription tier, flagged as lifetime and with a channel allowance far above any sold plan, creates an organisation-owner account alongside it, and returns the new organisation's API key in the response body. That key is immediately valid against the public API.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability described constitutes a critical authentication bypass combined with insecure direct object references and improper access control mechanisms within an enterprise provisioning system. The core technical flaw stems from a misconfiguration of the application’s middleware stack, where authentication requirements are explicitly bound to specific controllers but inadvertently omitted for the endpoint responsible for creating new organizations. This architectural oversight allows unauthenticated actors to interact directly with sensitive administrative functions without presenting valid session credentials or passing through standard identity verification processes. By relying solely on the presence of a signed token in the request body rather than enforcing strict authentication protocols, the system fails to verify the requester’s identity or authorization level, effectively treating any cryptographically valid signature as sufficient proof of privilege.
The severity of this flaw is significantly amplified by weaknesses in how security tokens are implemented and validated within the application logic. The provisioning endpoint performs a superficial check that validates the digital signature of the provided token against an instance secret but completely neglects to inspect standard JWT claims such as audience, purpose, or expiration time. Because login session tokens for ordinary users share the same signing secret and lack restrictive metadata like specific audiences or short lifespans, any valid user’s existing session token can be repurposed to exploit this endpoint. This design violates fundamental principles of secure token usage where tokens should be scoped narrowly to their intended function and context, preventing replay attacks and privilege escalation through credential reuse across different functional boundaries within the application.
The operational impact of exploiting this vulnerability is severe, resulting in full administrative takeover capabilities for any authenticated user with minimal effort. An attacker can submit a standard session token to the provisioning endpoint, triggering the automatic creation of a new organization configured with the highest possible subscription tier and lifetime validity. This action also generates an associated owner account equipped with API keys that possess unrestricted access privileges. These newly generated credentials are immediately active against the public-facing application programming interface, allowing the attacker to operate as a super-administrator within their own isolated tenant environment while potentially leveraging cross-tenant vulnerabilities or data isolation flaws if they exist. The ability to generate unlimited high-tier accounts can also lead to significant financial loss through resource exhaustion and billing fraud, alongside potential denial of service conditions due to excessive consumption of system resources such as database storage and computational power during the provisioning process.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, specifically regarding the failure to verify identity before granting access to sensitive functions, and CWE-862 Missing Authorization, where the application fails to ensure that users are authorized for the requested action despite being authenticated elsewhere in the system. In terms of offensive security frameworks, this behavior maps directly to MITRE ATT&CK technique T1078 Valid Accounts, as attackers leverage legitimate user credentials to gain unauthorized access, and potentially T1496 Resource Hijacking if the created organizations are used for malicious resource consumption or cryptomining activities that incur costs on behalf of the service provider. The lack of input validation regarding token claims also reflects CWE-20 Improper Input Validation, as the system accepts tokens without verifying their intended scope or validity period relative to the current operation.
Mitigation strategies must address both the architectural misconfiguration and the cryptographic implementation flaws immediately. First, authentication middleware should be applied globally or explicitly included for all administrative and provisioning endpoints to ensure that every request undergoes rigorous identity verification before processing. Second, token validation logic must be hardened to enforce strict claim checks; specifically, tokens used for organization provisioning should require specific audience identifiers, purpose claims indicating their intended use case, and short expiration times to prevent reuse of stale or misused session tokens. Implementing role-based access control ensures that only users with explicit administrative privileges can trigger organizational creation workflows. Additionally, introducing rate limiting on the provisioning endpoint can mitigate abuse attempts by restricting the number of new organizations a single account can create within a given timeframe. Finally, conducting a comprehensive audit of all middleware bindings and token validation routines across the application is essential to identify similar gaps in other sensitive areas where authentication might be inadvertently bypassed due to inconsistent security policy enforcement.