In July 2024, ServiceNow disclosed and patched three critical vulnerabilities that, when chained together, allowed unauthenticated remote code execution on ServiceNow instances. Within a week, active exploitation was observed in the wild, and within two weeks, tens of thousands of reconnaissance attempts were hitting exposed ServiceNow instances.
The three vulnerabilities are:
- CVE-2024-4879 (CVSS 9.3): Jelly template injection allowing unauthenticated remote code execution.
- CVE-2024-5217 (CVSS 9.2): Incomplete input validation in the GlideExpression script, enabling secondary code execution.
- CVE-2024-5178 (CVSS 6.9): Unauthorized file read allowing access to sensitive configuration files.
Individually, each vulnerability is serious. Chained together, they provide a complete attack path from zero access to full system compromise.
Understanding the Attack Chain
ServiceNow uses a server-side templating engine called Jelly, based on Apache Commons Jelly, to render dynamic web pages. Jelly templates are XML-based and can execute arbitrary Java code through embedded expressions.
Step 1: Template Injection (CVE-2024-4879)
Certain ServiceNow UI pages, accessible without authentication, process user-supplied input through the Jelly template engine without proper sanitization. An attacker can inject Jelly template expressions into URL parameters or form fields. These expressions are evaluated server-side, providing initial code execution.
The injection point was found in the login and public-facing widget pages, meaning no authentication was required. A crafted HTTP request to a vulnerable endpoint could execute arbitrary Jelly expressions, which in turn could invoke Java methods on the server.
Step 2: Escalation via GlideExpression (CVE-2024-5217)
While CVE-2024-4879 provided code execution within the Jelly template sandbox, the GlideExpression vulnerability allowed breaking out of that sandbox. GlideExpression is ServiceNow's internal scripting framework, and insufficient input validation allowed injected expressions to escalate to unrestricted server-side code execution.
Step 3: File Read for Persistence (CVE-2024-5178)
With code execution established, CVE-2024-5178 allowed reading arbitrary files from the ServiceNow server, including database credentials and encryption keys. This information enabled attackers to maintain persistent access even after patching.
Exploitation in the Wild
The timeline of exploitation was rapid:
- July 10, 2024: ServiceNow releases patches and advisories.
- July 11, 2024: Researchers at Assetnote publish detailed technical analysis.
- July 12-13, 2024: Proof-of-concept exploit code appears on GitHub.
- July 15-16, 2024: Threat intelligence firms report widespread scanning and exploitation attempts.
- July 22, 2024: CISA adds CVE-2024-4879 to the Known Exploited Vulnerabilities (KEV) catalog.
Resecurity and Imperva reported observing exploitation attempts targeting ServiceNow instances across multiple industry sectors, including government, financial services, and healthcare. Attackers were using the vulnerability chain to:
- Extract database credentials and user data.
- Access integrated systems via stored API keys and OAuth tokens.
- Plant web shells for persistent access.
- Exfiltrate sensitive records from IT service management databases.
Why ServiceNow Is a High-Value Target
ServiceNow is not just an IT ticketing system. In modern enterprises, it serves as a central nervous system for:
- IT Service Management (ITSM): Incident tickets, change requests, and configuration management databases (CMDBs) contain detailed information about an organization's infrastructure.
- Security Operations (SecOps): Security incident response workflows, vulnerability management data, and threat intelligence feeds.
- HR Service Delivery: Employee personal information, payroll data, and organizational structure.
- Business Process Automation: Workflows that connect to and control other enterprise systems via APIs and integrations.
Compromising a ServiceNow instance often means gaining access to credentials and integration tokens for dozens of other systems. The CMDB alone provides a roadmap of the target's entire IT environment.
Scope of Exposure
ServiceNow is deployed in over 7,700 enterprises globally, including 85% of Fortune 500 companies. While many large enterprises run ServiceNow on-premises or in dedicated cloud instances, a significant number of mid-market deployments use ServiceNow's SaaS offering, where patching is managed by ServiceNow.
Self-hosted and customer-managed instances were at particular risk because patching depended on the customer's own change management process. Organizations with slow patch cycles or complex testing requirements found themselves exposed for weeks after patches were available.
Shodan scans revealed thousands of ServiceNow instances directly accessible from the internet, many running vulnerable versions well into August 2024.
Mitigation and Remediation
Apply patches immediately. ServiceNow released patches for all supported versions (Utah, Vancouver, and Washington DC families). The patches address all three CVEs.
For organizations unable to patch immediately:
- Block public access to ServiceNow instances using a WAF or network-level restrictions. The attack requires direct HTTP access to the instance.
- Review access logs for indicators of compromise. Look for unusual requests to login pages or public widget endpoints with atypical URL parameter lengths or content.
- Rotate credentials for all integrations, especially database credentials, API keys, and OAuth tokens stored in ServiceNow. If an attacker exploited CVE-2024-5178, these credentials should be considered compromised.
- Audit user accounts for newly created admin accounts or modifications to existing account permissions.
Post-patch actions:
Even after patching, organizations should assume compromise may have occurred during the exposure window and conduct a thorough investigation:
- Review audit logs for the period between July 10 and the date of patching.
- Check for web shells or unauthorized files in the ServiceNow file system.
- Verify that no unauthorized admin accounts were created.
- Rotate all stored credentials and API tokens.
Lessons Learned
The ServiceNow vulnerability chain reinforces several important principles:
Template injection is still a critical attack vector. Despite being well-understood, server-side template injection continues to appear in enterprise applications. Any framework that evaluates user-supplied input as template expressions is at risk.
Internal applications are not safe from unauthenticated attacks. Many organizations treated their ServiceNow instances as "internal" applications, despite being accessible from the internet. Public-facing login pages and widgets created an unauthenticated attack surface.
Patch velocity matters. The window between patch release and active exploitation was measured in days, not weeks. Organizations that required multi-week change management processes for patching were exposed for the entire duration.
How Safeguard.sh Helps
ServiceNow is a critical supply chain component in most enterprises, integrating with dozens of other systems.
- Dependency and integration mapping identifies ServiceNow as a central node in your software supply chain and maps all systems that depend on it, helping you understand the blast radius of a compromise.
- Vulnerability alerting provides immediate notification when critical CVEs affect components in your environment, including platform-level vulnerabilities like CVE-2024-4879.
- Patch compliance tracking monitors whether critical patches have been applied within your defined SLA windows, highlighting instances that remain exposed.
- Risk scoring factors in the criticality and connectivity of components like ServiceNow, ensuring that vulnerabilities in highly integrated platforms are prioritized appropriately.
When a platform as central as ServiceNow is vulnerable, the entire supply chain is at risk. Visibility is the first line of defense.