CVE-2024-4879

What it actually does

CVE-2024-4879 is an unauthenticated remote code execution vulnerability caused by improper input validation in ServiceNow Now Platform Vancouver and Washington DC releases. A remote attacker can send specially crafted input to a vulnerable instance and cause server-side execution in the context of the Now Platform without credentials or user interaction. Successful exploitation can allow access to platform data, execution of platform-side logic, manipulation of records and workflows, and potential access to secrets, integrations, or credentials available to the ServiceNow application context.

Why it matters to the business

This is a critical, internet-exploitable vulnerability with active exploitation observed in the wild, CISA KEV listing, and an extremely high EPSS score, meaning exposed unpatched instances should be treated as likely targets. Compromise of a ServiceNow instance can disrupt IT service management, security operations, HR, customer service, asset management, and automation workflows, while exposing sensitive operational data, tickets, user information, approvals, configuration items, and integration credentials. The CISA remediation deadline was 2024-08-19, so any remaining unpatched or unverifiable instance represents a serious governance and operational risk.

How an attack unfolds

An attacker first identifies a ServiceNow Now Platform instance running an affected Vancouver or Washington DC release. Because the vulnerability requires no authentication, the attacker can directly send crafted HTTP requests containing malicious input to the exposed ServiceNow web interface. The vulnerable platform component fails to properly validate that input and processes it in a way that permits attacker-controlled code or script logic to execute in the Now Platform context. After achieving execution, the attacker may test execution with benign commands or lookups, then enumerate platform configuration, users, roles, records, workflows, attachments, and integration settings. Follow-on actions can include data theft, creation or abuse of privileged accounts or API tokens, modification of workflows and business rules, persistence through platform artifacts, and use of stored credentials or integrations to move into connected systems.

How to fix it

Apply the ServiceNow security patches or hot fixes for all affected Vancouver and Washington DC Now Platform releases immediately. ServiceNow stated that updates were applied to hosted instances, but organizations should still verify patch status in the ServiceNow support/HI portal or with ServiceNow support; partners and self-hosted customers must ensure the relevant vendor-provided update has been installed. If immediate patching is not possible, restrict network access to ServiceNow administrative and web interfaces using VPN, identity-aware proxy, trusted IP allowlists, or equivalent controls; disable unnecessary public exposure; increase logging; and monitor for exploitation attempts. Review platform users, roles, scripts, business rules, scheduled jobs, integrations, OAuth/API credentials, and recently modified records after patching, because remediation does not remove attacker-created persistence or stolen data.

How to confirm the fix worked

Confirm the instance is no longer running an affected Vancouver or Washington DC build and that the relevant ServiceNow security hot fix or patch is installed. Validate through the ServiceNow support portal, instance version/build information, vendor patch advisory, and change records. From outside the trusted network, confirm that only intended ServiceNow endpoints are reachable and that administrative access is restricted. Review web access logs and platform logs for exploit-pattern requests before and after patching; after remediation, known exploit payloads should fail and should not result in server-side execution, unexpected outbound callbacks, new administrative artifacts, or unauthorized record changes. Also validate that no unauthorized users, roles, business rules, scripts, scheduled jobs, integrations, or API/OAuth credentials were created during the exposure window.

Typical attack path

1. Scan the internet or target inventory for exposed ServiceNow Now Platform instances.
2. Fingerprint the instance release or attempt exploitation against endpoints associated with the affected Vancouver and Washington DC releases.
3. Send unauthenticated crafted HTTP requests containing malicious input to trigger server-side execution in the Now Platform context.
4. Validate execution through observable output, timing behavior, DNS callbacks, or changes in platform state.
5. Enumerate users, roles, records, tables, attachments, workflows, integrations, and configuration data accessible to the platform context.
6. Exfiltrate sensitive records or files and harvest credentials, tokens, or integration secrets where accessible.
7. Establish persistence by creating or modifying platform users, roles, business rules, scripts, scheduled jobs, integrations, or other administrative artifacts.
8. Use the compromised platform to disrupt workflows, manipulate records, impersonate business processes, or pivot through trusted integrations.

How to detect it

Investigate ServiceNow web access logs, reverse proxy/WAF logs, CDN logs, application logs, audit logs, user and role audit history, script/business rule change history, scheduled job history, integration/OAuth/API token activity, and outbound network telemetry. Look for unauthenticated requests to ServiceNow endpoints containing unusual template, scripting, Java, runtime, command execution, or callback strings, especially requests to login or public endpoints with suspicious parameters. Search for evidence of command validation such as whoami, id, uname, nslookup, curl, wget, PowerShell, cmd.exe, or outbound DNS/HTTP callbacks to attacker-controlled infrastructure. In the platform, review newly created or modified administrative users, role grants, business rules, script includes, scheduled scripts, UI actions, flows, integrations, OAuth applications, API tokens, and attachments created around the exposure window. If exploitation is suspected, also examine data access patterns for bulk reads, unusual exports, attachment downloads, or access to sensitive configuration and credential-related records.

• /login.do?jvar_page_title=
• jvar_page_title=
• j:jelly
• <j:jelly
• </j:jelly>
• gs.getProperty
• GlideRecord
• Packages.java.lang.Runtime
• java.lang.Runtime.getRuntime
• getRuntime().exec
• ProcessBuilder
• cmd.exe
• /bin/sh
• /bin/bash
• powershell
• whoami
• uname -a
• nslookup
• curl
• wget
• /xmlhttp.do
• /api/now/
• sysparm_query=
• sysparm_processor=
• sysparm_scope=
• sysparm_name=
• sysparm_value=

What your security team should do

• Treat any unverified Vancouver or Washington DC ServiceNow instance as high priority because the vulnerability is in CISA KEV, has active exploitation in the wild, and has an EPSS score near 1.0.
• Immediately verify patch or hot-fix status for all hosted, partner-managed, and self-hosted ServiceNow instances; escalate any unpatched instance for emergency remediation.
• If patch status cannot be confirmed quickly, restrict public access to the instance and require access through trusted network controls until the vendor fix is verified.
• Perform a compromise assessment covering the period before patching through the present, with emphasis on unauthenticated web requests, suspicious platform scripting artifacts, new privileged users, changed roles, and new or modified integrations.
• Rotate credentials and secrets that may be accessible to ServiceNow, including API keys, OAuth credentials, integration accounts, and service accounts, if exploitation is suspected or cannot be ruled out.
• Audit administrative users, role assignments, business rules, script includes, scheduled jobs, UI actions, workflow changes, MID Server configuration, and outbound integrations for unauthorized changes.
• Monitor for exploit attempts using request patterns involving suspicious ServiceNow parameters, server-side template/script markers, Java/runtime references, command execution strings, or outbound DNS/HTTP callbacks.
• Preserve relevant web logs, application logs, audit history, and platform configuration snapshots before cleanup to support investigation and potential incident response.