ServiceNow customers who haven’t yet patched two critical remote code execution vulnerabilities should treat their instances as compromised – not merely exposed – after the Cybersecurity and Infrastructure Security Agency added both flaws to its Known Exploited Vulnerabilities catalog. The move confirms that attackers are actively exploiting CVE-2024-4879 and CVE-2024-5217, which together allow unauthenticated access and full system takeover on unpatched deployments.

The agency’s July 29 designation upended the usual vulnerability-management timeline. Instead of routine patching cycles, it demands immediate containment and verification for internet-facing instances. For Windows and IT operations teams who live through emergency patches for Microsoft Exchange or Server flaws, the pattern is familiar: public reachability plus unauthenticated code execution equals a potential disaster that can’t wait for a change control board.

The vulnerabilities: Unauthenticated code execution across three release families

The two flaws were disclosed on July 10, 2024, by ServiceNow. CVE-2024-4879 and CVE-2024-5217 both allow remote, pre-authentication attackers to execute arbitrary code on affected versions of the Now Platform. The vulnerable releases include the Utah, Vancouver, and Washington DC families – collectively covering nearly every on-premises and partner-managed deployment not recently upgraded.

ServiceNow says it applied updates to its cloud-hosted instances automatically. Self-hosted customers and partners received the patches and hot fixes directly. But that distinction – “ServiceNow hosts us” versus “our specific instance is remediated” – is where many organizations slip. A functioning login page does not prove the underlying hot fix was applied, and a vendor statement about updates doesn’t eliminate the need for customer-side verification.

Who is affected and what’s at stake

If your organization uses ServiceNow for any line-of-business workflow – IT service management, HR case handling, customer service portals – you need to answer three questions immediately:

  1. Who owns the instance? Determine whether it runs in ServiceNow’s cloud, on a partner’s infrastructure, or in your own data center. The responsibility for patching shifts accordingly, but the urgency does not.
  2. What version and patch level are you running? Check the exact release family (Utah, Vancouver, or Washington DC) and the full patch number. Compare it against the fixed baselines listed below.
  3. Is the instance reachable from the public internet? If yes, and you can’t confirm the patch, you should assume it’s vulnerable until you can prove otherwise.

A compromised ServiceNow platform can deliver far more than a messy ticket queue. Because the platform usually sits at the center of enterprise operations, an attacker who executes code can pivot to connected identity stores, ERP systems, HR databases, and collaboration tools. In many networks, ServiceNow has a privileged position that makes post-exploitation movement swift and damaging.

Fixed baselines: Utah, Vancouver, Washington DC

ServiceNow’s advisory and an alert from the California Cybersecurity Integration Center specify the minimum patch levels required to close these vulnerabilities:

  • Utah → Utah Patch 10b Hot Fix 1
  • Vancouver → Vancouver Patch 10
  • Washington DC → Washington DC Patch 5

If your instance runs any version of these families below the listed baselines, it is vulnerable. Even if you think you patched, verify against the production instance – not a development or test clone. A patch that sat in a non-production environment but never reached the live system leaves the door wide open.

CISA’s KEV listing means active exploitation is occurring

On July 29, 2024 – 19 days after the initial disclosure – CISA placed both CVEs into its Known Exploited Vulnerabilities catalog. The agency reserves this list for flaws that it has evidence are actively being used in attacks. This is not a theoretical threat; threat actors already have exploits in hand and are scanning for vulnerable instances.

The KEV listing also triggers a binding operational directive for U.S. federal agencies, which must remediate by a set deadline, but the warning applies equally to state and local governments, critical infrastructure, and private enterprises. For any security team, that designation should flip the switch from “we’ll schedule a patch” to “we need a containment-and-patch plan today.”

How we got here: A summer of service-platform risks

The timeline illustrates how quickly a platform vulnerability can escalate from disclosure to active campaign.

  • July 10, 2024 – ServiceNow publishes advisories for CVE-2024-4879 and CVE-2024-5217, providing patches to hosted, partner, and self-hosted customers.
  • July 26, 2024 – The California Cybersecurity Integration Center issues a formal alert, citing both CVEs and specifying the fixed baselines. The alert underscores the combination of unauthenticated access and remote code execution as particularly dangerous.
  • July 29, 2024 – CISA adds the two flaws to its KEV catalog, noting active exploitation.

