CVE-2026-73488

Executive Summary

CVE-2026-73488 is an Insecure Direct Object Reference (IDOR) vulnerability in Flowise versions prior to 3.1.3, affecting the authenticated API endpoint GET /api/v1/organization/customer-default-source. An authenticated attacker can manipulate the customerId parameter to retrieve payment and profile data — email addresses, account balances, currency types, and billing configurations — belonging to other customers of the Flowise deployment. No CVSS score has been assigned, the CVE is not listed in CISA's Known Exploited Vulnerabilities catalog, and no public exploit code is identified; a patch is claimed in Flowise 3.1.3 via OSV but has not been independently confirmed.

Technical Analysis

The vulnerability belongs to the CWE-639 class (Insecure Direct Object Reference), a subtype of broken object-level authorization (OWASP API1:2023). The affected endpoint is GET /api/v1/organization/customer-default-source, which is reachable by authenticated users of the Flowise application. The endpoint is designed to return a customer's default-payment-source record — i.e., the billing/payment configuration tied to a customer account within an organization.

The vulnerability mechanism is object-level authorization bypass: when the HTTP handler processes a request for the default payment source, it uses the attacker-supplied customerId query parameter to look up and return the resource, but does not first verify that the authenticated principal is authorized to access the object identified by that customerId. In a correct implementation, the server would enforce a two-part authorization check: (1) authenticate the requester, and (2) verify the requester's identity/role is entitled to access the specific customer object. Flowise versions before 3.1.3 fail the second check, allowing any authenticated user to read resources owned by arbitrary other customers.

The NVD description states that customer IDs are predictable ("Attackers can enumerate predictable customer IDs"), meaning IDs are likely sequential integers or otherwise guessable identifiers rather than sufficiently random tokens. This makes the flaw practically exploitable: an attacker does not need to observe another customer's ID; they can simply iterate through ID values.

The data exposed per the NVD description includes: email addresses, account balances, currency types, and billing configurations. This is sensitive personally identifiable information (PII) combined with financial/billing metadata. No further implementation details are provided in the advisory — the underlying handler logic, database ORM usage, and API framework are not disclosed in the NVD description, and insufficient technical detail is available to describe the exact code path.

Attack surface considerations:

• The endpoint is under /api/v1/organization/, indicating it is exposed via the application's web API.
• Authentication is required, but only at the session level — no per-object authorization.
• Flowise is commonly self-hosted and may be exposed to the internet or to a wide internal user base, expanding the number of potential attackers.
• Because the attack is over standard HTTP GET requests with a query parameter, it is trivially scriptable once valid credentials are obtained. Every request returns a JSON response containing victim data; no CSRF, XSS, or injection is required.
• The vulnerability class (IDOR) is a well-understood web/API flaw, but the absence of public PoC code, a CVSS vector, and the low EPSS score (0.00265, 18.5th percentile) collectively indicate that active weaponization is not currently prominent.

Exploitation Scenarios

No public PoC or exploit code has been identified for CVE-2026-73488. The attack chain below is therefore inferred from the vulnerability class (CWE-639 IDOR) and the endpoint/parameter details disclosed in the NVD description.

Step 1 — Reconnaissance / Target identification. An attacker first identifies a Flowise deployment that is reachable over the network (e.g., via Shodan dorks targeting the Flowise web interface, or through internal network reconnaissance). The attacker then obtains valid credentials for any authenticated account in the system — these could be a low-privileged user account, a trial account, or a compromised legitimate account. No special privileges are required because the flaw is an authorization bypass, not a privilege escalation to an admin-only function.

Step 2 — Triggering the flaw. The attacker logs in, obtains a valid session token/cookie, and sends a GET request to /api/v1/organization/customer-default-source?customerId=<value> using an arbitrary or guessed customerId. Because the server omits the object-level authorization check, the endpoint returns the default payment source for the customer whose ID was supplied, regardless of whether the authenticated user has any relationship to that customer.

