GHSA-2364-JH4Q-M9VM
Vulnerability from github – Published: 2026-08-04 14:16 – Updated: 2026-08-04 14:16Summary
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
-
To reproduce the vulnerability, follow these steps:
-
Log in to your account at cloud.flowiseai.com.
-
Capture a request to the payment source endpoint using a proxy tool (e.g., Burp Suite).
-
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.2"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-04T14:16:46Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nAn 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.\n\n### Details\nThe 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.\n\nWhen a request is made to:\nGET /api/v1/organization/customer-default-source?customerId=cus_XXXX\n\nThe 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\u0027s identity. Since customer IDs follow a predictable pattern (Stripe-formatted cus_...), an attacker could potentially enumerate these IDs to scrape customer data.\n\n### PoC\n1. To reproduce the vulnerability, follow these steps:\n\n2. Log in to your account at cloud.flowiseai.com.\n\n3. Capture a request to the payment source endpoint using a proxy tool (e.g., Burp Suite).\n\n4. Change the customerId parameter in the URL to a target user\u0027s ID (e.g., cus_U9ajkQvu0e67uH).\n\nExecute the request:\n```\nGET /api/v1/organization/customer-default-source?customerId=cus_U9ajkQvu0e67uH HTTP/2\nHost: cloud.flowiseai.com\nCookie: [YOUR_AUTHENTICATED_COOKIES]\n...\n```\nResponse: \n```\n{\n \"id\": \"cus_U9ajkQvu0e67uH\",\n \"object\": \"customer\",\n \"email\": \"truongnguyen210044@gmail.com\",\n \"balance\": 0,\n \"currency\": \"usd\",\n \"invoice_settings\": {\n \"custom_fields\": null,\n \"default_payment_method\": null\n },\n \"livemode\": true\n ...\n}\n```\nThe server returns a 200 OK status with the private data of the target customer.\n### Impact\n- Vulnerability Type: Broken Access Control (IDOR).\n\n- Impacted Parties: All registered users and organizations on the FlowiseAI Cloud platform.\n\n- Consequences: * Data Privacy Breach: Exposure of Personally Identifiable Information (PII) such as email addresses.\n- Financial Information Leakage: Disclosure of account balances, currency settings, and invoice metadata.\n\n- Compliance Risk: Potential violation of data protection regulations (e.g., GDPR) due to unauthorized access to user billing profiles.",
"id": "GHSA-2364-jh4q-m9vm",
"modified": "2026-08-04T14:16:46Z",
"published": "2026-08-04T14:16:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-2364-jh4q-m9vm"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/pull/6321"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/commit/4d7899d02ca370a5510406be5c91483085a412f9"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Flowise: IDOR vulnerability exists at the GET /api/v1/organization/customer-default-source endpoint"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.