CVE-2024-3400 - PAN-OS GlobalProtect command injection

CVE-2024-3400 is an arbitrary-file-creation-to-command-injection vulnerability in the GlobalProtect feature of specific PAN-OS releases. An unauthenticated network attacker can reach the affected surface and execute code with root privileges on the firewall. Palo Alto Networks rates the issue critical and reports exploitation in the wild; CISA added it to the Known Exploited Vulnerabilities catalog on 2024-04-12 with a remediation due date of 2024-04-19.

The vulnerable software version is only half of the exposure decision. The firewall must also have a GlobalProtect gateway, a GlobalProtect portal, or both configured. Device telemetry does not need to be enabled. Disabling telemetry was early guidance that Palo Alto Networks later withdrew and is not a mitigation.

Evidence basis and limits

I reviewed the current Palo Alto Networks security advisory, the Unit 42 Operation MidnightEclipse threat brief, the CISA KEV entry, and the NVD record while preparing this recipe. I did not access a PAN-OS appliance, inspect a customer Tech Support File (TSF), review proprietary PAN-OS source, execute a payload, or perform live validation. The affected and fixed releases below are therefore vendor-advisory facts, not results observed in this repository or on a device. Re-check the live vendor advisory before approving a change because product and incident-response guidance can be updated.

When to use it

  • A repository owns PAN-OS software/image pins, VM-Series deployment definitions, Panorama templates for managed firewalls, configuration exports, upgrade runbooks, vulnerability policy, or fleet inventory for PAN-OS 10.2, 11.0, or 11.1.
  • A scanner, CMDB record, ticket, or vendor alert identifies CVE-2024-3400 on a firewall with a GlobalProtect portal or gateway.
  • A customer-managed VM-Series firewall may run an affected PAN-OS release. Managed Cloud NGFW is a different product and is not affected.
  • A team needs a bounded repository change and operator handoff that separates upgrade, temporary prevention, and possible-compromise response.

Do not use this recipe to investigate a device by sending crafted requests or to perform an unapproved production firewall upgrade. If attempted exploitation or compromise is suspected, preserve evidence and route to human-led incident response before rebooting or changing the appliance.

Inputs

  • A redacted inventory of every potentially affected firewall and HA peer: owner, environment, hardware or VM-Series form factor, customer-managed or managed-service status, deployed PAN-OS release, and authoritative evidence timestamp.
  • GlobalProtect configuration evidence showing whether a gateway or portal is present. The vendor documents the web-interface locations as Network > GlobalProtect > Gateways and Network > GlobalProtect > Portals.
  • Exposure evidence: public or private listener, ingress path, allowed source networks, DNS/load-balancer mapping, and which interface receives GlobalProtect traffic.
  • Repository-controlled image references, marketplace identifiers, Terraform, configuration-as-code, Panorama templates, policy exports, upgrade runbooks, HA sequencing, maintenance window, health checks, and rollback plan.
  • Threat Prevention evidence: Applications and Threats content version, availability of Threat IDs 95187, 95189, and 95191, the vulnerability protection profile, and proof that the profile applies to the GlobalProtect interface.
  • Security operations evidence supplied through an approved channel: relevant alerts, centralized logs, TSF collection status, Palo Alto Networks support case, incident commander, and credential-rotation owner. Do not commit TSFs, configurations containing secrets, or raw customer logs to the repository.
  • The authorized boundary for appliance access. Unless the task explicitly grants live-change authority, the agent may change repository artifacts and prepare operator instructions only.

Affected versions

Exposure requires both an affected release and a configured GlobalProtect gateway or portal. Palo Alto Networks identifies these primary fixed baselines:

  • PAN-OS 10.2: 10.2.9-h1 and later.
  • PAN-OS 11.0: 11.0.4-h1 and later.
  • PAN-OS 11.1: 11.1.2-h3 and later.

The vendor also released courtesy hotfixes for commonly deployed older maintenance lines. Within each line below, releases before the listed hotfix are affected and the listed hotfix is the first fixed release:

