Back to Intelligence

Three CVSS 10.0 ServiceNow AI Platform Flaws: Unauthenticated RCE and SQL Injection — Detection and Remediation Guide

SA
Security Arsenal Team
August 28, 2026
13 min read

ServiceNow has shipped patches for four vulnerabilities in the ServiceNow AI Platform — three of them carrying a perfect CVSS score of 10.0 and, under certain conditions, exploitable by an attacker with no credentials at all. If your organization runs a self-hosted ServiceNow instance, your exposure window is open right now: ServiceNow has already patched its hosted fleet, but the update is only as good as your change window.

ServiceNow sits at the center of IT operations for thousands of enterprises. It holds asset inventories, credentials for integrations, incident workflows, HR records, and — critically — it is a privileged orchestration engine that can push changes across the environment. An unauthenticated remote code execution flaw in that platform is not a web app bug; it is a potential enterprise-wide compromise primitive. Treat this with the same urgency you gave the Ivanti and ConnectWise criticals of the past two years.

What Happened

ServiceNow disclosed four security flaws impacting the ServiceNow AI Platform. Three are rated CVSS 10.0 — the maximum severity — and can be exploited by unauthenticated attackers in certain circumstances to execute code and run arbitrary SQL against the instance's underlying database. The fourth flaw rounds out the release at a lower (but still meaningful) severity.

The company's response followed its standard model:

  • Hosted instances: ServiceNow deployed the security update directly to customer instances hosted in its cloud. If ServiceNow operates your instance, you are patched — but you should still verify and hunt for pre-patch exploitation.
  • Self-hosted customers and partners: The update was made available, but applying it is on you. Any organization running ServiceNow on its own infrastructure or in a self-managed cloud is unpatched until they act.

That last point is where the risk concentrates. Attackers watch vendor patch releases for CVSS 10.0s and begin reverse-engineering the delta within days — sometimes hours. The gap between "update released to self-hosted customers" and "update applied" is your exploitation window.

Technical Analysis

Affected Platform

  • Product: ServiceNow AI Platform (the Now Platform with AI/GenAI capabilities layered in)
  • Deployment models affected: Self-hosted and partner-hosted instances are the primary at-risk population. ServiceNow-operated hosted instances received the update automatically.
  • Architecture context: Self-hosted ServiceNow instances run a Java-based application stack (Tomcat web layer in front of a relational database — typically MariaDB/MySQL). This matters enormously for both exploitation mechanics and detection, which we'll cover below.

Vulnerability Characteristics

