CVE-2026-81817

Executive Summary

CVE-2026-81817 is an authorization bypass vulnerability affecting Flowintel, a case-management platform, in versions up to and including 3.3.0. The flaw stems from a broken object-level authorization (BOLA) condition in which task endpoints accept both a case identifier and a task identifier but fail to verify the task actually belongs to the supplied case. An authenticated user with editor-level access to one case can substitute a task identifier from another case, thereby invoking sensitive operations — including edit, delete, note, assignment, status, file, export, MISP-linking, subtask, and external-reference operations — against tasks they are not authorized to access. The vulnerability has no public exploit code, no CISA KEV listing, and no confirmed in-the-wild exploitation as of reporting time; however, the vulnerable logic is known to exist in all versions released prior to the fix.

Technical Analysis

The vulnerability class is CWE-639 — Authorization Bypass Through User-Controlled Key. This is a broken object-level authorization issue common in web applications where resource identifiers are exposed or predictable.

According to the NVD description, affected Flowintel versions contain this flaw across "numerous task endpoints." The routes generally accept two identifiers: a case identifier and a task identifier. The intended semantics are that the task identifier is scoped to the supplied case. Prior to the patch, the application did not enforce that the task actually belonged to the supplied case. This means the application loaded the task object based solely on the task identifier, without validating that the task's owning case matched the case identifier supplied in the request.

From an architectural perspective, this indicates that task endpoints such as edit, delete, note, assignment, status, file, export, MISP-linking, subtask, and external-reference operations all shared the same flawed pattern: they accepted and processed a task ID without cross-checking it against the associated case ID.

The patch introduces a function named task_case_bound_required (explicitly named in the NVD description), which loads both objects and returns HTTP 404 unless the task belongs to the requested case. The 404 response — rather than a 403 — is intentional design: it avoids disclosing the existence of tasks the user is not authorized to access.

Additionally, the patch adds explicit checks that a requested note_id belongs to the current task before returning or exporting it. This closes related cross-object access paths where a user might supply a note identifier from another task or case.

The affected version range is "=>3.3.0" as reported, which we interpret as versions up to and including 3.3.0. The exact patched version number is not specified in the NVD description.

The privilege requirement for exploitation is editor-level access to at least one case. This is a relatively low-privilege requirement within the application's role model — an editor is not typically an administrator but holds sufficient permissions to modify case content.

Exploitation Scenarios

No public proof-of-concept or exploit code exists for CVE-2026-81817 at the time of writing. The following attack chain is inferred from the vulnerability class (broken object-level authorization) as described in the NVD data.

Step 1: Reconnaissance / Target Identification. The attacker must first be an authenticated user of a Flowintel instance. They need editor-level access to at least one legitimate case. This access could be achieved through legitimate user creation (if the instance allows self-registration and case assignment), through a compromised editor account, or through a legitimate low-privilege account that was granted editor rights on a single case.

Step 2: Triggering the Flaw. The attacker identifies task endpoints that accept both a case ID and a task ID. The attacker enumerates or guesses task identifiers from other cases. This can be done by observing sequential or predictable task IDs from their own case (since task IDs are typically auto-incremented integers in database-backed applications). The attacker then substitutes a task ID belonging to a different case into a request that references their own case ID. For instance, an attacker with access to Case 100 would send a request referencing case_id=100 while substituting task_id=500 (a task belonging to Case 200). Since the application does not verify task-to-case binding, the request is processed against the foreign task.

Step 3: Payload / Execution Method. At the vulnerability-class level, the attacker crafts HTTP requests (GET or POST depending on the operation) to endpoints that handle edit, delete, note, assignment, status, file, export, MISP-linking, subtask, or external-reference operations. Specifically, for the note-related cross-object path, the attacker supplies a note_id belonging to a note in a different task. The pre-patch application does not verify that the note belongs to the current task.

Step 4: Post-Exploitation Impact. Depending on the endpoint targeted, the attacker can:

