Decoding the world of cybersecurity

ServiceNow AI flaw draws active attacks

Attackers have reportedly exploited a critical ServiceNow AI Platform flaw against customer-managed deployments after the vendor protected its hosted instances.

ServiceNow AI flaw draws active attacks
Summary
  • CVE-2026-6875 permits unauthenticated sandbox escape and remote code execution.
  • ServiceNow says hosted instances were mitigated rapidly, while customer-managed deployments received fixes.
  • Hosting model determines who owns patching, exposure reduction, telemetry, and post-incident investigation.

Attackers have reportedly begun exploiting a critical vulnerability in the ServiceNow AI Platform, days after technical details of the unauthenticated code-execution path became public.

CVE-2026-6875 allows an attacker to escape the platform’s Guarded Script sandbox and execute code without authentication. The affected scripting function is intended to constrain user-supplied or generated logic, but the flaw enabled restricted syntax to be bypassed and commands to reach the underlying environment.

Security researchers disclosed the vulnerability to ServiceNow in April. The vendor says it mitigated hosted customer instances within 24 hours and distributed fixes for customer-managed deployments before publishing its security advisory on 13 July.

Threat intelligence company Defused subsequently reported attempted exploitation beginning on 18 July. The observed payload reached the same unauthenticated execution sink described by the original researchers but used a different route from the published proof of concept, indicating that attackers had developed or obtained an alternative exploit chain.

ServiceNow said it had found no evidence that the reported activity affected instances hosted by the company. Customer-managed deployments remain the principal area of concern, particularly where available fixes were not installed before exploitation began.

The original research showed that successful exploitation could reach data tables, create administrative users, and execute shell commands through connected proxy infrastructure. The exact result depends on deployment architecture and permissions, although ServiceNow frequently occupies a privileged position across service management, asset inventories, operational workflows, support processes, and automation.

An attacker able to modify workflows, create privileged identities, or access service records could interfere with incident response, obtain infrastructure information, or use trusted automation to reach connected systems. The platform’s central role can give one application weakness a broader organisational reach than an isolated web service.

Hosted and customer-managed versions of the same product carry different operating models. A software-as-a-service provider can deploy a platform-wide mitigation, monitor shared telemetry, and remove vulnerable code without waiting for separate customer change windows. A customer-managed instance depends on local ownership, patch scheduling, network controls, and the organisation’s ability to identify exposed components.

Asset and procurement records do not always preserve that distinction. An organisation may describe itself simply as a ServiceNow customer even though responsibility for patching, proxy nodes, evidence retention, and exposure varies between deployments. Incident response needs to begin by identifying the hosting model and confirming the installed fix.

Operators of affected instances should review unauthenticated requests, administrative-account creation, Guarded Script activity, unexpected table access, and commands passing through MID Servers or other connected proxy components. A current patch level does not rule out access that occurred before remediation.

The alternative exploit route also shows why defensive work cannot concentrate only on a published proof of concept. Once the vulnerable sink and underlying weakness become public, attackers can search for other paths through the same sandbox boundary or compare patched and unpatched code.

ServiceNow-hosted customers currently have the vendor’s assurance that the reported activity was not observed in their instances. Customer-managed operators need their own evidence that updates were installed, external exposure was removed, and no attacker established administrative access during the vulnerable period.

×