Throughout this period, ServiceNow emphasized that cloud-hosted instances were patched by the vendor. For self-hosted and partner-managed environments, the responsibility fell squarely on the customer. The window between disclosure and KEV listing highlights a perennial truth: once a patch is released, attackers reverse-engineer it and weaponize the vulnerability within days. Organizations that waited more than two weeks to act were likely under active attack.

What to do now: A practical playbook

Stop reading if you haven’t already verified your ServiceNow instance status. The following steps apply regardless of ownership model.

1. Identify ownership and tenancy

If your ServiceNow subscription is pure SaaS – that is, ServiceNow hosts the platform and you consume it as a service – log into the ServiceNow support portal or contact your account representative. Ask explicitly: “Was my production instance included in the July 2024 CVE-2024-4879/5217 remediation?” Get written confirmation. Do not assume a working portal equals a patched one.

For partner-managed or self-hosted instances, the onus is on you or your partner. Demand details: which instance, which release family, which patch level, and when it was applied. A vague “we handle all patches” response should be treated as a red flag.

2. Check the version and patch level

Navigate to the instance’s system information or use the stats.do or version.do endpoint to retrieve the exact release and patch identifier. Do not rely on hearsay or a support ticket subject line. Compare the patch number directly with the fixed baselines above.

If you’re uncertain which release family your instance belongs to, remember the families are distinct: Utah, Vancouver, Washington DC. Even if your version sounds “later” (for example, “Washington DC” sounds newer than “Vancouver”), the advisory lists specific patches for each. A newer family name does not guarantee safety.

3. Contain unverified, internet-facing instances

If you can’t confirm the patch immediately and the instance is accessible from the internet, restrict access now. This doesn’t mean taking down the entire service permanently. Use network controls, firewalls, or VPN enforcement to limit access to corporate IP ranges, trusted partners, and known integration points.

For a marketing self-service portal that must remain public, the decision is harder, but the risk of leaving a vulnerable RCE surface exposed likely outweighs the business interruption. Document the restriction as an emergency security measure, not a permanent architectural fix. Tell the business owner what will stop working and when you expect to restore full access after remediation.

4. Apply the patch (if self-hosted or partner-managed)

Once containment is in place, schedule and apply the appropriate patch or hot fix as an emergency change. The fixed releases are:
- Utah: upgrade to Utah Patch 10b Hot Fix 1 or later
- Vancouver: upgrade to Vancouver Patch 10 or later
- Washington DC: upgrade to Washington DC Patch 5 or later

After applying, recheck the version number on the production instance. Then, document the change, the patch source, and the verification method. This record will be essential for audits and incident response.

5. Investigate for post-exploitation activity

Patching closes the vulnerability but does nothing to reveal what might have already happened. If your instance was exposed and unpatched between July 10 and the time you remediated, assume compromise until your security team determines otherwise. Review ServiceNow access logs, integration executions, and any unusual scripted actions. Look for new admin users, suspicious scheduled jobs, or data exports. Engage incident response resources if you find anomalies.

For Windows admins managing ServiceNow as a platform

Many organizations place ServiceNow under a shared-services group that includes Windows infrastructure teams. Even if you don’t own the application, you may be responsible for network exposure, identity integration, or the underlying OS in a hybrid deployment. Here’s what you can do right now:

  • Ask the ServiceNow owner to provide written evidence of patch status. If they can’t produce it within hours, advocate for access restrictions.
  • Review firewall rules that expose the instance to the internet. Identify which rules can be tightened without breaking critical workflows.
  • Check for signs of lateral movement from the ServiceNow server to Windows hosts in your environment. If the platform was compromised, an attacker might have moved to a domain controller, file server, or database.

Outlook: The internet-facing enterprise platform problem

CVE-2024-4879 and CVE-2024-5217 are not isolated incidents. In recent years, similar unauthenticated RCE flaws have hit platforms like Atlassian Confluence, VMware vCenter, and Microsoft Exchange. The common thread: when a critical business application sits at the edge of the internet and a vulnerability allows code execution with no credentials, attackers will weaponize it within weeks – or days.

For ServiceNow specifically, the active exploitation does not mean every instance was breached. But it does mean that any instance still running a vulnerable version should be treated as if it were. The CISA KEV designation is a forcing function: it tells security teams to stop debating and start acting.

What to watch next: service-platform vendors may accelerate automatic patching for cloud tenants and strengthen hosted-versus-self-hosted transparency. Meanwhile, expect regulators and cyber insurers to ask pointed questions about whether your instance was patched before July 29, 2024. If you haven’t already, make sure you can answer that question with evidence, not assumptions.