The tool you patch through also needs patching

Your team manages remediation tickets in ServiceNow. In July 2024, attackers went after ServiceNow itself. A significant portion of the organizations caught exposed had the same blind spot: the platform they use to track patching wasn’t in their patch program.

Three vulnerabilities disclosed July 10, 2024 (CVE-2024-4879, CVE-2024-5217, and CVE-2024-5178) gave unauthenticated attackers a path from the internet to ServiceNow’s user database. CISA added all three to the Known Exploited Vulnerabilities catalog on July 29 with a 21-day federal deadline — 19 days after patches were available. By that point, exploitation was already underway.

What the chain does

The primary entry point is CVE-2024-4879, a Jelly template injection flaw in ServiceNow’s UI macros. Jelly is ServiceNow’s internal XML-based scripting language. The bug lets an unauthenticated attacker inject executable code by sending a crafted POST to the /login.do endpoint — the instance login page, which is internet-reachable by design. No account required, no MFA to bypass, no phishing chain. The endpoint exists and the input isn’t sanitized.

CVE-2024-5217, an incomplete validation flaw in ServiceNow’s GlideExpression scripting engine, provides a second code execution path. Attackers chain the two: the first achieves execution, the second confirms database access and enables bulk queries. The second-stage payload Resecurity documented in their analysis dumps user lists and password hashes. Some instances exposed plaintext credentials. CVE-2024-5178 then adds filesystem access for administrative users, turning a credential dump into a foothold for deeper access.

The public PoC for CVE-2024-4879 appeared almost immediately after disclosure, and exploitation complexity is rated Low. You need a target list and a script, not a research team.

Who got hit and how

Resecurity estimated roughly 300,000 ServiceNow instances were reachable from the internet and identifiable via FOFA. Attackers scanned that population. BleepingComputer confirmed active credential theft; SC Media reported attacks escalating through late July. Victims included government agencies, energy providers, financial institutions, and software development firms across the US, UK, India, and the EU. Some stolen data was later advertised for sale.

This was mass exploitation against a known vulnerable population. Once PoC was public and instances were enumerable, every unpatched organization was in the same situation.

The patching gap

Most ServiceNow customers run the vendor-hosted deployment. ServiceNow manages the infrastructure: servers, OS patching, platform availability. That holds. What it doesn’t cover is the application-layer patches, the “Now Platform” upgrade bundles that ServiceNow releases by name (Utah Patch 10b Hot Fix 1, Vancouver Patch 10, Washington DC Patch 5 for these CVEs). Those require customer action, even on fully cloud-hosted instances.

The fix lives in Now Support. Applying it requires scheduling and executing the upgrade: a change request, a maintenance window, testing against customizations and integrations, sign-off from the platform team. None of that happens automatically.

This is documented behavior, not a flaw in ServiceNow’s update model. The gap is organizational. IT teams treat ServiceNow as infrastructure someone else manages, when the application-layer update cadence still sits with the customer. The ITSM platform becomes the thing nobody thought was their job to patch.

The MID server problem

Even primarily SaaS customers often have at least one MID server — ServiceNow’s on-prem proxy agent that connects internal infrastructure (endpoints, network devices, CMDB sources) to the cloud instance. MID servers are entirely customer-managed. OS patching, Java runtime updates, and the MID server application itself all belong to your team.

A MID server typically runs inside the corporate network with broad discovery permissions: it talks to endpoints, network devices, and databases to populate your CMDB. Compromising one doesn’t hand an attacker the ServiceNow cloud instance directly, but it gives them internal network footing with service-account-level reach to whatever the MID server was configured to discover. Deepwatch flagged this during the July 2024 wave as an underappreciated secondary risk.

Find your MID servers in the MID Server list (ecc_agent table) in your ServiceNow instance. Treat each one like a privileged server: confirmed patch state, confirmed OS version, confirmed that service account permissions haven’t drifted.

What to do

If you’re still running Utah, Vancouver, or Washington DC:

• Utah: Utah Patch 10b Hot Fix 1 or later
• Vancouver: Vancouver Patch 10 or later
• Washington DC: Washington DC Patch 5 or later

For later releases (Xanadu and beyond), check Now Support for your release family’s advisory. ServiceNow’s KB for CVE-2024-4879 lists the fixed version per release.

Before patching: pull your instance’s current version from Now Support (not from within the ServiceNow product itself). If you’re an admin, also check your MID server inventory and their current build versions; recent admin account creations or modifications; unusual POST traffic to /login.do in your web access logs; and bulk queries against the sys_user table in your audit log.

If patching will take weeks due to upgrade testing, change freeze, or integration validation: restrict access to the instance login endpoint to known IP ranges if your deployment supports it, increase audit logging, and make sure someone is actively watching the instance logs rather than just the tickets inside them.

The pattern

CISA listed these CVEs on July 29 with an August 19 deadline. Three weeks to patch a critical, actively exploited RCE in an internet-facing platform. That’s tight but not unusual for a KEV-listed bug with a public PoC.

What made it harder than it should have been is that many organizations hadn’t built a clear ownership path for “patch ServiceNow the product.” The ticketing system tracks patches. Nobody opened a ticket for this one.

It’s worth checking your ITSM platform right now: What release family is it on? When was the last upgrade? Who approves the change request? If those questions take more than ten minutes to answer, you’ve found the gap. The July 2024 campaign exploited exactly that.

PatchDayAlert covers CISA KEV additions daily, including enterprise application platforms that fall into the same ownership blind spot.

Sources

• CISA — Adds CVE-2024-4879, CVE-2024-5217, CVE-2024-5178 to KEV (July 29, 2024)
• NVD — CVE-2024-4879
• ServiceNow KB1645154 — CVE-2024-4879 Jelly Template Injection
• ServiceNow KB1648312 — CVE-2024-5178 SecurelyAccess API
• BleepingComputer — Critical ServiceNow RCE flaws actively exploited to steal credentials (July 2024)
• Dark Reading — Patch Now: ServiceNow Critical RCE Bugs Under Active Exploit
• Resecurity — CVE-2024-4879 and CVE-2024-5217 Exploitation in a Global Reconnaissance Campaign
• Deepwatch Labs — Attackers Exploit Chain of Vulnerabilities in ServiceNow to Dump User List
• SC Media — Attacks involving ServiceNow vulnerabilities escalate
• Indusface — CVE-2024-4879 & CVE-2024-5217 - RCE in ServiceNow
• FortiGuard Labs — ServiceNow Remote Code Execution Outbreak Alert
• CYFIRMA — ServiceNow RCE (CVE-2024-4879) Vulnerability Analysis and Exploitation
• TechInformed — ServiceNow issue turns SaaS patching into a data-exposure test