Free AI Safety Workshop — in collaboration with explainx.aiSave your seat
AgentbeamBeta
AI agent vulnerability · Flowise

CVE-2026-30823: Flowise has IDOR leading to Account Takeover and Enterprise Feature Bypass via SSO Configuration

highCVSS 3.0 8.8GHSA-cwc3-p92j-g7qm

Summary The Flowise platform has a critical Insecure Direct Object Reference (IDOR) vulnerability combined with a Business Logic Flaw in the PUT /api/v1/loginmethod endpoint. While the endpoint requires authentication, it fails to validate if the authenticated user has ownership or administrative rights over the target organizationId. This allows any low-privileged user (including "Free" plan users) to: 1.

Published Mar 6, 2026 · Updated Mar 9, 2026

Affected packages

flowise

Ecosystem
npm
Affected
<= 3.0.12
Fixed in
3.0.13
Check
npm ls flowise

Advisory details

From the GitHub Advisory Database (CC BY 4.0).

Summary

The Flowise platform has a critical Insecure Direct Object Reference (IDOR) vulnerability combined with a Business Logic Flaw in the PUT /api/v1/loginmethod endpoint.

While the endpoint requires authentication, it fails to validate if the authenticated user has ownership or administrative rights over the target organizationId. This allows any low-privileged user (including "Free" plan users) to:

  1. Overwrite the SSO configuration of any other organization.
  2. Enable "Enterprise-only" features (SSO/SAML) without a license.
  3. Perform Account Takeover by redirecting the authentication flow.

Details

The backend accepts the organizationId parameter from the JSON body and updates the database record corresponding to that ID. There is no middleware or logic check to ensure request.user.organizationId === body.organizationId.

PoC

Prerequisites:

  1. The attacker creates a standard "Free" account and obtains a valid JWT token (Cookie/Header).
  2. The attacker identifies the target organizationId (e.g., bd2b74e0-e0cd-4bb5-ba98-3cc2ae683d5d).

Step-by-Step Exploitation: The attacker sends the following PUT request to overwrite the victim's Google SSO configuration.

Request:

PUT /api/v1/loginmethod HTTP/2
Host: cloud.flowiseai.com
Cookie: token=<ATTACKER_JWT_TOKEN>
Content-Type: application/json
Accept: application/json

{
  "organizationId": "bd2b74e0-e0cd-4bb5-ba98-3cc2ae683d5d",
  "userId": "6ab311fa-0d0a-4bd6-996e-4ae721377fb2", 
  "providers": [
    {
      "providerLabel": "Google",
      "providerName": "google",
      "config": {
        "clientID": "ATTACKER_MALICIOUS_CLIENT_ID",
        "clientSecret": "ATTACKER_MALICIOUS_SECRET"
      },
      "status": "enable"
    }
  ]
}

Response: The server responds with 200 OK, confirming the modification has been applied to the victim's organization context.

{
  "status": "OK",
  "organizationId": "bd2b74e0-e0cd-4bb5-ba98-3cc2ae683d5d"
}

Impact

  • Account Takeover: An attacker can replace a victim organization's legitimate OAuth credentials (e.g., Google Client ID) with their own malicious application credentials. When victim employees try to log in via SSO, they are authenticated against the attacker's application, potentially allowing the attacker to hijack sessions or steal credentials.
  • License Control Bypass: Users on the "Free" tier can illicitly enable and configure SSO providers (Azure, Okta, etc.), which are features strictly restricted to the "Enterprise" plan.

Credited to berkdedekarginoglu.

References

How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. No analysis has been written for this entry yet. Methodology

More Flowise vulnerabilities

All Flowise entries