ServiceNow Just Promised Autonomous AI Security. Three Weeks Earlier, an Unauthenticated Attacker Was Already Inside.

On July 18, an unauthenticated attacker was running arbitrary code inside a ServiceNow instance - no credentials, no phishing, no foothold required. Three weeks later, on a Black Hat USA 2026 stage in Las Vegas, ServiceNow announced Autonomous Security: six unified solutions, AI Specialists that close vulnerabilities without waiting for a human, and a vision called Shift Zero - “zero exposure at all times,” with proof of what acted, why, and who is accountable.

The vulnerability that was actively exploited three weeks before that pitch, CVE-2026-6875, sits in the same platform the pitch is about. It carries a CVSS score of 9.5. It requires no credentials. It lets an attacker run arbitrary code inside the platform that ServiceNow says orchestrates more than 100 billion workflows a year. According to the researchers who found it, a successful exploit compromises not just the instance but every proxy server connected to it, including MID Servers.

The timing is either the worst luck in recent security history, or the sharpest object lesson in it. This post is a technical look at both: what Autonomous Security actually is, what CVE-2026-6875 actually is, and why the gap between them is exactly where enterprise platform owners should be paying attention.

Part 1: What ServiceNow Actually Announced

Let's start with the substance, because there is real substance here.

Autonomous Security is the acceleration of a vision ServiceNow has been building toward since it acquired Armis for $7.75 billion and Veza in 2025. Armis gives continuous, agentless visibility across connected assets: OT, medical devices, IoT, and billions of tracked devices. Veza's Access Graph maps effective permissions across human, machine, and AI identities. Both now feed what ServiceNow calls its AI Control Tower and Context Engine.

The announcement organises the portfolio into six solution areas:

1. Unified Exposure Management. Agentic Exposure Management consolidates vulnerability findings from every source into a single stream, enriched with early-warning threat intelligence and “Fix Intelligence” prioritised remediation. The headline addition is the Vulnerability Resolution AI Specialist, which orchestrates triage, executes low-risk patches, and turns exposure backlogs into closure pipelines on its own.
2. Continuous Vulnerability Detection. Application Security, extended to threat-model AI-generated code and model dependencies, Dynamic Application Security Testing, and External Attack Surface Management. The intent is to stop governing code, cloud, and infrastructure as three separate problems.
3. Cyber-Physical Security. Agentic AI for Cyber Physical Security delivers agentless discovery across OT and medical networks, behavioural baselines, continuous compliance validation, and attack-path modelling - the Armis heritage, productised with autonomous remediation workflows.
4. Identity and Access Security. AI Agent Access Security unifies access control for AI agents across any platform or model provider. Non-Human Identity Remediation goes beyond risk scoring into active action: automated key rotation, deprovisioning, and permission revocation at scale across IT, OT, IoT, and medical networks - the Veza heritage.
5. Agentic Incident Response. A Tier 2 SOC AI Specialist that autonomously builds and executes multi-phase response plans - enrichment, correlation, containment, and blocking - escalating only high-risk decisions to human analysts.
6. Cyber Risk and Compliance. Agentic AI for Continuous Control Monitoring turns control evidence into a continuous operational signal, evaluating segregation of duties, access rights, and configuration state in real time, with on-demand compliance reporting across SOC 2, ISO 27001, PCI-DSS, and HIPAA. It also includes Cryptographic Asset Compliance for the migration from legacy algorithms to quantum-resistant standards before the quantum threat window closes.

Availability matters here: most of the platform pieces are available now, but the four AI Specialists - the parts that actually do the work - are scheduled for December 2026.

The core argument is coherent and hard to argue with at the macro level. Security teams are losing the race against AI-driven risk. Machine identities double every 18 months. The average enterprise runs more than 70 disconnected security tools. No human team can triage, prioritise, and remediate at the pace agents generate exposure. If you are going to let AI create risk at machine speed, you need AI to contain it at machine speed - under governance, with audit trails, and with human escalation where judgement is required.

That is the pitch. Now let's look at what the platform shipped for real, three weeks earlier.

Part 2: What CVE-2026-6875 Actually Is