• Modify or delete tasks belonging to other cases (data integrity loss).
• Add, read, or export notes attached to foreign tasks (data confidentiality breach).
• Change status or assignment of tasks (workflow disruption).
• Access or exfiltrate files attached to foreign tasks (data breach).
• Link tasks to MISP events or add external references (supply-chain / intelligence integrity compromise).

Because the flaw spans multiple categories of endpoints, a single attacker can achieve a wide range of unauthorized operations on data they have no legitimate access to. The impact compounds if the instance handles sensitive intelligence data — consistent with Flowintel's purpose as a case-management tool for threat intelligence teams.

Important note: No public PoC is available; the above is inferred from the vulnerability class and the endpoint categories named in the NVD description. Since the fix introduces task_case_bound_required and returns 404 for mismatched pairs, any future exploit code will need to specifically target pre-patch versions only.

Impact Assessment

Business Impact: High. Flowintel is a case-management platform for threat intelligence workflows. A BOLA vulnerability in this context allows an authenticated editor to access, modify, or delete tasks across cases they are not authorized to see. In threat-intelligence environments, case data frequently contains sensitive indicators, victim information, incident details, and closed-source intelligence. Unauthorized access to this data violates confidentiality requirements and can leak sensitive operational data.

Affected Systems: Any Flowintel instance running version 3.3.0 or earlier. This includes both on-premises deployments and any managed/SaaS implementations running affected versions.

Blast Radius: The vulnerability affects all task-related endpoints (edit, delete, note, assignment, status, file, export, MISP-linking, subtask, external-reference). The blast radius is heterogeneous: account compromise of any editor-level user on any case is sufficient to reach data in all other cases on the same instance.

CVSS Note: No official CVSS score or vector has been assigned by the CNA (NVD lists N/A for both score and vector). Based on the characteristics — low privilege requirement, large blast radius, confidentiality and integrity impact — this vulnerability would plausibly score in the High (7.0–8.9) range under CVSS v3.1 if formally assessed, but we emphasize that the official score is currently N/A and should not be replaced with speculative values in internal reporting.

EPSS: Not yet scored by FIRST.org. Do not rely on EPSS for prioritization; treat this as a high-priority patch because exploitation requires low privilege and the flaw spans many endpoints.

CISA KEV: Not listed. No evidence of exploitation in the wild as of reporting time.

Detection Guidance

The following detection rules are designed to identify suspected exploitation attempts. They are based on normalization, statistical anomaly hunting, and the observable request patterns that exploitation of this BOLA vulnerability would generate.

Sigma Rule

title: Flowintel BOLA - Cross-Case Task Access Attempt
id: 9d3a4f1c-56a1-4b7e-9d3c-7f2b5a8e0c11
status: experimental
description: Detects requests to Flowintel task endpoints where the referenced task ID likely belongs to a different case (broken object-level authorization, CVE-2026-81817)
author: vultersit.com Threat Intel
date: 2025/01/01
logsource:
  category: webserver
  product: flowintel
  service: apache_or_nginx
detection:
  selection_a:
    cs-uri-extension:
      - '.*task.*(?:edit|delete|note|assignment|status|file|export|misp|subtask|external-reference).*'
  selection_b:
    cs-uri-query:
      - 'case_id=\d+&task_id=\d+'
      - 'task_id=\d+&case_id=\d+'
  condition: selection_a and selection_b
  timeframe: 5m
  threshold: 5
falsepositives:
  - Legitimate case managers accessing tasks across cases (if the application supports it in any way)
  - Automated workflows that intentionally cross-case reference tasks
level: high
tags:
  - attack.t1190
  - attack.t1530
  - cve.2026.81817
  - cwe.639

YARA Rule

