Is CVE-2024-9465 (Palo Alto Networks Expedition SQL Injection) being exploited in the wild?

Yes. CISA added CVE-2024-9465 to its Known Exploited Vulnerabilities catalogue on 14 November 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Palo Alto Networks Expedition contains a SQL injection vulnerability that allows an unauthenticated attacker to reveal Expedition database contents, such as password hashes, usernames, device configurations, and device API keys.

What CISA’s KEV listing means for this CVE

CISA’s Known Exploited Vulnerabilities catalogue is the key signal here, because it is reserved for flaws with reliable evidence of active exploitation. For CVE-2024-9465, that means the answer is not just “possible exploitation,” but “yes, exploitation in the wild is established enough to trigger CISA prioritisation.”

The practical implication is that this is a prioritisation problem, not a theoretical review item. Treat the vulnerable Palo Alto Networks Expedition instance as exposed until you confirm whether it is present, reachable, and already remediated or contained.

For the authoritative record, cross-check the entry in the CISA Known Exploited Vulnerabilities Catalog and the vulnerability metadata in CVE Program and NIST National Vulnerability Database rather than relying on second-hand summaries.

Why this SQL injection flaw is operationally dangerous

This is not a narrow data-only issue. The direct answer says the SQL injection is unauthenticated and can expose Expedition database contents, including password hashes, usernames, device configurations, and device API keys. That makes the flaw especially useful to an attacker because one foothold can yield multiple downstream assets in one pass.

Once those values are exposed, the risk extends beyond the Expedition application itself. Password hashes can support credential cracking, usernames help with targeting and correlation, device configurations can reveal topology or management details, and API keys can become an access path into adjacent systems if they are still valid.

The attack pattern is consistent with the broader SQL injection class, where input handling failures turn a web-facing interface into a database disclosure path. For a fast refresher on the mechanism and the kinds of controls that break the chain, see the SQL Injection Prevention Guide.

What to check first on an Expedition deployment

Start with exposure, not with assumptions about patch state. Confirm whether Expedition is deployed anywhere in the environment, whether it is reachable from untrusted networks, and whether it has been internet-facing or otherwise exposed long enough to be a likely target.

Then focus on evidence of access to the impacted data. If the system stored database content that includes credentials, device records, or API material, treat those objects as potentially exposed even if you have already applied a fix. A SQL injection issue of this type can create a silent data-loss event rather than an obvious service outage.

If you need a practical model for prioritising exploited issues and verifying remediation, use the Vulnerability Management Guide and the Zero-Day and Exploited Vulnerabilities Guide as a playbook for urgency, compensating controls, and post-fix validation.

Risk and Threat Considerations

The main risk is credential and configuration exposure through a pre-authentication database read. That can turn a single web application flaw into broader administrative access, lateral movement, or device-management compromise if the leaked material is still usable elsewhere.

Failure mechanism: An unauthenticated SQL injection flaw allows an attacker to query Expedition’s backend database, extract sensitive records, and reuse any recovered hashes, usernames, device configuration data, or API keys to extend access beyond the original application.

Impact: Expect possible account compromise, device-management exposure, and follow-on intrusion risk across systems that trust the leaked secrets or configuration details.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Exploit evidence makes rapid prioritisation and remediation central.
Recommendation — Prioritise, remediate, and verify the exploited Expedition flaw immediately.
NIST SP 800-53 Rev 5	SI-10 — Input Validation	SQL injection is an input-handling failure that this control directly addresses.
	IA-5 — Authenticator Management	Leaked hashes and API keys require credential lifecycle action and rotation.
Recommendation — Enforce input validation to prevent SQL injection paths in exposed applications. Rotate exposed credentials and revoke any secrets recovered from the database.
OWASP ASVS	V4 — API and Web Service Security	The flaw is a web-service injection issue with data disclosure impact.
	V1 — Encoding and Sanitization	SQL injection prevention depends on correct handling of untrusted input.
	V14 — Data Protection	The issue exposed sensitive database contents, so data protection controls matter.
Recommendation — Verify server-side request handling and database access controls for the affected web surface. Apply strict input handling and parameterisation to block injection vectors. Protect stored secrets and sensitive records with stronger access and encryption controls.

Practitioner Guidance

What to prioritise: Treat any exposed Expedition deployment as a live incident candidate, not just a patching task. If the application handled operational credentials or device-management data, prioritise secret rotation and exposure review before assuming the vulnerability was only a web-layer issue.

What to verify: Confirm whether any leaked password hashes, usernames, or API keys are reused anywhere else in the environment. If they are, assume the blast radius extends beyond Expedition and validate whether those credentials were active at the time of exposure.

Practitioner takeaway: For an exploited SQL injection with secrets exposure, the decision point is not “patched or unpatched,” but “what data and access paths may already have been exposed and now need validation or rotation.”