CVE-2026-0313: Command injection in Cortex XSOAR and XSIAM OS Query packs fixed in 1.0.17

Palo Alto Networks has fixed an operating system command injection flaw in a content pack for its Cortex XSOAR and Cortex XSIAM security orchestration products. Tracked as CVE-2026-0313, the bug in the OS Query pack let an authenticated administrator run arbitrary OS commands on remote endpoints the platform manages, turning a console session into a foothold on managed hosts.

The vulnerability

According to an analysis published on dev.to, which cites the vendor's advisory and the French CERT bulletin CERTFR-2026-AVI-1326, Palo Alto Networks disclosed the issue on 14 October 2026. It is classified as CWE-78, OS command injection, and carries scores of 6.1 under CVSS-BT and 8.6 under CVSS-B. Urgency is rated moderate, exploit maturity is listed as unreported, and the disclosure records no known malicious use.

The affected components are the OS Query pack for Cortex XSIAM and Cortex XSOAR below version 1.0.17, and version 1.0.17 resolves both.

How the flaw works

The OS Query pack issues operating system queries across a fleet of endpoints and depends on the platform's SSH integration to reach them. As the dev.to write-up explains, input travelling through the platform arrived at the command layer without sanitisation, so a crafted value could execute on the target machine rather than be interpreted as a query argument.

Exploitation depends on three conditions holding at the same time, the piece notes: an administrator must be logged in, the pack must be installed, and SSH must be configured against reachable endpoints. Take away any one of them and there is no attack path.

Hard to size from outside

External scanning offers a murky picture of exposure. The dev.to article reports that a ZoomEye query for assets titled Cortex XSOAR returned 7,667 results, while a query tied to this specific CVE returned none. The author cautions that the first figure counts fingerprinted, product-titled assets rather than vulnerable instances, and the second reflects missing CVE fingerprints rather than safety, so decisions should rest on internal configuration data instead.

Remediation and hardening

The direct fix is upgrading the OS Query pack to 1.0.17. Beyond that, the dev.to analysis recommends shrinking the reach the flaw exposed: keep the Cortex console confined to administrative networks, give the SSH integration its own dedicated low-privilege accounts, apply command allow-lists where the integration supports them, and never point automation at a domain administrator account.

It also advises cataloguing every integration that reaches from the management plane into endpoints, recording which identity it uses, how much privilege it holds, what network path it takes and who owns it, and giving content packs the same review as any other code, since they run with the platform's privileges. Organisations running several tenants should check all of them, because a lab or regional tenant with the pack present is just as much a target as the production one.

Why it matters

Security orchestration platforms sit above almost everything an organisation runs: they store the credentials and hold the network access needed to touch nearly every system they manage. CVE-2026-0313 shows what happens when a small add-on, a content pack, inherits that reach without inheriting the scrutiny. An administrator's expected powers cover running playbooks, reading incident data and acting on alerts; arbitrary shell commands on hosts belong to a different class entirely. And once a shell exists on one endpoint, the privilege of the SSH credential decides whether the compromise stays put or travels across the fleet. The design habit the dev.to piece proposes generalises well: treat every integration credential as something that will one day be used by the wrong person, and if that thought is uncomfortable, the integration has too much privilege. The upgrade fixes the bug; the boundary review addresses the reason the bug mattered.