CVE-2024-5910

What it actually does

The flaw is a missing-authentication weakness in a critical Palo Alto Networks Expedition administrative function. An attacker who can reach the Expedition web interface over the network can trigger functionality that enables Expedition administrator account takeover without valid credentials. Once administrative access is obtained, the attacker can view, modify, export, or delete data managed by Expedition, including imported firewall configurations, migration data, credentials, secrets, and other sensitive operational information. Because Expedition is commonly used during firewall migration and tuning workflows, compromise can also expose downstream network architecture and security policy details.

Why it matters to the business

Compromise of Expedition can expose firewall configurations, credentials, shared secrets, and security policy data that attackers can use to move deeper into the network or plan follow-on attacks. The vulnerability is listed in CISA KEV, has been observed exploited in the wild, has a very high EPSS score, and the CISA remediation deadline of 2024-11-28 is long past, so any reachable unpatched instance should be treated as urgent. Operationally, an attacker could disrupt migration projects, tamper with configuration data, or force broad credential and secret rotation across affected security infrastructure.

How an attack unfolds

An attacker first identifies a network-reachable Expedition instance. Because the vulnerable administrative function does not properly require authentication, the attacker sends a crafted request to the exposed Expedition web application to take over or reset control of an Expedition administrator account. The attacker then authenticates as an Expedition administrator and accesses the application normally. From there, they can enumerate imported projects and devices, retrieve firewall configuration data, harvest stored credentials or secrets, create additional persistence inside the application, modify migration artifacts, and potentially use the stolen information to target firewalls, VPNs, management interfaces, or other infrastructure. In real-world activity, this type of access may be chained with other Expedition vulnerabilities or post-exploitation tooling to obtain files, execute commands, or exfiltrate sensitive data.

How to fix it

Upgrade Palo Alto Networks Expedition to a fixed release immediately; for this issue, use Expedition 1.2.92 or later, or the latest vendor-supported release. If Expedition is not actively required, shut it down or remove it. Restrict Expedition access to trusted administrative networks only, preferably through a VPN or dedicated management network, and block direct internet exposure. After patching, rotate all credentials, API keys, shared secrets, SNMP strings, VPN secrets, and other sensitive values that were imported into or stored in Expedition. Review Expedition administrator accounts and remove unknown or unnecessary users. If exploitation is suspected, preserve evidence, rebuild the Expedition host from trusted media, restore only known-good data, and perform a broader investigation for use of stolen firewall or network credentials.

How to confirm the fix worked

Confirm the installed Expedition version is 1.2.92 or later, or a newer vendor-supported fixed version. Verify the Expedition web interface is not reachable from untrusted networks or the public internet. Test that the previously vulnerable administrative restore/reset function cannot be invoked without authentication and returns an authorization failure or is unavailable. Review access-control rules, reverse proxies, and firewall policies to confirm only approved administrative sources can reach Expedition. After remediation, check that administrator passwords and stored secrets have been rotated and that no unexpected Expedition accounts, projects, scheduled jobs, web files, or configuration exports remain.

Typical attack path

1. Discover an internet- or network-accessible Palo Alto Networks Expedition web interface.
2. Confirm the target is running a vulnerable Expedition version or exposes the vulnerable administrative restore/reset functionality.
3. Invoke the unauthenticated critical function to take over or reset an Expedition administrator account.
4. Log in to Expedition with administrator privileges.
5. Enumerate projects, imported firewall configurations, stored credentials, secrets, and migration artifacts.
6. Export or exfiltrate sensitive configuration data and credentials.
7. Optionally create additional accounts, modify configurations, deploy web shells, or chain with other vulnerabilities for deeper system compromise.
8. Use harvested information to target firewalls, VPNs, management systems, or other internal infrastructure.

How to detect it

Review web server logs for unauthenticated requests to Expedition administrative restore or reset functionality, especially requests to /OS/startup/restore/restoreAdmin.php from unknown, internet, scanning, or non-administrative source IP addresses. Primary log sources include Apache or HTTPD access logs, Expedition application logs, authentication logs, reverse proxy logs, VPN logs, EDR telemetry, and firewall flow logs. Look for a request to the vulnerable endpoint followed shortly by successful Expedition administrator login, project enumeration, configuration export, file downloads, account creation, or unusual outbound traffic. Investigate any use of default or recently reset administrator credentials, unexpected changes to Expedition users, and abnormal access to imported firewall configurations or secrets. On the host, look for web shells or modified files under the Expedition web root, unexpected cron jobs, suspicious child processes spawned by the web server, archive files containing exported configurations, and outbound connections to unfamiliar infrastructure. Because exploitation has been observed in the wild and the issue is in KEV, absence of endpoint telemetry should not be treated as proof of no compromise; if logs are missing or rotated, perform credential rotation and host rebuild for high-risk exposed systems.

• /OS/startup/restore/restoreAdmin.php
• GET /OS/startup/restore/restoreAdmin.php
• POST /OS/startup/restore/restoreAdmin.php
• GET /OS/startup/restore/restoreAdmin.php HTTP/1.1" 200
• POST /OS/startup/restore/restoreAdmin.php HTTP/1.1" 200
• restoreAdmin.php
• /var/log/apache2/access.log
• /var/log/httpd/access_log
• /var/www/html/OS/startup/restore/restoreAdmin.php

What your security team should do

• Immediately identify all Palo Alto Networks Expedition instances and determine whether any are reachable from the internet or broad internal networks.
• Prioritize patching or decommissioning because this vulnerability is in CISA KEV, exploitation is active in the wild, EPSS is very high, and the KEV due date has passed.
• Upgrade to Expedition 1.2.92 or later, preferably the latest available vendor-supported release.
• Restrict Expedition to a dedicated management network or VPN and deny access from untrusted source ranges.
• Assume credentials and secrets stored in Expedition may be exposed; rotate firewall credentials, API keys, VPN/shared secrets, SNMP strings, service accounts, and other imported secrets.
• Review Expedition administrator accounts, login history, configuration exports, and project access for unauthorized activity.
• Hunt for unauthenticated requests to the vulnerable restore/reset endpoint and suspicious follow-on administrator logins.
• If suspicious activity is found, preserve logs, isolate the host, rebuild Expedition from trusted media, and investigate downstream use of harvested credentials or firewall configuration data.
• Monitor for chaining with other Expedition vulnerabilities, web shell deployment, unusual outbound connections, and unauthorized access to firewall or VPN management systems.