CVE-2026-6875 is a pre-authentication remote code execution vulnerability in the ServiceNow AI Platform, the renamed Now Platform. It is classified under CWE-94, Improper Control of Generation of Code, and rated 9.5 on the CVSS 4.0 scale: critical, maximum-severity territory for an unauthenticated RCE.

It was discovered by Adam Kues of Searchlight Cyber, who reported it to ServiceNow on April 1, 2026. ServiceNow remediated its hosted SaaS tenants over the following weeks - an important detail, because it means the patch existed for months before self-hosted customers got it - and shipped fixes for self-hosted customers and partners on July 13, 2026 under KB3137947. Five days later, on July 18, Defused observed the first in-the-wild exploitation attempts.

The timeline is stark: four months between report and self-hosted patch, five days between patch and exploitation, and three weeks between exploitation and the Autonomous Security launch.

The Attack Chain

The technical chain is worth walking through, because it shows exactly how thin the line between “sandboxed” and “game over” can be.

1. An unauthenticated endpoint. The entry point is /assessment_thanks.do, reachable without authentication on affected instances. An attacker who can send HTTP requests to an exposed instance needs no credentials, no phishing, and no prior foothold.
2. Attacker input reaches a query engine. A parameter on that endpoint, sysparm_assessable_type, flows directly into a GlideRecord query. This is the ServiceNow data access layer - the same query engine that underpins the platform's business logic.
3. JavaScript expressions are evaluated in filter context. ServiceNow's query engine supports JavaScript expressions inside filter values. A specially crafted filter value is evaluated before the query executes. In theory, this is confined by a sandbox that blocks eval, function declarations, and dangerous Java classes. In practice, the chain below walks out of it.
4. gs.include() runs in a less restricted context. The sandbox has a loophole: gs.include(), the mechanism for loading Script Includes. Searchlight Cyber demonstrated that Script Includes execute in a less restricted context than the surrounding sandbox. Chain those steps together - unauthenticated endpoint, raw parameter, JavaScript filter expression, gs.include(), arbitrary code execution - and you have a full pre-auth RCE.
5. Blast radius. Kues's warning is blunt: the flaw “allows a complete compromise of the ServiceNow instance as well as all connected proxy servers.” MID Servers, LDAP integrations, and any credential the instance holds are all in scope.

Why the “In the Wild” Part Matters More Than Usual

Defused's observation is the detail most coverage underplays: the live payloads hit the same /assessment_thanks.do entry point, but escape the sandbox through a different gadget chain than the public proof of concept. That is not a footnote.

If your defence strategy was “block the known exploit,” you are not defended. Signatures and detection rules written against the published proof of concept will miss the payloads defenders are actually seeing.

ServiceNow's official advisory still states it has not confirmed exploitation against the instances it hosts, and no APT has been publicly attributed. That may be true and still irrelevant to the people this actually affects: self-hosted and partner-managed instances, which were the population given the fix only on July 13, and which therefore had a months-long window where hosted tenants were patched but they were not.

The patch releases themselves are worth noting: Australia Patch 2, Yokohama Patch 12 Hot Fix 1b and Patch 13, Zurich Patch 7b and Patch 9, and Brazil EA and GA. The updates also ship a new platform capability called Guarded Script, which restricts the types of code allowed to run in sandbox contexts - an acknowledgement, from ServiceNow itself, that this class of flaw is structural, not a one-off.

Part 3: The Tension the Launch Does Not Address

Here is where the announcement and the vulnerability collide, and why platform owners should read them together.

Autonomous Security is, fundamentally, ServiceNow telling the market: trust the platform to secure the AI era - our platform, with AI Specialists that patch, contain, and remediate autonomously, under governance, at machine speed.

CVE-2026-6875 is the platform demonstrating, in production, that its own sandbox - the control that separates harmless input from arbitrary code execution - was escapable through a developer feature, by an unauthenticated attacker, in a way that a threat researcher found and the vendor did not. It was exploited in the wild five days after the self-hosted fix shipped, using a technique the published proof of concept did not describe. And the AI platform at the centre of the security pitch is the same platform where the vulnerability lived.

This is not a gotcha, and it is not a reason to abandon the platform. Every platform that reaches ServiceNow's scale has critical vulnerabilities. This class of bug is endemic to enterprise software that runs attacker-influenced logic. What the juxtaposition does is define the actual question enterprise platform owners should be asking:

When an AI Specialist is authorised to execute low-risk patches and rotate keys autonomously, what exactly is governing the platform's own trust boundary?

The AI Control Tower governs the agents you deploy: inventory, risk tiering, policy, and audit. But governance is only as strong as the underlying platform's security primitives. If an unauthenticated attacker can escape the script sandbox via gs.include(), then every agent running on that platform is running on a trust boundary that already failed once. Governance without a hardened foundation is paperwork.

There is also a less obvious operational point. The same gs.include()mechanism that enabled this exploit is a core developer tool. The security update that closes the hole ships alongside Guarded Script, which restricts what code can run in sandbox contexts. Every ServiceNow team running custom scripts, Script Includes, or workflow logic now has a new surface to validate: not just “did we patch,” but “does our existing code still behave correctly under the new sandbox restrictions, and do we know which of our Script Includes do things they are no longer allowed to do?”

Part 4: What to Actually Do About It

For anyone running ServiceNow, hosted or self-hosted, the immediate checklist is unchanged by any amount of framing:

1. Patch. Today. Self-hosted instances must be on Australia Patch 2, Yokohama Patch 12 Hot Fix 1b or Patch 13, Zurich Patch 7b or Patch 9, Brazil EA or GA, or later. The five-day gap between patch and exploitation is already closed. Attackers are not waiting.
2. Block the endpoint until patching is confirmed everywhere. Restrict access to /assessment_thanks.do at the network or WAF layer. Blocking it breaks the legitimate post-assessment landing page. That is an acceptable trade for an RCE.
3. Audit logs for exploitation, not just for the known proof of concept. Look for requests to /assessment_thanks.do with javascript: in parameters, unusual gs.include() calls, unexpected Script Include creation, and outbound connections from the instance process. Remember: the live payloads use a different gadget chain than the public proof of concept. Hunt for the primitive, not the signature.
4. Assume any internet-facing self-hosted instance was targeted between July 13 and patching, and triage accordingly.
5. Treat downstream compromise as in scope. The researcher's warning means MID Servers and connected proxies are in the blast radius. Rotate service-account secrets that touched the instance before you finished patching.
6. Hosted tenants: confirm your instance family actually received the backport. ServiceNow says its hosted fleet is not seeing this activity. Verify your own instance, rather than taking a vendor-level statement as instance-level assurance.
7. Plan for Guarded Script. Enable it after patching, but validate your custom Script Includes and workflow code against the stricter sandbox before you assume everything still runs.

Separately, at the architecture level: when you deploy AI Specialists that are authorised to remediate autonomously - whether ServiceNow's in December, or any agentic security tooling - treat the platform's own security posture as part of the risk model. Governance is not a dashboard. It is knowing what is running, what it can touch, and whether the boundaries underneath it are actually sound.

The MainStack View

We are ServiceNow people. We have built delivery platforms on this ecosystem, run them through production for enterprise clients, and we spend our days on the unglamorous layer that sits between “the AI can do this” and “the AI may do this.” We say this as practitioners, not as doomsayers:

Autonomous Security is a genuinely strong direction, and the Armis and Veza assets give it substance most security-portfolio announcements lack. But the launch landed three weeks after a critical, actively exploited sandbox escape in the platform it is built on. That is not a contradiction to dismiss and not a scandal to amplify. It is the clearest possible illustration of the gap between the AI's capabilities and the platform's own security maturity.

Enterprises do not need to choose between “adopt agentic AI” and “secure the platform.” They need to do both, in that order of difficulty: secure the foundation first, then let the agents run. The teams that treat platform hardening, sandbox validation, and agent governance as one problem instead of three are the teams that will be able to answer the question ServiceNow's own Shift Zero asks - what acted, why, and who is accountable - with something better than a policy document.

If you are running AI Specialists with autonomous remediation rights, or planning to when they ship in December, what is actually validating the platform underneath them?

MainStack helps enterprises harden ServiceNow foundations and govern autonomous AI through AI Control Tower. If you need to validate your platform's security posture before extending agentic remediation rights, we can scope the assessment in a working session.

Related: AI Control Tower · Now Assist