rule flowintel_bola_81817
{
    meta:
        author = "vultersit.com Threat Intel"
        description = "Detects log lines or payloads indicating cross-case task references in Flowintel requests (CVE-2026-81817)"
        cve = "CVE-2026-81817"
        cwe = "CWE-639"
        date = "2025-01-01"
    strings:
        $s1 = "task_id=" ascii wide
        $s2 = "case_id=" ascii wide
        $s3 = "note_id=" ascii wide
        $s4 = "task" ascii wide
        $s5 = "case" ascii wide
        $e1 = "edit" ascii wide
        $e2 = "delete" ascii wide
        $e3 = "export" ascii wide
        $e4 = "status" ascii wide
        $e5 = "assignment" ascii wide
        $e6 = "subtask" ascii wide
    condition:
        uint16(0) == 0x0a0d or filesize < 10MB and
        (all of ($s*) and any of ($e*)) and
        #s1 > 1 and #s2 > 1
}

Suricata IDS Rule

alert http any any -> any any (
    msg:"FLOWINTEL CVE-2026-81817 BOLA - Cross-Case Task Access Attempt";
    content:"task_id=";
    http_uri;
    content:"case_id=";
    http_uri;
    distance:0;
    pcre:"/^.*(?:edit|delete|note|assignment|status|file|export|misp|subtask|external).*$/U";
    threshold:type limit, count 5, seconds 60, track by_src;
    metadata:attack_target Web_Application, deployment Perimeter, signature_severity Critical, created_at 2025_01_01;
    reference:url,https://nvd.nist.gov/vuln/detail/CVE-2026-81817;
    reference:cve,2026-81817;
    sid:202681817;
    rev:1;
)

Elastic Detection

// EQL query - detect a single source IP hitting multiple task endpoints with different case/task pairs
sequence by source.ip with maxspan=10m
  [http where url.path like "*task*" and url.query contains "case_id=" and url.query contains "task_id="]
  [http where url.path like "*task*" and url.query contains "case_id=" and url.query contains "task_id=" and url.query != process.parent.executable]

// Simpler EQL - detect requests referencing different task IDs under the same case
any where url.query contains "case_id=" and url.query contains "task_id="
  and event.action in ("http_request", "web_request")
  and (url.path like "*task*edit*" or url.path like "*task*delete*" or url.path like "*task*export*")

Splunk SPL Query

index=web sourcetype=access_combined
| rex field=uri "task_id=(?<task_id>\d+)"
| rex field=uri "case_id=(?<case_id>\d+)"
| where isnotnull(task_id) AND isnotnull(case_id)
| stats count by clientip case_id task_id uri
| stats dc(task_id) AS distinct_tasks_by_case, dc(case_id) AS distinct_cases by clientip
| where distinct_cases > 1
| table clientip distinct_cases distinct_tasks_by_case
| sort - distinct_cases

Note: The above SPL looks for a single source IP referencing multiple cases — a strong indicator of cross-case enumeration. Adjust distinct_cases > 1 threshold based on your environment's normal traffic patterns.

Wazuh OSSEC Rule

<!-- Wazuh OSSEC local rules for detecting Flowintel BOLA attempts -->
<group name="flowintel,">
  <rule id="818171" level="12">
    <decoded_as>web</decoded_as>
    <description>Flowintel - Possible BOLA cross-case task reference (CVE-2026-81817)</description>
    <field name="url">\.(edit|delete|export|status|assignment|subtask|external).*</field>
    <field name="url">task_id=</field>
    <field name="url">case_id=</field>
    <group>access_control,attack,t1190,</group>
    <options>no_full_log</options>
  </rule>
  <rule id="818172" level="14" frequency="8" timeframe="300">
    <if_matched_sid>818171</if_matched_sid>
    <description>Flowintel - Repeated possible BOLA attempts from same source (CVE-2026-81817)</description>
    <group>access_control,attack,t1190,</group>
    <options>no_full_log</options>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED. No patch evidence exists from any tracked source. The NVD description includes details of a fix (the task_case_bound_required function and the note_id binding checks), but the patched version number has not been confirmed through vendor advisories or official patch channels. Affected version is listed as "=>3.3.0".

Immediate Mitigations (before patch is available or deployed):

