CVE-2026-6875: Pre-Auth RCE in ServiceNow AI Platform Now Actively Exploited

ServiceNow's AI Platform — the workflow engine that hums quietly behind IT help desks, HR portals, and vendor management systems at the majority of large enterprises — has a critical pre-authentication remote code execution vulnerability. CVE-2026-6875 was disclosed publicly on July 13, 2026. Four days later, exploitation in the wild began. By July 18, threat intelligence firm Defused had confirmed attackers were using a second sandbox-escape technique that bypasses defenses tuned to the published proof-of-concept.

If any of your vendors, managed service providers, or enterprise software partners run ServiceNow — and statistically, many of them do — this matters to your business even if you have never opened a ServiceNow tab yourself.

What the Vulnerability Is

The root of CVE-2026-6875 is deceptively simple: ServiceNow's GlideRecord API — which underpins hundreds of locations in the platform's codebase — accepts user-supplied data and passes it into database queries. When an attacker prefixes a value with javascript:, ServiceNow evaluates the string as JavaScript before using it as a query argument. That JavaScript runs inside ServiceNow's server-side script sandbox, which was supposed to contain it.

The sandbox escape is the second act. Researchers at Searchlight Cyber, who discovered and responsibly disclosed the bug in April, found they could override Object.clone using the Function constructor and manipulate AbstractAjaxProcessor.prototype — giving them code execution outside the sandbox's restrictions. The entry point is the /assessment_thanks.do endpoint via the sysparm_assessable_type parameter, which passes unsanitized user input directly into a GlideRecord query. No authentication required, no login, no token.

The Defused researchers' finding that attackers are reaching the same code-execution primitive via a different gadget chain is the more alarming detail: it means simply blocking or signature-matching on the published PoC leaves organizations exposed. There are multiple roads to the same destination.

What Happens After Exploitation

Once an attacker has code execution on a ServiceNow instance, the blast radius is broad:

• Full database access — every table the instance can read, which often includes employee records, vendor contracts, IT asset inventories, and sensitive ticket data
• Admin account creation — attackers can quietly add backdoor administrator accounts and maintain persistence through credential rotation
• Lateral movement via MID Servers — ServiceNow's MID Server proxies sit inside corporate networks and relay traffic between the cloud instance and internal systems; code execution on a MID Server means an attacker has a foothold inside your vendor's internal network
• Credential harvesting — integration credentials, API keys, and service account details stored in the platform are accessible

ServiceNow processes more than 100 billion enterprise workflows annually and powers over 100,000 enterprise AI applications at 85% of Fortune 500 companies. The supply-chain exposure that flows from a compromised instance is substantial.

Patch Timeline and Who Is Still at Risk

Searchlight Cyber reported the vulnerability to ServiceNow on April 1, 2026. ServiceNow patched hosted (SaaS) instances in April — the vast majority of their customer base. Security updates for self-hosted instances were distributed via advisory KB3137947 on July 13, 2026, the same day Searchlight Cyber published their public disclosure.

Self-hosted deployments are the immediate risk. These are organizations that run ServiceNow on their own infrastructure rather than consuming the SaaS product — typically larger enterprises with specific data sovereignty or compliance requirements. If those self-hosted instances haven't been updated since July 13, they are vulnerable and actively being probed.

As a defensive measure going forward, ServiceNow introduced Guarded Script — a new sandbox mode that restricts executable code to single simple expressions, closing off the class of nested-constructor abuse that enabled this escape. It's a deeper architectural fix rather than a surface-level patch.

Why This Hits Businesses That Don't Run ServiceNow

Most small and mid-size businesses don't run ServiceNow directly. But supply-chain exposure doesn't require you to operate the vulnerable software yourself. Consider:

• Your managed IT provider may use ServiceNow to manage tickets, assets, and change requests for your environment — their compromise is a pivot point into your systems
• Enterprise vendors you share data with (payroll processors, benefits administrators, logistics providers) commonly use ServiceNow to manage vendor relationships and store contract data
• Any organization that has your data and runs a compromised ServiceNow instance can inadvertently expose it via the platform's connected MID Server or database tables

This is the uncomfortable reality of modern SaaS sprawl: the security perimeter is only as strong as the weakest platform in your extended partner ecosystem.

What to Do Right Now

If your organization or any of your IT service providers runs ServiceNow:

• Verify patch status immediately — confirm the July 13 update (KB3137947) has been applied on any self-hosted instances; hosted instances should already be patched, but verify with your ServiceNow account team
• Audit /assessment_thanks.do logs — look for unusual requests containing javascript: in sysparm_assessable_type or other parameters, particularly from unfamiliar source IPs
• Review admin accounts — check for newly created administrator or service accounts you don't recognize; attacker-created backdoor accounts are a common persistence mechanism
• Restrict external exposure — if ServiceNow doesn't need to be reachable from arbitrary internet IPs, network-level controls should limit access
• Ask your vendors — any managed service provider or enterprise software partner that uses ServiceNow should confirm patch status and be able to show you audit logs on request

The fact that Defused has already documented a second exploitation path means that waiting on patching isn't a risk-management decision — it's just risk accumulation. Patches are available, the vulnerability is trivially exploitable without credentials, and scanning is underway.

At Falcon Internet, supply-chain visibility is part of how we think about infrastructure security — not just hardening the servers we manage directly, but understanding what's upstream. When a critical flaw in a widely deployed enterprise platform gets weaponized inside a week of disclosure, it's a reminder that your network boundary is broader than your own firewall.