Is CVE-2024-29824 (Ivanti Endpoint Manager (EPM) SQL Injection) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 17, 2026 Domain: Cyber Security

Yes. CISA added CVE-2024-29824 to its Known Exploited Vulnerabilities catalogue on 2 October 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Ivanti Endpoint Manager (EPM) contains a SQL injection vulnerability in Core server that allows an unauthenticated attacker within the same network to execute arbitrary code.

How to interpret an exploited-in-the-wild SQL injection finding

This question is not just about whether a CVE exists, but whether the vulnerability has crossed from theory into active abuse. Once a flaw is in CISA’s Known Exploited Vulnerabilities catalogue, the operational assumption should shift to exposure, triage, and compromise assessment, not curiosity about exploitability. The practical question becomes: where is the product deployed, what can it reach, and what evidence shows abuse?

SQL injection remains especially dangerous when it sits in a management or server-side component, because attackers do not need a user click or a client-side foothold to start. If the vulnerable service is reachable on an internal network segment, same-network access may still be enough to turn a single injection point into code execution and broader environment access. That is why these findings should be handled as incident-priority vulnerabilities rather than routine patch backlog items.

For authoritative tracking, use the CVE Program to confirm the record and the CISA Known Exploited Vulnerabilities Catalog to confirm that the issue is being treated as actively exploited. CISA placement matters because it changes prioritisation, exception handling, and the urgency of compensating controls.

What to check first on Ivanti Endpoint Manager deployments

Start with asset inventory and exposure mapping. Identify every Ivanti Endpoint Manager installation, then verify which instances are internet-facing, which are reachable only from internal subnets, and which have administrative or database connectivity that could amplify a successful injection. The key question is not simply whether the software is present, but whether the vulnerable Core server path can be invoked from any trusted network segment.

Next, determine whether the environment has already shown signs of abuse. Review web, application, database, and endpoint telemetry for unusual query patterns, unexpected process creation from the EPM server, new local accounts, task creation, service modification, and suspicious outbound connections. SQL injection that leads to server-side execution often leaves evidence outside the application itself, so the hunt must span multiple telemetry layers.

The most useful external references for this stage are the NIST National Vulnerability Database for record-level details and the FIRST EPSS service when you need a risk-prioritisation view alongside KEV status. NVD helps confirm the vulnerability record and associated metadata, while EPSS can support internal prioritisation when many exploitable items compete for attention.

One practical shortcut is to treat the vulnerable server as a potential pivot point, not just an application host. If the EPM service has access to directory services, management interfaces, or software deployment functions, compromise can spread quickly across the environment even without a public-facing exploit chain.

Risk and Threat Considerations

Actively exploited SQL injection in a management platform creates a dual risk: immediate remote code execution and downstream trust abuse from a system that is often allowed to administer others. Even when the attacker starts with only same-network access, the impact can extend well beyond the application boundary if the server stores credentials, can reach other management planes, or runs with elevated service permissions.

Failure mechanism: The attacker abuses unsanitised server-side input to alter a database query, then leverages the resulting application control to execute commands, steal data, or pivot into adjacent systems. In management software, that often turns a single web request into a broader administrative foothold.

Impact: Expect possible compromise of the EPM server, credential exposure, unauthorized software deployment, and lateral movement into managed endpoints or supporting infrastructure. Because KEV-listed flaws are already being used in the wild, defenders should assume opportunistic scanning and follow-on exploitation are both plausible.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	SQL injection exploitation is a public-facing app attack path.
Recommendation — Map EPM exposure and hunt for exploitation of the vulnerable server path.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	KEV-listed flaws require asset identification and exposure review.
	PR.PS-05 — Configuration Management	Mitigation depends on hardening or isolating the vulnerable service.
Recommendation — Inventory Ivanti EPM instances and prioritise the exploited CVE. Apply compensating configuration controls while remediation is pending.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Actively exploited vulnerabilities require disciplined flaw remediation.
	AU-6 — Audit Record Review, Analysis, and Reporting	Investigation depends on reviewing logs for exploitation evidence.
Recommendation — Remediate the vulnerable EPM installation on an emergency timeline. Review application and server logs for signs of SQL injection abuse.

Practitioner Guidance

What to prioritise: Treat the vulnerable EPM instance as a high-priority exposure until you can prove the affected path is absent, remediated, or effectively isolated. If patching must wait, reduce reachable surface immediately and increase monitoring around the server and any connected management systems.

What to verify: Confirm whether the server has administrative reach, stored service credentials, or database access that could widen the blast radius. If compromise is suspected, validate whether attacker activity touched accounts, tasks, scripts, package repositories, or remote management channels.

Practitioner takeaway: A KEV-listed SQL injection in management software should be handled as a potential compromise path, not a standalone code flaw, because the real risk is the trust and control the server already has.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org