Summary
A horizontal privilege escalation issue in @better-auth/stripe allows authenticated users who belong to multiple organizations to manage subscriptions for organizations they should not control.
The flaw arises when the middleware authorizes one organization identifier while the handler uses another, enabling unauthorized access to billing details and subscription actions under specific multi-tenant conditions.
Affected context
This vulnerability affects multi-tenant applications using @better-auth/stripe where users can belong to more than one organization.
It manifests in organization-level subscription and billing operations that rely on both query parameters and request bodies to identify the organization.
The issue appears when the middleware validates an organization ID from the query string, while the downstream handler resolves the organization from the request body or falls back to the active organization stored in the session.
In such setups, mismatches between these sources can lead to actions being applied to an unintended organization that the user is not permitted to manage.
Exploit preconditions
- Attack surface: Organization subscription and billing endpoints exposed via @better-auth/stripe.
- Required access: Valid authenticated account that is a member of multiple organizations within the same application.
- Trigger point: Invocation of subscription-related routes (e.g., cancel, change plan, restore, billing portal) where:
- The middleware authorizes an organization ID from the query string, and
- The handler uses an organization ID from the request body or defaults to the user's active session organization.
- Why exploitation is possible: Authorization and enforcement are performed against inconsistent organization identifiers, allowing a user to have one organization authorized while actions are actually performed against another organization they should not manage.
Why this happens
The root cause is an inconsistent use of identifiers in the authorization flow, corresponding to CWE-639: Authorization Bypass Through User-Controlled Key.
The middleware validates the organization based on a query-string parameter, but the business logic in the handler reads the organization from the request body or falls back to the user's active session organization.
This split trust model means the authorization decision is made on one resource identifier, while the actual operation is carried out on another, effectively bypassing intended access checks in multi-tenant contexts.
Conceptually, this reflects a design flaw where user-controlled or ambiguous resource keys are not normalized and bound consistently across authentication, authorization, and handler layers.
Potential impact
- An authenticated user may manage subscriptions (cancel, change plan, restore) for another organization they belong to but should not administer.
- Attackers could gain access to another organization's billing details, including payment methods, invoices, and subscription status.
- Misconfiguration of billing for affected organizations, potentially leading to unwanted downgrades, upgrades, or cancellations.
- Exposure of sensitive financial and subscription metadata to unauthorized organizational members.
General mitigation guidance
Effective mitigation centers on enforcing a single, trustworthy source of truth for organization identifiers throughout the request lifecycle.
Common defensive patterns include:
- Resolving the organization identifier once (e.g., from session or a canonical route parameter) and reusing that value consistently in middleware and handlers.
- Avoiding mixing organization IDs from query parameters, request bodies, and sessions without strict normalization and validation.
- Binding the authorization check directly to the resource being acted upon, ensuring that the same key is used for both access control and business logic.
- Restricting who can perform subscription and billing actions through clearly defined roles and tenancy-aware permission checks.
- Minimizing reliance on client-supplied identifiers for sensitive operations, favoring server-derived or server-validated references.
How teams detect issues like this
Organizations can detect similar issues by focusing on authorization flows and multi-tenant boundaries:
- Static analysis and code scanning: Look for handlers where resource identifiers (such as organization IDs) are derived from different sources (query, body, session) than those used in authorization middleware.
- Code review practices: Review multi-tenant endpoints to ensure that the same identifier is propagated from authentication through authorization to business logic, and that role checks align with organizational permissions.
- Audit logging: Implement detailed logs capturing which user performed which operation on which organization, using a single canonical organization identifier to spot anomalies and cross-organization access.
- Policy enforcement: Integrate automated checks or linters in CI pipelines that flag patterns where critical operations depend on user-controlled IDs without consistent normalization.
