CVE-2024-5217

What it actually does

This is an unauthenticated remote code execution flaw caused by insufficient input validation in affected ServiceNow Now Platform releases, including Washington DC, Vancouver, and earlier releases. A remote attacker can submit specially crafted input to the platform and cause attacker-controlled code or server-side logic to execute in the context of the Now Platform without needing valid credentials. Successful exploitation can compromise platform confidentiality, integrity, and availability, including access to sensitive records, modification of workflows or configuration, and disruption of platform services. The supplied package metadata also references moodle/moodle fixed at commit e8d03fdae4ec30a40cdc535c8e9e95f30604ec10; because that conflicts with the ServiceNow advisory details, affected-product inventory should be reconciled against authoritative vendor advisories before closure.

Why it matters to the business

Compromise of a ServiceNow environment can affect core business workflows such as IT service management, change management, HR, customer support, asset management, and integrations with downstream systems. Attackers may steal sensitive operational data, alter approvals or tickets, create persistence through accounts or scripts, disrupt service delivery, or use stored integration credentials to pivot elsewhere. This issue is listed in CISA KEV, has observed exploitation in the wild, and has a very high EPSS likelihood score of 0.99628; the CISA remediation deadline of 2024-08-19 has already passed, so any remaining exposure should be treated as urgent.

How an attack unfolds

An attacker first identifies an internet-accessible affected Now Platform instance and fingerprints its release or patch level. The attacker then sends a crafted unauthenticated HTTP request containing input designed to bypass the platform's disallowed-input validation. If the instance is vulnerable, the payload is interpreted by server-side platform components and executes within the Now Platform security context. From there, the attacker can enumerate data, access application records, create or modify users and roles, deploy malicious scripts or scheduled logic, tamper with workflows, extract credentials or integration tokens, and use outbound integrations or stored secrets for follow-on activity. Public exploitation has been reported, and opportunistic scanning should be expected for unpatched instances.

How to fix it

Apply the relevant ServiceNow June 2024 security patches and hot fixes for Washington DC, Vancouver, and earlier Now Platform releases immediately. Confirm the instance is on a vendor-designated fixed build for its release family, not merely a later-looking but unpatched build. If the affected-product data in dependency tooling references moodle/moodle, validate that finding separately and ensure moodle/moodle is at commit e8d03fdae4ec30a40cdc535c8e9e95f30604ec10 or later where applicable; do not treat the Moodle package metadata as a substitute for ServiceNow patch validation. Where immediate patching is not possible, reduce exposure by restricting access to administrative and unauthenticated endpoints, enforcing strong network allowlisting for management access, applying WAF rules for suspicious encoded template/script payloads, disabling unnecessary public access, and monitoring closely. If exploitation is suspected, rotate platform credentials, integration secrets, OAuth tokens, API keys, and credentials stored for outbound integrations after containment and patching.

How to confirm the fix worked

Confirm remediation by checking the platform release, build, and hotfix level against the ServiceNow security advisory and the June 2024 patch matrix for the exact release family in use. Validate that all production, development, test, clone, and disaster-recovery instances are patched, not only primary instances. Review external attack-surface inventories to ensure no forgotten or cloned instance remains on an affected version. For dependency or source-code inventories that report moodle/moodle, verify the deployed revision is e8d03fdae4ec30a40cdc535c8e9e95f30604ec10 or later where that package is genuinely present. Confirm compensating controls by reviewing WAF, proxy, and access-control policies for blocking or alerting on suspicious encoded server-side template/script constructs. Finally, run post-patch monitoring for failed exploit attempts and verify that no unauthorized accounts, roles, scripts, scheduled actions, or integration changes were introduced before remediation.

Typical attack path

1. Discover internet-facing ServiceNow Now Platform instances through scanning, search engines, or prior asset lists.
2. Fingerprint the instance version, build, or patch posture to identify Washington DC, Vancouver, or earlier vulnerable releases that lack the June 2024 fixes.
3. Send unauthenticated crafted requests containing malformed or encoded input intended to bypass validation controls.
4. Trigger server-side code execution in the context of the Now Platform.
5. Run reconnaissance inside the platform to identify users, roles, sensitive records, workflows, integrations, and stored credentials or tokens.
6. Establish persistence by creating or modifying accounts, roles, scripts, business logic, scheduled jobs, or integration configuration.
7. Exfiltrate sensitive data, manipulate operational workflows, disrupt platform availability, or pivot through integrations to connected systems.

How to detect it

Search web server, CDN, WAF, reverse-proxy, and platform transaction logs for unauthenticated requests containing encoded XML, template, script, or command-execution markers, especially requests that generated 400 or 500 errors followed by successful responses. Review platform audit and administrative logs for unusual changes to users, roles, scripts, scheduled jobs, workflows, business rules, integrations, OAuth clients, API credentials, and outbound connection settings. Look for abnormal spikes in unauthenticated traffic, probing of login or UI endpoints, requests with long encoded parameters, repeated input-validation failures, or payloads containing server-side expression markers. Correlate suspicious requests with subsequent administrative actions, new sessions, unusual data exports, or outbound network connections. Include threat-intelligence and vulnerability-scanner telemetry for exploitation of this KEV-listed ServiceNow input-validation RCE, and pay particular attention to activity before patch installation because public exploitation has been observed.

• /login.do?jvar_page_title=
• jvar_page_title=
• <j:jelly
• %3Cj%3Ajelly
• <g:evaluate
• %3Cg%3Aevaluate
• ${jndi:
• java.lang.Runtime
• getRuntime().exec
• ProcessBuilder
• Packages.java.lang
• /bin/sh -c
• cmd.exe /c
• powershell -enc
• wget http
• curl http
• base64 -d

What your security team should do

• Treat this as an emergency remediation item for any exposed affected instance because it is KEV-listed, actively exploited, and past the CISA due date.
• Immediately inventory all ServiceNow Now Platform instances, including non-production, cloned, regional, and partner-managed instances, and map each to its release and hotfix level.
• Apply the vendor June 2024 patches or hot fixes for Washington DC, Vancouver, and earlier releases, then verify the fixed build through the vendor-supported method.
• Place temporary WAF, CDN, reverse-proxy, or network controls in front of exposed instances to block suspicious encoded template/script payloads until patching is complete.
• Hunt for prior exploitation across platform logs, web access logs, WAF/CDN telemetry, proxy logs, identity logs, and administrative audit trails for at least the period since public disclosure, and longer where log retention permits.
• Review recent creation or modification of privileged users, role assignments, scripts, scheduled jobs, business logic, inbound and outbound integrations, OAuth clients, API tokens, and service accounts.
• If suspicious activity is found, preserve logs and forensic artifacts, isolate administrative access, rotate credentials and integration secrets, and perform incident response before returning the instance to normal operation.
• Reconcile the conflicting affected-product metadata with authoritative vendor advisories so that vulnerability management does not incorrectly close a ServiceNow exposure based on unrelated package data.