Cortex XSOAR EUVD-2026-36146

Exploitation requires three concurrent conditions: (1) the attacker must be physically or logically adjacent to the network segment hosting the Cortex XSOAR engine - remote internet-based exploitation is not possible given AV:A; (2) the attacker must successfully achieve active MITM positioning to intercept and modify outbound network response traffic from the XSOAR engine, indicated by AC:H and AT:P - passive observation is insufficient; (3) the XSOAR engine must initiate a network request to fetch or update content (e.g., a content pack download) during the attacker's interception window, providing the opportunity to inject the malicious archive (reflected by UI:P). Limiting factors: network segmentation preventing adjacency is the strongest deterrent; use of TLS with proper certificate validation for content downloads would prevent MITM injection even if network proximity is achieved; the attack does not work against XSOAR deployments that do not perform outbound content/update fetches.

Despite VC:H/VI:H/VA:H in the CVSS 4.0 vector - indicating full triad impact on the vulnerable system - the overall score of 4.8 reflects significant exploitation barriers. AV:A (adjacent network only) confines attackers to the same network segment as the XSOAR host, AC:H signals high attack complexity, and AT:P indicates an additional attack requirement (specifically, active MITM positioning). UI:P (user interaction present) means exploitation is contingent on the XSOAR engine initiating a network request that the attacker can intercept, rather than being attacker-initiated at will. The CVSS 4.0 supplemental metric E:U (exploitation unreported) confirms no public exploit or observed in-the-wild activity at time of publication. Conversely, AU:Y (automatable) suggests that once an attacker achieves MITM positioning, the exploitation chain can be executed programmatically without per-victim manual steps. The Amber urgency rating and Moderate response effort from vendor further suggest this is a genuine but not immediately critical risk for most deployments - organizations with XSOAR deployed in flat or poorly segmented networks face meaningfully higher exposure.

An attacker positioned on the same network segment as a Cortex XSOAR engine - via ARP poisoning, rogue switch port, or compromised network device - intercepts an outbound HTTP/S request made by the engine to download a content pack or integration update. The attacker substitutes the legitimate response with a crafted tar archive containing a member path such as '../../etc/cron.d/backdoor', causing the XSOAR engine to extract the file outside the intended directory and write attacker-controlled content to a sensitive system path. No public POC has been identified, but the underlying mechanism (Python tarfile path traversal per CVE-2007-4559) is extremely well-documented and low-skill to implement once MITM is achieved.