Monitor vulnerabilities like this one. Sign up free to get alerted when software you use is affected.
8.8

Flowise allows unauthorized users to hijack other accounts and features

GHSA-cwc3-p92j-g7qm CVE-2026-30823 GHSA-cwc3-p92j-g7qm
Summary

An attacker can exploit a weakness in Flowise's login system to take control of other users' accounts and enable features they shouldn't have access to. This can happen because Flowise doesn't check if the user making changes has permission to do so. To fix this, Flowise needs to ensure that only authorized users can make changes to other users' accounts and features.

What to do
  • Update flowise to version 3.0.13.
Affected software
VendorProductAffected versionsFix available
flowise <= 3.0.12 3.0.13
flowise <= 3.0.13 3.0.13
Original title
Flowise has IDOR leading to Account Takeover and Enterprise Feature Bypass via SSO Configuration
Original description
### 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**:

```http
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.

```json
{
"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.
ghsa CVSS3.1 8.8
Vulnerability type
CWE-639 Authorization Bypass Through User-Controlled Key
CWE-862 Missing Authorization
Published: 6 Mar 2026 · Updated: 13 Mar 2026 · First seen: 6 Mar 2026