PAN-OS line First fixed releases on older maintenance lines
10.2 10.2.0-h3, 10.2.1-h2, 10.2.2-h5, 10.2.3-h13, 10.2.4-h16, 10.2.5-h6, 10.2.6-h3, 10.2.7-h8, 10.2.8-h3, 10.2.9-h1
11.0 11.0.0-h3, 11.0.1-h4, 11.0.2-h4, 11.0.3-h10, 11.0.4-h1
11.1 11.1.0-h3, 11.1.1-h1, 11.1.2-h3

Select a currently supported, vendor-approved release compatible with the device, plugins, HA pair, and operational policy rather than pinning to an old minimum merely because it contains the CVE fix. Do not compare PAN-OS hotfix suffixes as ordinary decimal versions.

The vendor lists PAN-OS 9.0, 9.1, 10.0, and 10.1 as unaffected by this CVE. It also lists Cloud NGFW, Panorama appliances, and Prisma Access as unaffected. That does not make a PAN-OS firewall managed through Panorama unaffected, and it does not cover customer-managed VM-Series firewalls in AWS or Azure; those firewalls are affected when the release and GlobalProtect configuration match. Do not downgrade to an old unaffected PAN-OS branch as remediation.

Indicator-of-exposure

Classify each target independently:

  1. Product: It is a PAN-OS firewall or customer-managed VM-Series device, not managed Cloud NGFW, Panorama itself, or Prisma Access.
  2. Version: It runs PAN-OS 10.2, 11.0, or 11.1 below the applicable fixed threshold.
  3. Configuration: A GlobalProtect gateway or portal is configured. A portal alone is sufficient for the vendor’s exposure condition.
  4. Reachability: Untrusted traffic can reach that GlobalProtect surface. Reachability changes priority and containment, but a private listener does not change the vendor’s affected-version classification.

Use repository search only to locate candidate ownership and configuration; it does not prove the live appliance state:

rg -n -i "globalprotect|global-protect|pan-os|panos|vm-series|panorama|95187|95189|95191|8836-8695" .

Confirm effective version and configuration from an approved read-only inventory, signed export, or operator-provided screenshot. Do not infer the deployed version from a desired-state file alone. Do not send an exploit, path-manipulation cookie, command string, or vendor demonstration request to a firewall to prove exposure.

A correctly applied Threat Prevention profile can contain initial exploitation, but the device remains on vulnerable software until upgraded. Conversely, device telemetry being disabled proves neither containment nor lack of exposure.

Remediation strategy

  1. Run the evidence-preservation gate before reboot. Review approved alerts and operator-supplied evidence. If there is possible attempted exploitation, unexplained file activity, configuration access, unexpected processes, or interactive command execution, stop routine remediation. Palo Alto Networks says to collect a TSF for forensic analysis before rebooting into a fixed release because some prior-installation logs become inaccessible after the upgrade. Open a support and incident-response case.
  2. Upgrade to a fixed release. Move every affected firewall and HA peer to a vendor-supported release at or beyond the correct fixed threshold. Update all repository-controlled image references, marketplace identifiers, configuration baselines, inventory policy, runbooks, and generated artifacts together. Keep upgrade order, failover, health checks, maintenance impact, and rollback under human review.
  3. Apply vendor containment while rollout is pending. With a Threat Prevention subscription, use Applications and Threats content version 8836-8695 or later, enable Threat IDs 95187, 95189, and 95191, and ensure the vulnerability protection profile is actually applied to the GlobalProtect interface. This is temporary protection, not a replacement for the fixed PAN-OS release.
  4. Escalate when documented containment is unavailable. If the signatures cannot be applied correctly, prepare an operator decision to disable or isolate the affected GlobalProtect surface until upgrade. Do not make an availability-impacting change without the service owner and change authority.
  5. Treat suspected compromise as recovery, not patch management. Unit 42 observed activity ranging from unsuccessful probes to configuration-file access and interactive command execution. The vendor also documents post-exploitation persistence techniques and offers an enhanced factory reset (EFR) process through support. A fixed release prevents the initial vulnerability; it does not, by itself, establish that a previously compromised device is trustworthy.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2024-3400, a critical, known-exploited PAN-OS
