An Insecure Direct Object Reference in Flowise Cloud's /api/v1/organization/customer-default-source endpoint lets any authenticated user swap the customerId parameter to pull another tenant's email address, account balance, currency, and billing configuration. There's no CVSS score, no CISA KEV listing, no public exploit code, and no Nuclei template for this one, and the package has zero downstream dependents in our tracking, so this isn't a mass-exploitation risk — but the barrier to abuse is trivial: any signed-in user with a Burp proxy can enumerate Stripe-formatted customer IDs and scrape PII across the multi-tenant platform. The real exposure is regulatory rather than technical — GDPR-relevant PII and financial metadata leaking to peer tenants is exactly the kind of incident that triggers breach-notification obligations. Upgrade self-hosted Flowise instances to 3.1.3 or later immediately, and if you operate a multi-tenant fork or similar organization/billing API pattern, add object-level authorization checks that verify the requesting session owns the requested customerId rather than trusting session validity alone. Detection-wise, watch API access logs for a single authenticated user issuing sequential or high-volume requests to this endpoint with varying customerId values — that's the enumeration signature described in the PoC.
What is the risk?
Medium severity as rated, and appropriately so: exploitation requires an existing authenticated account (not unauthenticated/anonymous access), there is no CVSS vector, EPSS score, KEV listing, public exploit, or scanner template, and downstream dependent count is 0. However, exploitability is trivial once authenticated — no special tooling beyond a request interceptor and predictable Stripe-style ID guessing/enumeration. This is a classic broken object-level access control (CWE-639) issue, not an AI-model-specific attack, but it lives inside an AI agent-building platform (Flowise) that stores tenant billing/PII data, so the compliance and privacy blast radius is disproportionate to the technical severity.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Flowise | npm | <= 3.1.2 | 3.1.3 |
Do you use Flowise? You're affected.
How severe is it?
What should I do?
1 step1) Upgrade Flowise to version 3.1.3 or later, which patches the endpoint per the referenced commit and GHSA advisory. 2) If running a customized fork or similar internal API pattern, implement server-side authorization checks that verify the session's owner matches the requested customerId before returning data — never trust query-string identifiers alone. 3) For SaaS operators, review access logs for the /api/v1/organization/customer-default-source endpoint for evidence of ID enumeration (many requests, sequential/varying customerId, single session). 4) Consider replacing predictable/enumerable identifiers exposed to clients with non-guessable tokens scoped per-session. 5) If leakage is suspected, notify affected customers per GDPR breach-notification requirements given exposed email/billing data.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-2364-jh4q-m9vm?
An Insecure Direct Object Reference in Flowise Cloud's /api/v1/organization/customer-default-source endpoint lets any authenticated user swap the customerId parameter to pull another tenant's email address, account balance, currency, and billing configuration. There's no CVSS score, no CISA KEV listing, no public exploit code, and no Nuclei template for this one, and the package has zero downstream dependents in our tracking, so this isn't a mass-exploitation risk — but the barrier to abuse is trivial: any signed-in user with a Burp proxy can enumerate Stripe-formatted customer IDs and scrape PII across the multi-tenant platform. The real exposure is regulatory rather than technical — GDPR-relevant PII and financial metadata leaking to peer tenants is exactly the kind of incident that triggers breach-notification obligations. Upgrade self-hosted Flowise instances to 3.1.3 or later immediately, and if you operate a multi-tenant fork or similar organization/billing API pattern, add object-level authorization checks that verify the requesting session owns the requested customerId rather than trusting session validity alone. Detection-wise, watch API access logs for a single authenticated user issuing sequential or high-volume requests to this endpoint with varying customerId values — that's the enumeration signature described in the PoC.
Is GHSA-2364-jh4q-m9vm actively exploited?
No confirmed active exploitation of GHSA-2364-jh4q-m9vm has been reported, but organizations should still patch proactively.
How to fix GHSA-2364-jh4q-m9vm?
1) Upgrade Flowise to version 3.1.3 or later, which patches the endpoint per the referenced commit and GHSA advisory. 2) If running a customized fork or similar internal API pattern, implement server-side authorization checks that verify the session's owner matches the requested customerId before returning data — never trust query-string identifiers alone. 3) For SaaS operators, review access logs for the /api/v1/organization/customer-default-source endpoint for evidence of ID enumeration (many requests, sequential/varying customerId, single session). 4) Consider replacing predictable/enumerable identifiers exposed to clients with non-guessable tokens scoped per-session. 5) If leakage is suspected, notify affected customers per GDPR breach-notification requirements given exposed email/billing data.
What systems are affected by GHSA-2364-jh4q-m9vm?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks.
What is the CVSS score for GHSA-2364-jh4q-m9vm?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0047AI-Enabled Product or ServiceAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
### Summary An Insecure Direct Object Reference (IDOR) vulnerability exists at the **GET /api/v1/organization/customer-default-source** endpoint. This flaw allows an authenticated attacker to bypass authorization checks and retrieve sensitive payment and profile information of other customers by manipulating the customerId parameter. The exposed data includes email addresses, account balances, currency types, and internal billing configurations. ### Details The application fails to implement proper object-level access control. While the endpoint requires a valid session/token, it does not verify if the requesting user has the authority to access the specific customerId provided in the query string. When a request is made to: GET /api/v1/organization/customer-default-source?customerId=cus_XXXX The server processes the request based solely on the existence of a valid session, returning the data associated with the ID regardless of the data owner's identity. Since customer IDs follow a predictable pattern (Stripe-formatted cus_...), an attacker could potentially enumerate these IDs to scrape customer data. ### PoC 1. To reproduce the vulnerability, follow these steps: 2. Log in to your account at cloud.flowiseai.com. 3. Capture a request to the payment source endpoint using a proxy tool (e.g., Burp Suite). 4. Change the customerId parameter in the URL to a target user's ID (e.g., cus_U9ajkQvu0e67uH). Execute the request: ``` GET /api/v1/organization/customer-default-source?customerId=cus_U9ajkQvu0e67uH HTTP/2 Host: cloud.flowiseai.com Cookie: [YOUR_AUTHENTICATED_COOKIES] ... ``` Response: ``` { "id": "cus_U9ajkQvu0e67uH", "object": "customer", "email": "truongnguyen210044@gmail.com", "balance": 0, "currency": "usd", "invoice_settings": { "custom_fields": null, "default_payment_method": null }, "livemode": true ... } ``` The server returns a 200 OK status with the private data of the target customer. ### Impact - Vulnerability Type: Broken Access Control (IDOR). - Impacted Parties: All registered users and organizations on the FlowiseAI Cloud platform. - Consequences: * Data Privacy Breach: Exposure of Personally Identifiable Information (PII) such as email addresses. - Financial Information Leakage: Disclosure of account balances, currency settings, and invoice metadata. - Compliance Risk: Potential violation of data protection regulations (e.g., GDPR) due to unauthorized access to user billing profiles.
Exploitation Scenario
An attacker signs up for a legitimate Flowise Cloud account (low barrier, self-service signup) and uses a proxy tool like Burp Suite to capture a normal request to the customer-default-source endpoint. Recognizing the customerId follows Stripe's predictable cus_XXXX format, the attacker methodically substitutes different values — either guessed, leaked from other sources, or harvested from public references — and replays the authenticated request. Each successful substitution returns another tenant's email, account balance, currency, and invoice settings with a 200 OK, allowing the attacker to build a scraped database of Flowise customer PII and billing profiles for resale, targeted phishing, or account-takeover reconnaissance against high-value tenants.
Weaknesses (CWE)
CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
- [Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
- [Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2025-7133810.0Flowise: unauthenticated file write enables RCE
Same package: flowiseCVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same package: flowiseCVE-2025-619139.9Flowise: path traversal in file tools leads to RCE
Same package: flowiseCVE-2026-409339.9Flowise: RCE via MCP stdio command injection
Same package: flowiseCVE-2026-464429.9Flowise: sandbox escape enables authenticated RCE
Same package: flowise