Multiple buffer overflow vulnerabilities in the User-ID Terminal Server Agent

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.

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.

1. Restrict TSA listener to Terminal Server / Citrix host IPs only — Add explicit source-IP allowlists on the firewall management/data-plane interface hosting the TSA port so only the TSA-installed Windows hosts can connect. Per noisgate mitigation SLA for HIGH, deploy this within 30 days — but if your TSA port is externally reachable today, treat it as CRITICAL exposure and lock it down within hours.
2. Audit Panorama for firewalls with TSA entries — Export the User-ID > Terminal Server Agents list from every managed firewall. Any firewall with zero entries is not vulnerable and can be deprioritized — this narrows the patch scope drastically. Complete within 7 days.
3. Monitor for TSA daemon restarts and User-ID agent disconnects — Wire Panorama and SIEM alerts on User-ID agent state transitions and unexpected data-plane process restarts; DoS is the most likely exploit outcome and shows up as identity policy degradation.
4. Upgrade to fixed PAN-OS trains — Schedule maintenance windows to move to 12.1.8 / 11.2.13 / 11.1.16 / 10.2.7-h36 (or the corresponding hotfix line closest to your current build) within the noisgate remediation SLA of 180 days for HIGH.

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

Sources

1. Palo Alto PSIRT — CVE-2026-0288 advisory
2. Canadian Centre for Cyber Security AV26-674
3. CyberPress coverage
4. Cybersecurity News writeup
5. Tenable CVE record
6. NVD CVE-2026-0288
7. Feedly CVE tracker
8. OpenCVE record