A memory-corruption bug in the plumbing that tells your firewall which Citrix user is which
The User-ID Terminal Server Agent (TSA) is the PAN-OS component that maps source-port ranges to individual users on multi-user Windows/Citrix hosts so firewall policies can be identity-aware. It listens on a TCP port that agents connect to, and multiple out-of-bounds writes (CWE-787) in that listener let an unauthenticated attacker with network reach send crafted traffic that corrupts memory — either crashing the daemon (DoS) or, less reliably, achieving arbitrary code execution in the TSA process context. Affected: PAN-OS 12.1 < 12.1.8 (and h-lines 12.1.4-h8, 12.1.7-h2), 11.2 < 11.2.13 (h-lines 11.2.4-h20, 11.2.7-h18, 11.2.10-h12), 11.1 < 11.1.16, and 10.2 < 10.2.7-h36 plus Prisma Access equivalents. Panorama and any firewall with no TSA entry configured under Device > User Identification > Terminal Server Agents is unaffected.
Palo Alto's CVSS:4.0 base of 7.2 HIGH is defensible but bakes in the assumption you followed their deployment guidance. Where operators exposed the TSA listener to untrusted networks — a real, observed misconfiguration — the vendor's own CVSS-B climbs to 9.2. There is no NVD/CVSS 3.1 vector, so this is a first-pass assessment: we land at HIGH (7.8) because unauth pre-auth memory corruption on a network-edge product with fleet-scale blast radius easily clears the HIGH floor, even after discounting for the fact that most TSA installs are correctly segmented.
4 steps from start to impact.
Discover a firewall with TSA configured
nmap -sS across the firewall inside interface. Panorama and firewalls with an empty TSA list are not in scope.- Network path to a PAN-OS device with a configured TSA entry
- PAN-OS version in the affected range
- TSA is designed for internal-only reach — most enterprises restrict it to the Citrix/TS server subnets
- Panorama and TSA-less firewalls are excluded entirely
product:PAN-OS plus custom port; internal asset inventories via Panorama config export.Send crafted TSA traffic to the listener
- TCP reach to the TSA listener port
- Ability to speak or malform the TSA wire protocol
- No public PoC yet — attackers must reverse the TSA protocol themselves
- ASLR, stack canaries, and NX in modern PAN-OS complicate reliable code exec — DoS is the practical outcome for most attackers
Escalate DoS to code execution (aspirational)
- Reliable heap/stack layout knowledge for the specific PAN-OS build
- Bypass of PAN-OS binary hardening
- Per-build offsets differ across PAN-OS trains
- No exploit toolkit exists as of 2026-07-09
Abuse identity mapping to weaken policy
any or unknown-user). An attacker inside the network can now traverse zones that identity-gated rules would have blocked, or impersonate a privileged user in User-ID mappings if code execution succeeded.- User-ID-based security policy in use
- TSA disruption sustained long enough to shift traffic
- Well-designed policy has deny-by-default fallbacks for unknown-user
- Panorama alerts on User-ID agent disconnects
unknown-user traffic spikes.- Threat Prevention signatures alone — Palo Alto will publish App-ID / Threat sigs, but they only fire on inbound traffic to the firewall itself; if your TSA port is exposed to hostile subnets you cannot rely on the vulnerable device to protect itself.
- Turning off User-ID at the policy level — the TSA listener still binds if a TSA entry exists. You must remove the TSA entry or upgrade.
- WAF or upstream firewall — TSA speaks a proprietary binary protocol on a non-HTTP port; WAFs are irrelevant.
The supporting signals.
| In-the-wild exploitation | None observed. Palo Alto: *not aware of any malicious exploitation* |
|---|---|
| KEV listed | No |
| EPSS | 0.00524 (~0.5% — very low near-term exploit probability) |
| Public PoC | None public as of 2026-07-09. Discovered by researcher Liang Zhu and reported to Palo Alto |
| CVSS vector (vendor) | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L — 7.2 HIGH base, 9.2 when TSA is internet-exposed |
| CWE | CWE-787 Out-of-bounds Write |
| Affected | PAN-OS 12.1, 11.2, 11.1, 10.2 and Prisma Access — only when a TSA entry is configured. Panorama unaffected |
| Fixed versions | 12.1.8, 11.2.13, 11.1.16, 10.2.7-h36, plus hotfix lines 12.1.4-h8 / 12.1.7-h2 / 11.2.4-h20 / 11.2.7-h18 / 11.2.10-h12; Prisma Access 11.2.7-h18 / 10.2.10-h39 |
| Exposure telemetry | TSA is not a standard internet-exposed service; Shodan/Censys show negligible external TSA listeners. Most risk is internal-network reachability |
| Disclosed | 2026-07-08 by Palo Alto PSIRT |
Sources.
Why this verdict
- Unauth + network + memory-corruption on a network-security appliance clears the HIGH threshold on its own; there is no auth or user-interaction gate.
- Role multiplier — canonical network edge: PAN-OS firewalls are network-edge / policy-enforcement devices. TSA compromise degrades User-ID enforcement fleet-wide behind the firewall and, if RCE lands, delivers a data-plane foothold on the perimeter. Floor is HIGH.
- Friction — exposure narrowness: TSA is architected for internal-only reach; correctly configured deployments never expose the listener externally. This holds the verdict at HIGH rather than pushing to CRITICAL.
- Friction — RCE reliability: No public PoC, PAN-OS binary hardening (ASLR/NX/canaries), and the wording 'potentially execute arbitrary code' means DoS is the reliable outcome and RCE is a research problem. EPSS 0.00524 aligns.
- Not KEV, no in-the-wild use — removes the immediate-patch pressure that would push to CRITICAL.
Why not higher?
CRITICAL would require broad external reachability, active exploitation, or a reliable public RCE. TSA is a segmented internal service, EPSS is 0.005, no PoC exists, and PA has seen no exploitation. All three CRITICAL prerequisites fail.
Why not lower?
MEDIUM would ignore that this is unauthenticated memory corruption on a network-edge security device. The role multiplier alone floors this at HIGH regardless of how few installs expose TSA — if the chain lands, the firewall itself is impacted, which is fleet-scale for every user behind it.
Crowdsourced verification payload.
Run on an auditor workstation with API access to Panorama or each firewall. Requires a PAN-OS API key with read on config and op. Invoke as ./check-cve-2026-0288.sh <firewall-host> <api-key>. Outputs VULNERABLE / PATCHED / UNKNOWN based on PAN-OS version AND whether any TSA entry is configured.
#!/usr/bin/env bash
# noisgate check for CVE-2026-0288 (PAN-OS TSA buffer overflow)
# Usage: ./check-cve-2026-0288.sh <fw-host> <api-key>
set -u
HOST="${1:-}"
KEY="${2:-}"
if [[ -z "$HOST" || -z "$KEY" ]]; then
echo "usage: $0 <fw-host> <api-key>" >&2
exit 2
fi
CURL=(curl -sk --max-time 20)
# 1. Pull PAN-OS software version
VER_XML=$("${CURL[@]}" "https://$HOST/api/?type=op&cmd=<show><system><info></info></system></show>&key=$KEY")
VER=$(printf '%s' "$VER_XML" | sed -n 's:.*<sw-version>\([^<]*\)</sw-version>.*:\1:p')
if [[ -z "$VER" ]]; then
echo "UNKNOWN: could not read PAN-OS version from $HOST"
exit 3
fi
# 2. Check for any configured TSA entry
TSA_XML=$("${CURL[@]}" "https://$HOST/api/?type=config&action=get&xpath=/config/devices/entry/vsys/entry/user-id-agent&key=$KEY")
TSA_COUNT=$(printf '%s' "$TSA_XML" | grep -c '<entry name=' || true)
# 3. Version comparison (major.minor.patch[-hN])
vuln_ver() {
local v="$1"
case "$v" in
10.2.*) awk -v v="$v" 'BEGIN{split(v,a,"."); split(a[3],b,"-h"); p=b[1]+0; h=(b[2]==""?0:b[2]+0); if(p<7||(p==7&&h<36)) exit 0; exit 1}" && echo yes ;;
11.1.*) awk -v v="$v" 'BEGIN{split(v,a,"."); p=a[3]+0; if(p<16) exit 0; exit 1}' && echo yes ;;
11.2.*) awk -v v="$v" 'BEGIN{split(v,a,"."); split(a[3],b,"-h"); p=b[1]+0; h=(b[2]==""?0:b[2]+0); if((p<4)||(p==4&&h<20)||(p>4&&p<7)||(p==7&&h<18)||(p>7&&p<10)||(p==10&&h<12)||(p>10&&p<13)) exit 0; exit 1}' && echo yes ;;
12.1.*) awk -v v="$v" 'BEGIN{split(v,a,"."); split(a[3],b,"-h"); p=b[1]+0; h=(b[2]==""?0:b[2]+0); if((p<4)||(p==4&&h<8)||(p>4&&p<7)||(p==7&&h<2)||(p>7&&p<8)) exit 0; exit 1}' && echo yes ;;
*) echo unknown ;;
esac
}
RESULT=$(vuln_ver "$VER")
if [[ "$RESULT" == "unknown" ]]; then
echo "UNKNOWN: version $VER not in affected trains — verify manually"
exit 3
fi
if [[ "$RESULT" == "yes" && "$TSA_COUNT" -gt 0 ]]; then
echo "VULNERABLE: PAN-OS $VER with $TSA_COUNT TSA entry(ies) configured"
exit 1
fi
if [[ "$TSA_COUNT" -eq 0 ]]; then
echo "PATCHED: no TSA entries configured — not exposed regardless of version ($VER)"
exit 0
fi
echo "PATCHED: PAN-OS $VER is on a fixed train ($TSA_COUNT TSA entries present)"
exit 0