The headline details from the disclosure:

  • Three flaws rated CVSS 10.0 — critical severity, network-exploitable, low complexity, no privileges required (that's what drives a 10.0 under CVSS v3.x scoring).
  • Unauthenticated exploitation "in certain circumstances" — this qualifier typically maps to specific configurations, enabled modules, or exposed endpoints. Do not read "certain circumstances" as "probably safe." Read it as "you must determine whether your configuration matches the exploitable condition," and assume it does until proven otherwise.
  • Impact: code execution and SQL injection. The SQL component is the sleeper issue. ServiceNow instances store integration credentials, API keys, OAuth tokens for downstream systems, LDAP bind accounts, and MID Server credentials in their database. An unauthenticated SQL injection against a ServiceNow backend is, in practical terms, a credential vault breach and a launchpad for lateral movement.

Attack Chain (Defender's View)

Based on the disclosed impact, a realistic exploitation path against a self-hosted instance looks like this:

  1. Reconnaissance: Attacker identifies internet-facing or internally exposed ServiceNow instances (Shodan/Censys fingerprints ServiceNow portals readily; self-hosted instances are frequently exposed for employee self-service access).
  2. Initial access: Unauthenticated request to a vulnerable endpoint in the AI Platform component — no session, no credentials required.
  3. Execution/SQLi: Depending on which flaw is hit, the attacker either achieves code execution in the context of the ServiceNow application service account or injects SQL against the backend database.
  4. Post-exploitation: Extraction of stored integration credentials, session tokens, and user data; deployment of a web shell into the Tomcat webroot; or pivoting through MID Servers, which by design have reach into internal networks for discovery and orchestration.

The MID Server angle deserves emphasis: ServiceNow MID Servers are deliberately positioned to bridge the platform into your internal infrastructure. Compromise of the instance can translate into compromise of everything the MID Server can touch.

Exploitation Status

At the time of writing, the disclosure does not confirm in-the-wild exploitation, and no public proof-of-concept has been reported. That is the good news. The sobering news: CVSS 10.0 unauthenticated RCE/SQLi flaws in a platform this widely deployed are priority-one targets for both ransomware affiliates and nation-state operators, and the vendor publishing patches to self-hosted customers effectively starts the clock on reverse engineering. History with comparable enterprise platforms (Ivanti, Citrix, MOVEit, Confluence) tells us the window between patch release and mass exploitation is now measured in days. Operate as if exploitation is imminent.

Detection & Response

Patching is the fix, but your instance was exposed before you patched. Hunt first, patch in parallel, and assume breach for any internet-facing self-hosted instance.

The following detections target the post-exploitation behaviors most likely to follow exploitation of these flaws: the Java/Tomcat application process spawning shells or system utilities (code execution / web shell deployment), and SQL injection probe patterns in web access logs.

YAML
---
title: ServiceNow Tomcat Process Spawning Shell or System Utility
id: 9c2e7a41-3b58-4f6d-a1e9-5d8c2f7b3e6a
status: experimental
description: Detects the Java/Tomcat process hosting a self-hosted ServiceNow instance spawning command shells or system utilities, consistent with remote code execution or web shell deployment following exploitation of the ServiceNow AI Platform flaws.
references:
  - https://thehackernews.com/2026/08/three-cvss-100-servicenow-flaws-could.html
  - https://attack.mitre.org/techniques/T1190/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/08/07
tags:
  - attack.initial_access
  - attack.execution
  - attack.t1190
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'tomcat'
      - 'catalina'
      - 'servicenow'
      - 'java'
  selection_image:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/python3'
      - '/perl'
      - '/base64'
      - '/id'
      - '/whoami'
  condition: selection_parent and selection_image
falsepositives:
  - ServiceNow MID Server or discovery jobs may legitimately invoke system commands from the application context — baseline per-instance and alert on deviations
  - Vendor support scripts executed during maintenance windows
level: high
---
title: SQL Injection Probes Against ServiceNow Web Endpoints
id: 4f1b8d63-7e2a-4c95-b8d1-2a6f9e4c5b7d
status: experimental
description: Detects HTTP requests to ServiceNow application endpoints containing SQL injection probe patterns (UNION SELECT, boolean-based probes, database error elicitation) in web access or reverse proxy logs, consistent with exploitation attempts against the SQL injection flaws in the ServiceNow AI Platform.
references:
  - https://thehackernews.com/2026/08/three-cvss-100-servicenow-flaws-could.html
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/08/07
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri_host:
    cs-uri-stem|contains:
      - '/api/now'
      - 'sysparm'
      - '.do'
      - '/nav_to.do'
  selection_sqli:
    cs-uri-query|contains:
      - 'union select'
      - 'union all select'
      - ' or 1=1'
      - '\' or \'1\'=\'1'
      - 'extractvalue('
      - 'updatexml('
      - 'concat(0x'
      - 'information_schema'
      - 'sleep('
      - 'benchmark('
      - 'load_file('
  condition: selection_uri_host and selection_sqli
falsepositives:
  - Authorized vulnerability scanners and DAST tools — correlate source IPs against approved scanner ranges
  - Web application firewall tuning traffic
level: high
---
title: Outbound Network Connection From ServiceNow Application Process
id: 7d3a9f52-1c84-4b27-9e6a-8f5d1c3a9b2e
status: experimental
description: Detects the ServiceNow Java/Tomcat application process initiating outbound network connections to non-standard destinations, which may indicate command-and-control or data exfiltration following compromise of a self-hosted instance.
references:
  - https://thehackernews.com/2026/08/three-cvss-100-servicenow-flaws-could.html
  - https://attack.mitre.org/techniques/T1071/
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/08/07
tags:
  - attack.command_and_control
  - attack.exfiltration
  - attack.t1071
  - attack.t1105
logsource:
  category: network_connection
  product: linux
detection:
  selection_process:
    Image|contains:
      - '/java'
      - 'tomcat'
  filter_known_dest:
    DestinationIp|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection_process and not filter_known_dest
falsepositives:
  - Legitimate ServiceNow cloud connectivity (instances phone home to ServiceNow infrastructure) — baseline destination ASNs and domains for your instance and alert on novel destinations
  - Third-party integrations and webhooks
level: medium

The first rule is the highest-fidelity: a Java/Tomcat process spawning sh, curl, or whoami on a ServiceNow application server is almost never legitimate outside of discovery integrations, and it is the canonical signature of web application RCE. Tune the parent-process match to your actual installation path before deployment.

KQL — Microsoft Sentinel / Defender
// Hunt for SQLi probes and anomalous unauthenticated request patterns against
// self-hosted ServiceNow instances in proxy/WAF logs ingested via CEF/Syslog.
// Adjust the DeviceHostName filter to your ServiceNow front-end / proxy hosts.
let servicenow_hosts = dynamic(["sn-proxy-01", "servicenow.example.com"]);
let sqli_patterns = dynamic([
  "union select", "union all select", " or 1=1", "extractvalue(",
  "updatexml(", "information_schema", "sleep(", "benchmark(",
  "concat(0x", "load_file("
]);
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where DeviceHostName in (servicenow_hosts) or DestinationHostName has_any (servicenow_hosts)
| extend Url = coalesce(RequestURL, AdditionalExtensions)
| where Url has_any (sqli_patterns)
   or (RequestMethod == "POST" and Url has_any ("/api/now", "sysparm", ".do")
       and RequestContext !has "session")  // candidate unauthenticated API hits
| summarize RequestCount = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            UniqueUrls = dcount(Url),
            SampleUrls = make_set(Url, 5)
  by SourceIP, SourceUserAgent, RequestMethod
| order by RequestCount desc;

// Companion hunt: Syslog from ServiceNow app servers showing the Java/Tomcat
// process spawning shells or download utilities (post-exploitation RCE).
Syslog
| where TimeGenerated > ago(14d)
| where ProcessName has_any ("java", "tomcat", "catalina")
   or SyslogMessage has ("servicenow")
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl ", "wget ", "whoami", "nc -", "base64 -d")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;
VQL — Velociraptor
-- Artifact: SecurityArsenal.ServiceNow.PostExploitHunt
-- Hunts self-hosted ServiceNow application servers for post-exploitation
-- indicators: Java/Tomcat processes with suspicious children, recently
-- dropped files in Tomcat webroots (potential web shells), and
-- unexpected outbound connections from the application process.

-- 1. Java/Tomcat processes and their command lines
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)java|tomcat|catalina'
   OR CommandLine =~ '(?i)servicenow|catalina'

-- 2. Recently modified files in Tomcat webroots (web shell candidates)
--    Adjust the glob path to your installation layout.
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=[
  '/opt/tomcat/webapps/**/*.jsp',
  '/opt/*/webapps/ROOT/**/*.jsp',
  '/usr/share/tomcat*/webapps/**/*.jsp',
  '/srv/servicenow/**/webapps/**/*.jsp'
])
WHERE Mtime > (now() - 1209600)  -- modified in last 14 days
ORDER BY Mtime DESC

