Flowintel CVE-2026-81817

Exploitation requires a valid Flowintel account with editor-level access to at least one case - unauthenticated exploitation is not possible per the CVSS PR:L metric. The attacker must also know or successfully enumerate a valid task ID belonging to a case they do not own; if task IDs are non-sequential or UUID-based the guessing surface is reduced. No special server configuration or non-default feature enablement is required - the vulnerability was present on all task-related endpoints in any standard Flowintel >= 3.3.0 deployment. Exploitation is limited to the Flowintel application's own data scope (no scope change, SC/SI/SA = N); it does not grant OS-level or database-level access beyond what Flowintel itself exposes. Multi-team deployments where case access is intentionally partitioned between teams or customers face the highest practical risk.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N, score 7.2) accurately reflects the threat profile: network-reachable, low complexity, requiring only a low-privilege authenticated session, with high integrity impact on vulnerable-system data. The PR:L requirement is the primary limiting factor - exploitation demands an account with editor-level access to at least one case, which is a non-trivial barrier in most controlled deployments. Confidentiality impact is rated low, consistent with the ability to read task notes or export data from foreign cases, but not credential or system-level data. Availability impact is low because tasks can be deleted but the platform itself remains operational. No CISA KEV listing and no public exploit code have been identified, lowering the immediate exploitation likelihood. The EPSS score is not available in the provided data. The breadth of the fix - over a dozen endpoints decorated in the patch - indicates the authorization gap was systemic rather than isolated, meaning exploitation surface was wide once an attacker had valid credentials. For organizations using Flowintel in multi-tenant or multi-team configurations where case segregation is a security boundary, this vulnerability should be treated as high priority.

An attacker authenticated as an editor on Case A enumerates task IDs by interacting with their own case, then crafts API requests substituting a task ID from Case B into endpoints such as DELETE /case/{caseB_id}/task/{taskB_id} or GET /case/{caseA_id}/task/{taskB_id}/note. Because the pre-patch routes only verified case-level access and not task-to-case ownership, the server processes the request against the foreign task, enabling the attacker to read, modify, or delete task data - including notes, files, assignments, and MISP-linked artifacts - from cases they have no legitimate access to. No public exploit code has been identified, but the attack requires only knowledge of a valid foreign task ID, which may be discoverable through sequential ID enumeration if integer IDs are used.