GlobalProtect arbitrary-file-creation-to-command-injection vulnerability.
Produce exactly one output:

- A reviewer-ready PR/change request that updates repository-controlled PAN-OS
  release pins, policy/configuration artifacts, safe verification, operator
  upgrade/containment instructions, inventory evidence, and rollback, or
- `TRIAGE.md` when ownership, exposure, evidence preservation, incident
  response, live-device authority, or safe rollout cannot be resolved in this
  repository.

## Rules and guardrails

- Scope only CVE-2024-3400 and directly related PAN-OS version inventory,
  GlobalProtect exposure, Threat Prevention containment, upgrade artifacts,
  safe verification, and incident-response handoff.
- Do not connect to, scan, probe, or mutate a live firewall unless the task
  explicitly grants that exact authority. Repository authority is not appliance
  authority.
- Do not generate or send an exploit payload, crafted cookie, path traversal,
  command string, callback, file-write probe, or proof-of-concept request.
- Do not copy or execute active-request examples from advisories. Verification
  must use version/configuration evidence, policy tests, normal health checks,
  and approved logs.
- Treat TSFs, configuration exports, support bundles, certificates, secrets,
  user data, network topology, serial numbers, and raw logs as sensitive. Do not
  add them to Git or print them in PR logs.
- Do not reboot or upgrade a device with possible exploitation evidence before
  the incident owner decides whether a TSF and other evidence must be collected.
- Do not treat disabled device telemetry as mitigation. Telemetry does not need
  to be enabled for exploitation.
- Do not treat Threat IDs `95187`, `95189`, and `95191` as effective unless the
  required content is present and the vulnerability protection profile is
  applied to the GlobalProtect interface.
- Do not treat prevention signatures as a durable substitute for upgrading.
- Do not declare a device uncompromised because one indicator, log search, or
  alert is absent. Do not erase, clean, or alter suspected artifacts.
- Do not auto-merge, push appliance configuration, trigger failover, reboot,
  rotate credentials, or start an EFR procedure.

## Steps

1. Inventory repository ownership. Search PAN-OS/GlobalProtect image pins,
   Terraform, marketplace definitions, Panorama templates, configuration
   exports, policy-as-code, inventory, runbooks, generated artifacts, CI checks,
   and vulnerability exceptions. Record the files inspected.
2. Build a redacted target matrix with one row per firewall and HA peer:
   owner, product/form factor, customer-managed status, environment, current
   PAN-OS version and evidence date, GlobalProtect gateway/portal state,
   reachability, Threat Prevention content/profile state, desired fixed release,
   and repository control point.
3. Classify each row as one of:
   - `not affected`: an unaffected product/release, or no GlobalProtect gateway
     or portal, with authoritative evidence;
   - `vulnerable and exposed`: affected release plus gateway/portal;
   - `vulnerable with documented temporary containment`: affected release plus
     correctly applied vendor Threat Prevention controls;
   - `unknown`: missing or conflicting product, version, configuration, or
     deployment evidence.
4. Apply the incident-response gate before planning a reboot. Review only
   approved, already-available security evidence. If alerts, logs, support
   findings, or operator reports suggest attempted exploitation or compromise,
   stop routine patch work. Record the need to collect a TSF before reboot,
   preserve external logs, contact Palo Alto Networks support, and engage the
   incident owner. Do not investigate by probing the appliance.
5. For repository-controlled vulnerable targets without a compromise stop:
   - select a currently supported vendor release at or above `10.2.9-h1`,
     `11.0.4-h1`, or `11.1.2-h3`, as applicable, or use an exact older-line
     hotfix threshold listed in the Palo Alto Networks advisory when an approved
     compatibility constraint requires it;
   - update image/release pins, IaC, Panorama templates, inventory policy,
     runbooks, checks, and generated outputs consistently;
   - document HA peer order, compatibility, maintenance window, normal service
     health checks, rollback, and the human operator steps. Do not execute them.
