Tanium Comply CVE-2026-87047

Exploitation requires a valid, authenticated Tanium Comply session with at least low-level privileges (PR:L per CVSS). The attacker must be able to discover or guess a user-controlled key - such as a record or object identifier - belonging to another user or group within the same Comply deployment. No special non-default configuration is required beyond having an active Comply account. Exploitation is limited by the need for prior authentication and by the moderate per-object impact (C:L/I:L/A:L); unauthenticated external attackers cannot exploit this flaw directly.

The vendor-assigned CVSS 3.1 score of 6.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) accurately captures the threat model: network-reachable, low-complexity, but requiring a valid authenticated session (PR:L), with limited per-request impact across all three CIA dimensions. IDOR vulnerabilities in multi-tenant compliance platforms carry elevated business risk compared to raw CVSS score because compliance data (audit findings, remediation status, policy baselines) is often sensitive and cross-tenant visibility could undermine regulatory posture. No EPSS data is provided, KEV status is negative, and no public proof-of-concept has been identified - this is not a priority for emergency patching but should be remediated on the next scheduled maintenance cycle. The three simultaneously affected release branches (2.32, 2.35, 2.37) suggest a systemic access-control pattern rather than a one-off oversight.

An authenticated Comply user with a standard low-privilege account identifies a predictable compliance record identifier - such as an assessment ID or remediation ticket key - belonging to a peer or a different organizational group, then substitutes that key in an API request or URL parameter to read or alter that record without authorization. No proof-of-concept has been identified, but IDOR exploitation requires minimal technical skill once an attacker holds any valid session.