Summary
An enterprise and reseller organisation provisioning endpoint is reachable without normal session authentication and accepts a broadly valid signed token instead of a purpose-bound provisioning credential. An ordinary user's login token may therefore be accepted, allowing unauthorized creation of a highly privileged organisation and disclosure of an immediately usable API key.
Affected context
The issue occurs in deployments where authentication middleware is applied through an explicit controller allowlist that omits the enterprise provisioning controller. The affected routes rely only on signature validation using the instance secret, while login tokens share that secret and lack purpose, audience, or expiry constraints. This combination may allow a valid user-issued token to cross an unintended trust boundary.
Exploit preconditions
- Attack surface: Publicly reachable enterprise or reseller organisation provisioning routes
- Required access: A valid ordinary user login token, without requiring administrative privileges
- Trigger point: Submission of a provisioning request containing the signed token
- Why exploitation is possible: Route-level authentication is absent, and token validation checks signature validity without confirming intended purpose, audience, or lifetime
Why this happens
The primary flaw is missing authentication enforcement on sensitive controller routes, mapping to CWE-306: Missing Authentication for Critical Function. The design also reuses a signing secret and token format across different security purposes without claims that distinguish login tokens from provisioning credentials. This creates an authentication and authorization boundary failure, consistent with token validation weaknesses such as CWE-345 and improper trust in security-relevant data.
Potential impact
- An unauthorized user could create organisations with elevated or commercially unavailable subscription properties
- The application could create organisation-owner accounts without appropriate authorization
- An attacker could obtain API keys for newly created organisations
- The exposed API keys could enable unauthorized use of public API capabilities
- Excessive channel or resource allowances could increase operational cost or facilitate abuse
- Unbounded organisation creation could consume application or infrastructure resources
General mitigation guidance
Mitigation generally focuses on enforcing authentication and authorization at the route boundary and separating token purposes.
Common defensive patterns include:
- Apply authentication middleware by default, using explicit exclusions only for intentionally public routes
- Require an authorization decision tied to the provisioning operation and the caller's privileges
- Use purpose-bound tokens with distinct audiences, scopes, and appropriate expiration claims
- Avoid using one signing secret or token format for unrelated security functions
- Validate subscription attributes, ownership creation, and resource allowances against server-side policy rather than client-controlled values
- Apply quotas, rate limits, and bounded resource policies to provisioning operations
- Return newly issued API credentials only through controlled, authorized workflows and limit their initial privileges
How teams detect issues like this
Organizations can detect similar weaknesses through:
- Route and middleware inventory checks that identify sensitive controllers or endpoints outside default authentication coverage
- Static analysis and code review rules for authentication middleware bound only to explicit controller lists
- Tests verifying that unauthenticated and low-privilege users cannot invoke provisioning functions
- Token-validation reviews checking for purpose, audience, scope, and expiry enforcement
- Policy checks that flag shared signing secrets or token schemas across authentication and administrative workflows
- Monitoring for unusual organisation creation, lifetime-plan assignment, excessive allowances, or API-key issuance
- Automated security review tools that exercise endpoint authorization matrices in CI