6. If rollout cannot be immediate and the repository controls containment,
   require content `8836-8695` or later, Threat IDs `95187`, `95189`, and
   `95191`, and a vulnerability protection profile applied to the GlobalProtect
   interface. Keep a tracked removal/reevaluation condition after upgrade.
7. Add safe policy and rendering checks that fail when:
   - a controlled GlobalProtect target resolves below its applicable fixed
     threshold;
   - a temporary mitigation omits any required Threat ID, uses older content,
     or is not bound to the GlobalProtect interface;
   - an HA peer or generated deployment artifact remains on an old release;
   - a vulnerability exception lacks owner, expiry, evidence, and fixed target.
8. Validate repository artifacts with their normal schema, formatting, render,
   and policy tests. Verify expected GlobalProtect availability using existing
   non-adversarial health checks only. Record commands and results honestly;
   do not claim a live version or policy was observed unless evidence was
   supplied.
9. Add a PR section named `CVE-2024-3400 operator actions` containing:
   - the redacted target matrix and evidence timestamps;
   - before/after PAN-OS releases and the vendor threshold used;
   - gateway/portal exposure and reachability;
   - Threat Prevention content, IDs, profile, and interface binding;
   - TSF/evidence-preservation decision and incident owner;
   - HA sequencing, maintenance impact, health checks, and rollback;
   - support/EFR handoff if compromise is suspected;
   - remaining actions that require live-device authority.

## TRIAGE.md stop conditions

Stop and produce `TRIAGE.md` instead of a PR when any of these is true:

- No affected firewall, configuration, or deployment artifact is owned by this
  repository.
- Product type, deployed PAN-OS release, HA peer state, GlobalProtect
  gateway/portal state, or effective reachability cannot be proved from
  authoritative evidence.
- Attempted exploitation, unauthorized file activity, possible configuration
  access, unexpected process activity, or other compromise evidence exists.
- Evidence preservation or TSF collection must be decided before a reboot or
  upgrade.
- The selected fixed release/hotfix, marketplace image, plugin compatibility,
  hardware support, HA path, maintenance window, or rollback cannot be
  validated safely.
- Threat Prevention containment is required but the subscription, content,
  Threat IDs, profile, or GlobalProtect interface binding cannot be proved.
- Remediation requires live firewall access, failover, reboot, service outage,
  credential rotation, support-case action, or EFR authority not granted by the
  task.
- Meaningful verification would require a crafted request, exploit behavior,
  public scanning, sensitive-data access, or a destructive test.
- Repository validation fails for unrelated pre-existing reasons; record the
  failures without broadening this change.

`TRIAGE.md` must list the files and evidence inspected, redacted target/owner,
observed and required versions, gateway/portal state, reachability, temporary
mitigation state, compromise concern, TSF-before-reboot decision, blocking
authority or compatibility issue, next responsible human, and required next
action. Do not include TSFs, secrets, full configurations, raw customer logs,
or unredacted network details.

Stop conditions

  • Suspected attempted exploitation or compromise: preserve evidence, collect a TSF before reboot when the incident owner/vendor directs, and hand off to Palo Alto Networks support and incident response.
  • The repository does not own the affected firewall or its deployment/config artifacts.
  • Product, PAN-OS version, GlobalProtect gateway/portal state, reachability, HA state, or containment cannot be established with authoritative evidence.
  • A safe fixed release, supported upgrade path, maintenance window, HA plan, or rollback has not been approved.
  • The task would require live appliance mutation, an outage, credential rotation, active probing, or access to sensitive support artifacts beyond its authorization.

In each case, return TRIAGE.md with the evidence and ownership fields required by the prompt. Do not convert an incident-response stop into an ordinary patch PR.