Step 3 — Payload / execution method. At the vulnerability-class level, the payload is simply a crafted HTTP query string. Since customer IDs are predictable, the attacker enumerates IDs — e.g., sequential integers (1, 2, 3, ...) or other low-entropy identifiers — typically via a simple loop script or an HTTP fuzzer. Each iteration yields the target customer's billing and profile records. The predicted volume of data disclosure scales linearly with the number of IDs enumerated.

Step 4 — Post-exploitation impact. The collected data — email addresses, account balances, currency types, and billing configurations — is aggregated and used for: spear-phishing (email addresses and billing context), financial fraud or extortion (account balances and currency information), and further targeted attacks against high-value customers. Because the endpoint reveals payment-source configuration, an attacker may also map the billing infrastructure of the organization, potentially enabling subsequent social-engineering attacks against payment providers or support desks. The stolen PII may also trigger regulatory notification obligations (e.g., GDPR breach reporting) if the deployment processes EU personal data.

Impact Assessment

The business impact of CVE-2026-73488 is primarily a confidentiality breach at scale. The vulnerability exposes financial and personal data (email, balances, currency, billing configuration) of all customers managed by the affected Flowise organization, without requiring compromise of a privileged account.

Affected systems: self-hosted Flowise deployments running versions prior to 3.1.3. The vulnerability is exposed through the web API layer and requires network access to the application plus an authenticated session. Deployments that use network-level access controls (VPN, IP allowlists) have a reduced attack surface. Deployments directly exposed to the internet pose the highest risk.

Blast radius considerations:

• Data sensitivity: Payment configuration and account balances are high-sensitivity data; exposure can enable fraud, extortion, and phishing.
• Scale: IDOR enumeration allows an attacker to harvest data for all customers, not a single targeted victim, meaning the blast radius is effectively the entire customer database.
• CVSS: The NVD has assigned no CVSS vector or score for this CVE. Organizations should not treat the absence of a score as "low risk"; rather, they should perform independent risk scoring using CWE-639 as a guide (the OWASP API Security Top 10 rates broken object-level authorization as the number one API risk).
• Exploitation likelihood: EPSS = 0.00265 (18.5th percentile) suggests a low current probability of exploitation in the wild; CISA KEV does not list the CVE. However, IDOR is a trivially scriptable flaw once a valid session is obtained, and the enumeration step requires minimal skill.
• Compliance: Depending on the data subjects, exposure of email addresses, financial data, and billing configurations can trigger GDPR, CCPA, PCI-DSS, or sector-specific breach notification and remediation obligations.

Detection Guidance

The endpoint and parameter names in the following rules are taken directly from the NVD description. Detection focuses on two signals: (1) direct access to the sensitive endpoint, and (2) burst patterns indicating IDOR enumeration (many distinct customerId values from a single authenticated source within a short timeframe).

Sigma Rule

title: Flowise customer-default-source IDOR Access - CVE-2026-73488
id: 7f3a9c11-4d52-4b7e-9f1a-3d6c8e734881
status: experimental
description: >
  Detects HTTP requests to the Flowise GET /api/v1/organization/customer-default-source
  endpoint with a customerId parameter, which may indicate exploitation of an
  insecure direct object reference (CVE-2026-73488).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-73488
author: Threat Intelligence Team, valtersit.com
date: 2026/01/01
logsource:
  category: webserver
  product: apache
  definition: Requires web server access logs that include the query string (e.g., Combined Log Format).
detection:
  selection:
    cs-method: GET
    cs-uri-path: /api/v1/organization/customer-default-source
    cs-uri-query|contains: customerId=
  condition: selection
fields:
  - c-ip
  - cs-username
  - cs-uri-query
falsepositives:
  - Legitimate administrative or support operations that fetch a customer's payment source
level: high

---
title: Flowise customer-default-source IDOR Enumeration - CVE-2026-73488
id: 8b4d0f22-5e63-4c8a-a07e-9d7f4b845992
status: experimental
description: >
  Detects burst-like enumeration of distinct customerId values against the Flowise
  customer-default-source endpoint from a single client, characteristic of IDOR
  exploitation (CVE-2026-73488).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-73488
