PAN-OS: three-CVE chain and an exposed admin interface

On 12 February 2025 Palo Alto Networks published advisories for CVE-2025-0108 and CVE-2025-0111. In both documents the vendor states that it has observed exploitation attempts in which these defects are used together with the earlier CVE-2024-9474, published on 18 November 2024. The targets were devices running unpatched PAN-OS versions whose web management interface was reachable from untrusted networks. The status of the event matters: this is a record of observed attempts, not a confirmed compromise of specific hosts and not a disclosure of affected organizations.

For an on-call engineer the useful conclusion lies in the access mechanics, not in the number of identifiers. Risk appears where two factors overlap: network reachability to the management interface, and missing patches. Where the interface is not reachable from external networks, the first link of the chain has no technical starting point.

How the chain works

The Palo Alto Networks advisories contain no step-by-step attack instructions, but they do describe clearly what each defect allows. It is the combination of those capabilities that makes an exploit chain.

Link one — CVE-2025-0108: authentication bypass

CVE-2025-0108 (vendor tracker PAN-273971) is an authentication bypass in the web management interface. According to vendor documentation, an unauthorized user with network access to the interface can bypass the credential check and invoke certain PHP scripts. The limitation the vendor states is important: on its own this vulnerability does not allow remote code execution. It affects the confidentiality and integrity of PAN-OS data by exposing functionality that should be hidden from anonymous users. Turning that access into something dangerous to the system requires a next step.

Link two — CVE-2024-9474: privilege escalation

CVE-2024-9474, with an advisory dated 18 November 2024, is a privilege escalation issue classified as OS command injection (CWE-78). Here a hard requirement appears: exploitation needs a PAN-OS administrator account, so the attacker must already hold admin-level access to the management console. Where that condition is met, actions can be performed at root level on the firewall.

Link three — CVE-2025-0111: authenticated file read

CVE-2025-0111 (PAN-273994) is a file read by an authenticated user. With access to the web interface obtained through the first link, an attacker can read files on the PAN-OS file system that are available to the nobody user.

The chain is built sequentially. CVE-2025-0108 gets past the front door. Data or file-read functionality from CVE-2025-0111 is then likely used to obtain or restore administrator access, or to prepare the environment. The final step goes through CVE-2024-9474, which turns administrator actions into root-level ones. Without a reachable management interface, none of these steps can be initiated from an external network.

What an exposed interface actually means

Palo Alto Networks states explicitly that risk is highest when access to the management interface is allowed directly from the internet or from other untrusted networks. The vendor also makes an important nuance explicit: public reachability is not the only technical predisposing factor. Risk remains where the interface is reachable from an internal network that is treated as trusted but may contain compromised hosts.

In practice it looks like this. Many organizations deploy firewalls so that the management port listens only on an internal segment. To an external scan such a device looks closed. If a GlobalProtect profile is configured on the same interface, the picture changes. The advisory notes that GlobalProtect portals and gateways are not themselves vulnerable, except where a management profile makes the web management interface reachable through those interfaces, typically on port 4443.

The version dependency

Patch prioritization is not possible without knowing the current software version. The three vulnerabilities affect different PAN-OS release trains, and the fixed releases differ.

CVE-2025-0108 and CVE-2025-0111: affected version ranges

Release train 10.1: before 10.1.14-h9.
Release train 10.2: before the corresponding maintenance releases, including 10.2.13-h3.
Release train 11.1: before the stated fixes, including 11.1.6-h1.
Release train 11.2: before 11.2.4-h4 or 11.2.5.

The vendor also notes that PAN-OS 11.0 and older releases that have reached End-of-Life are considered vulnerable, and scheduled fixes are not issued for them. If devices like these remain in the infrastructure, they stay in the risk zone indefinitely.

CVE-2024-9474: affected versions and products

For CVE-2024-9474 the list of affected versions is broader. Release trains 10.1, 10.2, 11.0, 11.1 and 11.2 are affected before the base fixed releases:

10.1 before 10.1.14-h6.
10.2 before 10.2.12-h2.
11.0 before 11.0.6-h1.
11.1 before 11.1.5-h1.
11.2 before 11.2.4-h1.

The product line covered includes PA-, VM- and CN-Series firewalls, Panorama systems (virtual and M-Series) and WildFire appliances. Cloud NGFW and Prisma Access are not on the list of affected products.

This means the version check is the first filter. If a device has been updated to the latest stable releases of the trains listed above, this specific CVE combination is ruled out as an attack vector. If the version is old, the question moves to the network: where can the management interface be reached from at all?

Where the chain could have been broken

Consider the point at which the attack would stop before the command execution stage. The first weak spot is the network access configuration. The vendor recommends restricting access to the management interface to trusted internal IP addresses only, for example through a jump box. That lowers the risk without removing it, since the jump box can become a target in turn.

A stronger barrier is the complete absence of a route from an untrusted zone to the management interface. If an external scanner sees no response on the management port, the exploit logic breaks at the first step. How serious the authentication flaw is inside the code does not matter if the packet never reaches the listening socket.

The second weak spot is perimeter change monitoring. Often the problem is not that someone deliberately opened a port, but that the configuration changed. A new interface was added, an extra channel for roaming staff was connected, debug mode was switched on. A static inventory taken six months ago says nothing about the current state. What is needed is a mechanism that regularly checks which ports actually respond on the organization's public IP addresses.

If such a check shows that the management port (usually 443, 8443, or the ports specific to GlobalProtect) responds from an external address, that is not necessarily a tooling error, but it is a departure from the intended security architecture and calls for immediate review. An engineer may have forgotten to remove a temporary access rule for remote support. A management profile may have been bound to an external interface by accident.

How to check your own systems today

There is no need to wait for an incident to find out whether your management interface is visible from outside. The steps below can be carried out in-house or handed to the team that monitors the perimeter.

Collect the list of external IP addresses. Take every public address registered to your organization or used by firewalls in NAT mode.
Check the management ports. Run an active scan of those addresses. The ports of interest are the ones typical of PAN-OS web interfaces. The standard HTTPS port is often used for management where it is not separated from user traffic. Check port 4443 as well if GlobalProtect is in use.
Assess the result. A closed port is the good case: even where vulnerabilities exist in the code, the network path to exploit them is absent. An open, responding port puts the device in the higher-risk group, and the PAN-OS version on it needs to be checked straight away.
Check the GlobalProtect profiles. If you use GlobalProtect, confirm that the management profile is not bound to internet-facing interfaces. The advisory names this configuration directly as a source of risk.

For step three, the version decides what happens next:

If the version matches the vulnerable list above, the device needs an urgent update, or the interface needs isolating from the external network.
If the version has been updated to a fixed release, the risk from this specific chain is low, but a management port open to the internet remains poor practice and a possible door for future vulnerabilities.

No response to a scan does not prove a device is secure. Hidden tunnels or other vectors may exist. What it does remove is the main risk factor described in the context of these three CVEs, and for prioritizing patch work that factor is decisive: start with the devices that are both running an old version and visible from outside. The rest can be handled within the normal update cycle.

This task calls for regular checks rather than a single pass. The perimeter changes: new branches appear, providers change, cloud connectors are added. A one-off check says nothing about whether someone opens a port for diagnostics tomorrow and forgets to close it. Monitoring changes in external topology makes such an event visible at the moment it happens, rather than after the fact, once a chain of three CVEs has become a live threat to a specific piece of hardware.

PAN-OS: a chain of three CVEs and the cost of an exposed management interface