-- 3. Outbound connections from the Java application process
SELECT Pid, Name, RemoteAddress, RemotePort, Status
FROM netstat()
WHERE Name =~ '(?i)java'
  AND Status =~ 'ESTAB'
  AND NOT RemoteAddress =~ '^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|127\\.)'
Bash / Shell
#!/bin/bash
# servicenow_patch_verify.sh — Verify patch status and baseline posture
# for a self-hosted ServiceNow instance. Run on the application server
# or against the instance API with an admin credential.
#
# Usage:
#   ./servicenow_patch_verify.sh https://your-instance.example.com admin_user

set -euo pipefail

INSTANCE="${1:?Usage: $0 <instance_url> <username>}"
USER="${2:?Usage: $0 <instance_url> <username>}"

echo "[+] Querying instance build/version info..."
# The stats.do page exposes the current build tag and patch level.
curl -s -u "${USER}" "${INSTANCE}/stats.do" \
  | grep -iE 'build|version|patch|release' \
  | sed 's/<[^>]*>//g'

echo ""
echo "[+] ACTION REQUIRED: Compare the build tag above against the patched"
echo "    build listed in the ServiceNow security advisory for the AI Platform"
echo "    flaws (ServiceNow Support / HI portal). If your build predates the"
echo "    patched build for your release family, your instance is VULNERABLE."