author: Threat Intelligence Team, valtersit.com
date: 2026/01/01
logsource:
  category: webserver
  product: apache
detection:
  selection:
    cs-method: GET
    cs-uri-path: /api/v1/organization/customer-default-source
    cs-uri-query|contains: customerId=
  timeframe: 1m
  condition: selection | count(distinct cs-uri-query) by c-ip > 10
fields:
  - c-ip
  - cs-uri-query
falsepositives:
  - Bulk operations performed by scripts or monitoring tools with legitimate scope
level: critical

YARA Rule

rule CVE_2026_73488_Flowise_IDOR_CustomerDefaultSource
{
    meta:
        author = "Threat Intelligence Team, valtersit.com"
        description = "Detects web server logs, HTTP captures, or script artifacts referencing the Flowise customer-default-source endpoint with a customerId parameter (CVE-2026-73488)."
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-73488"
        date = "2026-01-01"
        cve = "CVE-2026-73488"
        severity = "high"

    strings:
        $endpoint = "/api/v1/organization/customer-default-source"
        $param = "customerId="
        $http_get = "GET " ascii nocase
        $json_balance = "balance" ascii nocase
        $json_currency = "currency" ascii nocase

    condition:
        all of ($endpoint, $param) and any of ($http_get, $json_balance, $json_currency)
}

rule CVE_2026_73488_Flowise_IDOR_Enumeration_Burst
{
    meta:
        author = "Threat Intelligence Team, valtersit.com"
        description = "Detects log files containing a high frequency of distinct customerId values against the Flowise customer-default-source endpoint, indicating IDOR enumeration (CVE-2026-73488)."
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-73488"
        cve = "CVE-2026-73488"

    strings:
        $endpoint = "/api/v1/organization/customer-default-source"
        $param_key = "customerId"

    condition:
        all of them and #param_key >= 10
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"CVE-2026-73488 Flowise customer-default-source IDOR enumeration attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"/api/v1/organization/customer-default-source"; http.uri; content:"customerId="; http.uri; pcre:"/customerId=[0-9A-Za-z-]+/U"; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2026-73488; classtype:attempted-user; threshold:type both, track by_src, count 15, seconds 60; sid:202673488; rev:1;)

Notes: The rule triggers on each request to the sensitive endpoint carrying a customerId query parameter, and the threshold keyword suppresses noisy single hits while alerting when 15 or more such requests are sent by one source IP within 60 seconds — the characteristic signature of IDOR enumeration. Adjust the threshold to baseline legitimate traffic in your environment.

Elastic Detection

// Alert on single access to the sensitive endpoint (high-value hit)
http where http.request.method == "GET"
    and http.request.uri.path == "/api/v1/organization/customer-default-source"
    and http.request.uri.query startsWith "customerId="

// Alert on enumeration: many requests, many distinct customerId values, one source
any where true
| filter event.category == "web" and http.request.method == "GET"
    and http.request.uri.path == "/api/v1/organization/customer-default-source"
    and http.request.uri.query like "customerId=*"
| stats req_count = count(*),
        distinct_customers = cardinalize(http.request.uri.query),
        src_ips = cardinalize(source.ip) by source.ip
| where req_count >= 15 and distinct_customers >= 5

Splunk SPL Query

index=web sourcetype=access_combined
    uri_path="/api/v1/organization/customer-default-source"
    uri_query="*customerId=*"
| stats
    count AS request_count,
    dc(uri_query) AS distinct_customer_ids,
    values(uri_query) AS sample_queries,
    earliest(_time) AS first_seen,
    latest(_time) AS last_seen
    BY clientip, user
| where request_count >= 15 AND distinct_customer_ids >= 5
| eval duration_minutes = round((last_seen - first_seen) / 60, 2)
| table _time, clientip, user, request_count, distinct_customer_ids, duration_minutes, sample_queries
| sort by request_count desc

Wazuh OSSEC Rule

<group name="web,flowise,idor,">
  <!-- Single-hit detection for the sensitive endpoint (CVE-2026-73488) -->
  <rule id="100201" level="12">
    <decoded_as>web</decoded_as>
    <match>/api/v1/organization/customer-default-source</match>
    <regex>customerId=\S+</regex>
    <description>Flowise customer-default-source endpoint accessed with customerId parameter - possible CVE-2026-73488 IDOR attempt</description>
    <group>attack.idor,cve_2026_73488,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>

  <!-- Enumeration burst: same source, many requests in 60s -->
  <rule id="100202" level="15" frequency="15" timeframe="60">
    <if_matched_sid>100201</if_matched_sid>
    <same_source_ip />
    <description>Possible CVE-2026-73488 IDOR enumeration - repeated customerId manipulation from a single source</description>
    <group>attack.idor,cve_2026_73488,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED). The only patch reference is an OSV entry attributing the fix to Flowise version 3.1.3. This has not been independently confirmed against the vendor's release notes or changelog, and the vendor field in the CVE record is listed as "Unknown." Organizations should treat the patch claim with caution and verify it before relying on it.

