Tanium Comply EUVD-2026-74550

Exploitation requires a valid authenticated session in Tanium Comply with at least low-level privileges (PR:L per CVSS). The attacker must have network access to the Tanium Comply web or API interface. No special non-default configuration is required beyond having an account in the affected Comply version. Limiting factors: unauthenticated external attackers cannot exploit this; exploitation is constrained to the network segments that can reach the Tanium server; impact is bounded to integrity and availability of compliance records (C:N per CVSS - no credential or sensitive data disclosure confirmed). Three specific version branches are affected: 2.32.x before 2.32.252, 2.35.x before 2.35.306, and 2.37.x before 2.37.308.

Real-world risk is moderate. The CVSS 5.4 score with PR:L correctly reflects that exploitation requires a valid authenticated session within the Tanium Comply application - unauthenticated attackers cannot exploit this remotely. Attack complexity is low (AC:L), meaning no special race conditions or environmental dependencies are required beyond having an account. The integrity and availability impacts are both Low (I:L/A:L), scoping the harm to partial manipulation or disruption of compliance records rather than full system compromise. EPSS data is not provided in the source intelligence; given the low public profile, opportunistic mass exploitation is unlikely. No KEV listing and no POC are present, further indicating this has not been weaponized. The primary realistic threat is an insider or compromised low-privileged Comply account being used to corrupt, delete, or falsify compliance scan results - which is consequential in regulated environments where Comply data feeds audit and policy decisions. The mismatch between C:N in the CVSS and the IDOR root cause (CWE-639 typically also enables unauthorized reads) should be verified against the vendor advisory; it is possible only write/delete paths are affected.

An authenticated Tanium Comply user with a standard or read-only role modifies the object identifier in an API request - for example, changing a scan-result or policy record ID to one belonging to another team or a higher-privileged scope. The server processes the request without verifying ownership, allowing the attacker to alter or delete compliance records they do not own. In a regulated environment, this could be used to suppress failed compliance findings before an audit, undermining the integrity of the compliance program. No public exploit code is required; the technique follows standard IDOR methodology.