echo ""
echo "[+] Checking local Tomcat webroot for recently modified JSP files"
echo "    (potential web shells — last 14 days)..."
for webroot in /opt/tomcat/webapps /usr/share/tomcat*/webapps /srv/servicenow/*/webapps; do
  if [ -d "${webroot}" ]; then
    find "${webroot}" -name '*.jsp' -mtime -14 -type f 2>/dev/null \
      | while read -r f; do
          echo "  RECENTLY MODIFIED: ${f} ($(stat -c '%y' "${f}"))"
        done
  fi
done

echo ""
echo "[+] Checking for shell/utility child processes of the Java/Tomcat process..."
JAVA_PIDS=$(pgrep -f 'java|catalina' || true)
if [ -n "${JAVA_PIDS}" ]; then
  for pid in ${JAVA_PIDS}; do
    children=$(ps --ppid "${pid}" -o pid=,comm= 2>/dev/null || true)
    if [ -n "${children}" ]; then
      echo "  Java PID ${pid} has child processes:"
      echo "${children}" | sed 's/^/    /'
    fi
  done
else
  echo "  No Java/Tomcat process found on this host (app tier may be elsewhere)."
fi

echo ""
echo "[+] Reviewing access logs for SQLi probe patterns (last 100k lines)..."
for log in /var/log/tomcat*/localhost_access_log*.txt /opt/*/logs/localhost_access_log*.txt /var/log/nginx/access.log /var/log/httpd/access_log; do
  if [ -f "${log}" ]; then
    hits=$(tail -n 100000 "${log}" | grep -icE 'union%20|union |select |sleep\(|benchmark\(|information_schema|extractvalue|updatexml' || true)
    if [ "${hits}" -gt 0 ]; then
      echo "  ${log}: ${hits} suspicious request(s) — investigate"
    fi
  fi
done

echo ""
echo "[+] Done. If any findings above are unexpected, preserve logs and"
echo "    escalate to IR before patching (patching can destroy evidence)."

Remediation

Prioritized actions, in order:

  1. Determine your deployment model immediately. If ServiceNow hosts your instance, confirm with ServiceNow Support (via the HI/Now Support portal) that your instance received the update and note the date it was applied — that date bounds your exposure window for retrospective hunting. If you are self-hosted or partner-hosted, you are in the at-risk population until the update is applied.

  2. Apply the security update now. The update is available through ServiceNow's standard channels for self-hosted customers and partners (Now Support / HI portal). Do not wait for a normal change freeze cycle — three simultaneous CVSS 10.0 unauthenticated flaws meet any reasonable definition of emergency change. Verify the post-patch build tag matches the patched build for your release family.

  3. Hunt before and after patching. If your instance was reachable from the internet (employee self-service portals frequently are), assume it was scanned and possibly probed. Pull access logs from the application tier and any fronting proxy/WAF for at least the past 30 days and run the SQLi and unauthenticated-request hunts above. Preserve forensic copies before patching — upgrades can rotate logs and overwrite artifacts.

  4. Restrict exposure as a compensating control. Until patched, put the instance behind your WAF with SQLi/attack-pattern rules in blocking mode, restrict access to known network ranges or VPN/ZTNA where business processes allow, and block direct internet access to administrative and API paths (/api/now/*, *.do endpoints not required for self-service). This is a stopgap, not a fix — "exploitable in certain circumstances" means you cannot be confident which request path is dangerous.

  5. Rotate integration credentials on suspicion of compromise. If hunting turns up any evidence of exploitation — SQLi probes followed by anomalies, unexpected child processes, new JSP files — treat all credentials stored in the instance (integration accounts, API keys, OAuth client secrets, LDAP bind credentials, MID Server credentials) as compromised. Rotate them in dependency order, starting with anything that has reach into your internal network or IdP.

  6. Audit MID Servers. Review MID Server service accounts for least privilege, check MID Server hosts for unexpected processes or connections, and validate that no new MID Servers or integrations were registered in the instance that you didn't approve.

  7. Watch for follow-on intelligence. Monitor ServiceNow's security advisories, CISA's Known Exploited Vulnerabilities catalog, and your threat intel feeds for exploitation confirmation and any CVE identifiers assigned to these flaws. If exploitation is confirmed, re-run hunts over the full exposure window.

The broader lesson for vulnerability management programs: SaaS-hybrid platforms create a two-speed patching problem. Your vendor patched its cloud in a day; your self-hosted deployment is your responsibility, and adversaries know exactly which organizations run self-hosted instances. Maintain an accurate inventory of every self-hosted enterprise platform, its exposure, and its patch latency — when the next CVSS 10.0 drops, that inventory is the difference between a weekend patch and a breach disclosure.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.