1) Immediate mitigations (no patch verified):

• Apply network-layer access controls to the Flowise API: restrict access to the web application and /api/v1/* paths to trusted internal networks/VPNs; do not expose Flowise directly to the internet unless strictly required.
• If the application must be internet-facing, deploy a reverse proxy or WAF rule that (a) blocks or rate-limits requests to /api/v1/organization/customer-default-source, or (b) requires the endpoint to be accessed only from administrative IP ranges.
• Audit and rotate credentials for all existing Flowise user accounts; disable unused or low-privilege accounts to reduce the authenticated attacker surface.
• Review application logs for anomalous access to the endpoint — especially bursts of distinct customerId values from a single user/IP — using the detection rules in this report before applying the patch.

2) Patch / upgrade steps:

• Upgrade the Flowise deployment to version 3.1.3 or later once the fix is confirmed. Because patch confidence is 2/4 (single-source claim, not independently confirmed), validate the upgrade against the vendor's official release channel (e.g., the Flowise project repository or issued releases) rather than relying solely on the OSV entry.
• After upgrading, regression-test the endpoint: log in as a low-privileged user and confirm that requesting a customerId belonging to another organization/customer returns an authorization error (HTTP 403/404) rather than data.

3) Long-term hardening:

• Implement server-side object-level authorization on every API handler: the authenticated principal must be verified as the owner (or an authorized member of the owning organization) of the requested resource before any data is returned. Do not rely on client-supplied identifiers for access decisions.
• Replace predictable, sequential customer identifiers with high-entropy, non-enumerable IDs (e.g., UUIDv4) at the API level, or enforce opaque reference mapping.
• Add per-user rate limiting and anomaly detection on API endpoints that return sensitive or financial data.
• Run regular API security assessments (e.g., OWASP API Security Top 10 checks) covering broken object-level authorization, and incorporate IDOR test cases (cross-tenant resource access) into the CI/CD pipeline.
• Ensure web server and API access logs include the full query string, authenticated username, and source IP to support future forensic analysis.

References

• NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-73488
• OSV Advisory (patch claim, single source): https://osv.dev/vulnerability/CVE-2026-73488
• CWE-639 — Insecure Direct Object Reference: https://cwe.mitre.org/data/definitions/639.html
• Flowise project repository (affected product; patch source verification): https://github.com/FlowiseAI/Flowise
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-73488 NOT currently listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor / in-the-wild evidence: No threat actor campaign, exploit-in-the-wild activity, or public proof-of-concept has been identified at the time of writing. The absence of a CISA KEV listing and the low EPSS percentile (0.00265, 18.5th percentile) are consistent with an unreported or unreleased exploitation status. This assessment may change rapidly if the patch claim is confirmed, a PoC is published, or mass scanning of Flowise deployments is observed.