1. Restrict editor-level account access. If any users have editor access to one or more cases, verify whether editor access is strictly required for their role. Reduce to read-only or limited roles where possible. Since exploitation requires editor-level access to at least one case, minimizing the number of editor accounts reduces the attack surface.
2. Deploy a Web Application Firewall (WAF) with URI inspection. Create WAF rules that flag or block requests to known task endpoints where both task_id and case_id reference parameters are present and the task ID is not visibly within the allowed range for that user.
3. Audit existing logs for anomalous cross-case references. Review access logs for any requests where a single user references task IDs that appear to span multiple case ID ranges. Pay particular attention to note export and file export operations, as those provide data exfiltration paths.
4. Monitor for task ID enumeration patterns. Sequential task IDs are common. Detect requests that sequentially increment task IDs while keeping the case ID static — this is a strong indicator of BOLA probing.

Patch / Upgrade Steps:

1. Monitor the vendor's release channels for the version that includes the task_case_bound_required fix. The NVD description indicates the patch has been written, so a release containing it should be expected.
2. Before upgrading, validate the upgrade in a staging environment. The patch changes behavior from returning task data (with wrong case binding) to returning 404 for mismatched pairs. Verify that legitimate automated workflows or integrations do not depend on the vulnerable behavior.
3. Apply the patch to all production instances. Given the vulnerability spans all task endpoints, patch critical instances first, then all instances worldwide — there is no geolocation benefit to delaying.
4. After patching, recrawl internal documentation and integrations to ensure no scripts rely on cross-case task references.

Long-Term Hardening:

1. Adopt a positive-security model at the application layer. Enforce that all object references are scoped to the authenticated user's permitted contexts before any object is loaded. The fix's approach — loading both objects and returning 404 on mismatch — is a sound pattern; adopt it as a framework-wide convention for all new endpoints.
2. Implement object-level authorization testing in CI/CD. Add security tests that attempt to access objects across authorization boundaries. Prompt the tests against the task_case_bound_required pattern to verify binding checks exist on all new endpoints.
3. Enforce UUID-based identifiers instead of sequential integers. Sequential integers enable trivial enumeration. UUIDs (or random 128-bit identifiers) make cross-object guessing impractical even if binding checks are briefly absent in a future regression.
4. Conduct periodic access-control audits. Review all endpoints quarterly for BOLA patterns — particularly endpoints that accept multiple object IDs where one should be scoped to another.
5. Enable structured logging of authorization failures. Ensure that 403/404 responses for authorization violations are logged with sufficient context (source IP, user ID, target object type) to support post-incident forensics.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-81817 — Official vulnerability description and metadata (as referenced in the CVE intelligence data provided).
2. CWE-639: Authorization Bypass Through User-Controlled Key — https://cwe.mitre.org/data/definitions/639.html — The relevant weakness classification for this vulnerability, providing background on the vulnerability class and remediation patterns.
3. Flowintel (project homepage) — https://github.com/khulnasoft/flowintel (returned 404 — verify manually) — The vendor project page where official releases and advisories would be published. As of this report, no security advisory referencing CVE-2026-81817 has been posted.
4. CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CVE-2026-81817 is NOT listed in the KEV as of reporting time; this reference is provided for continuous monitoring of any future updates.
5. ATT&CK Technique T1190 — Exploit Public-Facing Application — https://attack.mitre.org/techniques/T1190/ — The MITRE ATT&CK technique that best categorizes this vulnerability's exploitation profile, useful for SOC alignment.

Threat Actor Activity / Exploit-in-the-Wild Assessment: As of this report, there is no public evidence of exploitation in the wild, no exploit code, and no PoC published. The vulnerability was disclosed with fix details (the task_case_bound_required function) but the fix version is not yet confirmed released, meaning affected instances remain exposed. Organizations running Flowintel ≤ 3.3.0 should treat this as a high-priority hardening item even in the absence of in-the-wild exploitation, since the vulnerability class is well-understood and the application is likely internet-facing given its purpose as a collaborative intelligence platform.