Summary
Flowise billing endpoints before 3.1.3 accept attacker-controlled Stripe subscription identifiers without confirming that they belong to the authenticated user's organization. An authenticated attacker may use this flaw to alter another tenant's subscription plan or seat quantity, potentially causing financial loss or service disruption.
Flowise billing endpoints before 3.1.3 accept attacker-controlled Stripe subscription identifiers without confirming that they belong to the authenticated user's organization. An authenticated attacker may use this flaw to alter another tenant's subscription plan or seat quantity, potentially causing financial loss or service disruption.
Affected context
The issue occurs in Flowise enterprise organization billing functionality where Stripe subscription identifiers are supplied by clients and used for subscription operations. Risk is present when the server authenticates the user but does not also verify that the referenced subscription is associated with the user's organization or authorized billing account.
The issue occurs in Flowise enterprise organization billing functionality where Stripe subscription identifiers are supplied by clients and used for subscription operations. Risk is present when the server authenticates the user but does not also verify that the referenced subscription is associated with the user's organization or authorized billing account.
Exploit preconditions
- Attack surface: Enterprise organization billing endpoints
- Required access: An authenticated Flowise account with access to the relevant billing functionality
- Trigger point: A request that supplies a Stripe subscription identifier to a plan or seat-management operation
- Why exploitation is possible: The server accepts the object identifier without enforcing ownership or tenant authorization, allowing a valid user context to reference another organization's subscription
- Attack surface: Enterprise organization billing endpoints
- Required access: An authenticated Flowise account with access to the relevant billing functionality
- Trigger point: A request that supplies a Stripe subscription identifier to a plan or seat-management operation
- Why exploitation is possible: The server accepts the object identifier without enforcing ownership or tenant authorization, allowing a valid user context to reference another organization's subscription
Why this happens
The underlying bug is an object-level authorization failure. Although the request is associated with an authenticated user, the application does not establish that the supplied Stripe subscription identifier belongs to that user's organization before performing the requested operation. This maps primarily to CWE-639: Authorization Bypass Through User-Controlled Key, with a broader relationship to CWE-284: Improper Access Control.
The underlying bug is an object-level authorization failure. Although the request is associated with an authenticated user, the application does not establish that the supplied Stripe subscription identifier belongs to that user's organization before performing the requested operation. This maps primarily to CWE-639: Authorization Bypass Through User-Controlled Key, with a broader relationship to CWE-284: Improper Access Control.
Potential impact
- An attacker may change another organization's subscription plan
- An attacker may modify another tenant's seat quantity
- Organizations could incur unauthorized charges or billing changes
- Customer access or service availability could be disrupted
- Cross-tenant trust boundaries could be weakened
- An attacker may change another organization's subscription plan
- An attacker may modify another tenant's seat quantity
- Organizations could incur unauthorized charges or billing changes
- Customer access or service availability could be disrupted
- Cross-tenant trust boundaries could be weakened
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the object and tenant boundaries for every billing operation.
Common defensive patterns include:
- Resolve subscription ownership server-side from the authenticated organization rather than trusting client-supplied identifiers
- Verify that every referenced billing object belongs to the requesting organization before mutation
- Use server-maintained organization-to-subscription mappings where possible
- Apply deny-by-default authorization policies to billing actions
- Limit billing permissions according to role and least privilege
- Avoid exposing mutable cross-tenant identifiers as sufficient authorization evidence
- Centralize authorization checks so new billing endpoints receive consistent protection
Mitigation generally focuses on enforcing authorization at the object and tenant boundaries for every billing operation.
Common defensive patterns include:
- Resolve subscription ownership server-side from the authenticated organization rather than trusting client-supplied identifiers
- Verify that every referenced billing object belongs to the requesting organization before mutation
- Use server-maintained organization-to-subscription mappings where possible
- Apply deny-by-default authorization policies to billing actions
- Limit billing permissions according to role and least privilege
- Avoid exposing mutable cross-tenant identifiers as sufficient authorization evidence
- Centralize authorization checks so new billing endpoints receive consistent protection
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review rules that flag direct use of request-supplied object identifiers in mutation calls
- Review of billing controllers for missing organization-ownership checks
- Tests that attempt to use one tenant's subscription identifier from another authenticated tenant
- API authorization policies requiring tenant scoping for all subscription operations
- Audit logs correlating authenticated organization IDs with the billing objects they modify
- Automated security testing for broken object-level authorization and insecure direct object references
Organizations can look for this class of issue through:
- Static analysis and code review rules that flag direct use of request-supplied object identifiers in mutation calls
- Review of billing controllers for missing organization-ownership checks
- Tests that attempt to use one tenant's subscription identifier from another authenticated tenant
- API authorization policies requiring tenant scoping for all subscription operations
- Audit logs correlating authenticated organization IDs with the billing objects they modify
- Automated security testing for broken object-level authorization and insecure direct object references
