Two Tanium report permissions can become code execution. Three release branches need checking.

Two Tanium Comply advisories published on 9 September describe different ways that lower-trust activity can reach the management service. One begins with an authenticated report writer. The other begins with privileged access to a machine running the Tanium Client.

They share fixed builds. They do not describe a demonstrated two-step exploit chain. Keeping that distinction intact is what makes the update plan useful.

Two report permissions carry execution risk

TAN-2026-040, CVE-2026-87021, is rated High at CVSS 3.1 7.2. Tanium identifies an authenticated user holding both Comply Report Content Write and Comply Report Write. The impact is unauthorised code execution in the Comply service context.

The interesting part is the permission pair. A role called report author can sound less sensitive than a role called administrator, yet the advisory describes a route from that role's capabilities to service execution. The role's friendly name is therefore a poor basis for deciding who should hold it.

An access review should resolve effective permissions, including group inheritance and service accounts. Reviewing only direct assignments can miss a user who receives one capability from a team role and the other from an exception granted months earlier. That is a review method, not a claim about a particular customer's deployment.

The second route starts at a managed client

TAN-2026-042, CVE-2026-87034, is rated High at 8.3. Its narrative requires an attacker with privileged access to a system running the Tanium Client and describes tampering with a SQL query executed by Comply.

Its vector nevertheless contains PR:N, together with high attack complexity, required user interaction and changed scope. Do not turn PR:N into “any unauthenticated internet user can exploit this”. The prose names a precondition on another system. The advisory does not explain every scoring judgement, so an internal triage note should retain both the narrative and the vector.

Match the update to the release branch

Both advisories give the following builds under Available Updates. Use that section for the fixed build: the parenthetical version ranges in Products Affected also repeat these endpoints, which can otherwise make a quick transcription ambiguous.

Fixed Comply builds listed by Tanium

Release branch	Update	Comply version
2025H1	Update 24 or later	2.32.252 or later within the branch
2025H2	Update 14 or later	2.35.306 or later within the branch
2026H1	Update 7 or later	2.37.308 or later within the branch

The branch qualification matters. A ticket that says “install Update 7” without identifying the release family does not communicate a reproducible target. Record the module and its full version, not only the umbrella platform version or an update number copied from another team's estate.

Neither advisory lists a workaround. Removing unnecessary report permissions is sensible exposure reduction for the first route, but it should not be presented as a vendor-endorsed substitute for installing the fixed build. It also does not address the different precondition in the client-originating route.

An illustrative access review

Consider a compliance analyst who can create report content through one group and save reports through another. A team may have approved each group independently. The security-relevant result is the combination of permissions in the user's effective role, not the two approval records viewed separately.

Now consider a separate administrator of a managed workstation. That person need not be the report author in the first scenario. The second advisory begins with privileged access on a client system. Combining the two people into one fictional attacker would make the story easier to draw and harder to use.

The review should therefore produce two lists: principals with the report permission pair, and the administrators responsible for the trust placed in managed-client inputs. The first list supports entitlement review. The second identifies the owners who need to validate the client-to-service boundary and any relevant investigation evidence.

Ask for module-level proof

A useful completion record contains the release branch, installed Comply build, update time and evidence that the service is running the intended version. It also records an ordinary report workflow succeeding after the change. A successful platform login is not a test of the module operation that changed.

Where exposure has prompted an investigation, preserve relevant audit records before routine retention removes them. The advisories do not provide a complete detection recipe or establish that a specific customer was compromised. Do not invent indicators to fill that gap, and do not describe the absence of an alert as proof of absence.

This is the same discipline behind the earlier SonicWall remediation briefing: closure needs evidence for the action actually required. The similarity is procedural, not a claim that the products share a vulnerability mechanism.

The position

Treat report-writing authority as a security-sensitive capability and managed-client input as a boundary to validate. Patch the Comply branch you run, retain the full module version in the record, and keep the two access paths separate when reviewing exposure. A single “Tanium updated” checkbox loses precisely the detail these advisories provide.