Verification - what the reviewer looks for

  • Every controlled firewall and HA peer has authoritative, timestamped deployed version evidence; desired-state files are not the only proof.
  • Each GlobalProtect target resolves to a vendor-supported release at or beyond the applicable fixed threshold, including generated artifacts and cloud image references.
  • Gateway and portal configuration are both checked. A portal-only target is not incorrectly dismissed.
  • Temporary containment, when present, records content 8836-8695 or later, Threat IDs 95187, 95189, and 95191, and the profile binding to the GlobalProtect interface.
  • The change does not present disabled telemetry as protection and does not downgrade to an old unaffected branch.
  • HA order, compatibility, service health checks, maintenance impact, rollback, and human-only live steps are explicit.
  • Possible-compromise evidence causes a TSF/evidence-preservation and incident-response handoff before reboot rather than a patch-only outcome.
  • Tests are static, policy-based, or normal operational health checks. No exploit payload, crafted request, external callback, unauthorized scan, or destructive test was used.
  • Validation results distinguish what was checked in the repository from what an authorized operator must verify on the live appliance.

Guardrails

  • Never store a TSF, full running configuration, private key, credential, certificate, raw customer log, or unredacted topology in Git.
  • Never probe a public or production GlobalProtect endpoint to confirm the issue. Version and configuration evidence are sufficient for remediation.
  • Never reboot, fail over, or upgrade before the incident owner decides whether pre-reboot evidence is required.
  • Never use the absence of one known indicator as proof that a device is clean.
  • Never let Threat Prevention containment, a private listener, or disabled telemetry become a permanent vulnerability exception.
  • Never describe upgrade completion as compromise eradication. Recovery trust is an incident-response decision.

Output contract

Return one of:

  • A reviewer-ready PR/change request that inventories every controlled target, updates all PAN-OS/image/configuration references to an approved fixed release, adds safe policy checks, documents any temporary Threat Prevention containment, and supplies a human-reviewed HA upgrade, health-check, rollback, evidence-preservation, and operator-action plan.
  • TRIAGE.md containing the bounded evidence, owner, affected/fixed release, GlobalProtect exposure, containment state, compromise concern, TSF decision, authority/compatibility blocker, and next action when a safe repository change cannot be completed.

The output must state what was verified from repository artifacts, what came from operator evidence, and what remains unverified. It must not claim that a live firewall was patched, clean, or protected unless authorized execution evidence is supplied.

Watch for

  • Portal-only exposure. The vendor explicitly includes a GlobalProtect portal without a gateway.
  • Stale telemetry guidance. Disabling device telemetry is not effective and telemetry need not be enabled for exploitation.
  • Product-name confusion. Panorama itself, Prisma Access, and managed Cloud NGFW are unaffected, but customer-managed VM-Series and Panorama-managed PAN-OS firewalls can still match the exposure conditions.
  • Hotfix comparison mistakes. Compare against the exact maintenance-line threshold, not a hand-written decimal conversion. Palo Alto Networks notes that Azure marketplace hotfix naming can encode 11.1.2-h3 as 11.1.203.
  • Passive HA peers and stale artifacts. A fixed active peer does not prove its partner, disaster-recovery device, template, image, or next replacement instance is fixed.
  • Unbound prevention profiles. Having current Threat IDs on the device is not protection unless vulnerability protection applies to the GlobalProtect interface.
  • Patch-before-preservation. Rebooting into the fixed release can make some prior-installation logs inaccessible. Resolve TSF collection first when an investigation is needed.
  • Patch-only incident closure. Unit 42 documented configuration-file access and interactive command execution, while Palo Alto Networks documents possible persistence. A fixed release blocks initial exploitation but does not establish recovery trust for an already compromised device.
  • Sensitive evidence in review systems. TSFs and configuration exports can contain secrets and network details; retain them only in approved forensic or support channels.
  • CVE intelligence intake gate
    • use this first when the scanner record, product ownership, deployed version, or GlobalProtect exposure evidence is incomplete.

References