Someone left the master filing cabinet unlocked on the sidewalk, and anyone walking by can read, rewrite, or shred every document inside
CVE-2026-13016 is an unauthenticated SQL injection in the ServiceNow AI Platform, affecting the Yokohama (before Patch 13 Hot Fix 5a), Zurich (before Patch 10 Hot Fix 3b / Patch 11 Hot Fix 3), and Australia (before Patch 2 Hot Fix 4b W32 / Patch 4 Hot Fix 3 / Patch 5) release trains. An attacker with nothing more than network access to the instance can inject arbitrary SQL through unsanitized input fields and read, modify, or destroy the contents of the underlying database. That database is not some ancillary data store — it is the CMDB, the HR module, the incident queue, the integration credential vault, and every workflow your enterprise runs through ServiceNow. The flaw was discovered by Adam Kues of Assetnote and disclosed September 24, 2026. ServiceNow has already patched cloud-hosted tenants.
The CVSS 4.0 base score circulating from advisory aggregators is 9.3 Critical (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N), and that score is honest. Pre-auth, low-complexity, no user interaction, full confidentiality/integrity/availability impact on the vulnerable component. ServiceNow's own advisory language — *'unauthenticated user, in certain circumstances'* — undersells the risk. The qualifier *'in certain circumstances'* likely refers to the AI Platform feature set needing to be enabled, but in practice every customer licensing the AI Platform module has it active. For the ~85% of Fortune 500 companies running ServiceNow on the vendor's SaaS cloud, this is already remediated. The danger is concentrated in self-hosted (Private Stack) deployments that must apply patches manually, and any instance — cloud or self-hosted — that was exposed prior to the patch window.
5 steps from start to impact.
Discover the ServiceNow instance
http.title:"ServiceNow" or http.favicon.hash), or passive certificate transparency logs. ServiceNow login pages have a distinctive UI fingerprint. The stats.do endpoint, if not locked down, leaks build name and patch level, confirming vulnerability.- Target runs a self-hosted ServiceNow AI Platform instance
- Instance is network-reachable (internet-facing or attacker has internal network access)
- Most ServiceNow deployments are SaaS and already patched by ServiceNow
- Private Stack instances may be behind VPN or air-gapped in sovereign environments
http.title:ServiceNow and ssl.cert.subject.cn:*.service-now.com.Identify the vulnerable AI Platform endpoint
- AI Platform module is licensed and enabled on the instance
- Vulnerable endpoint is not blocked by a WAF or reverse proxy
- Not every ServiceNow instance has the AI Platform module enabled — but adoption has surged since 2025 and most enterprise-tier licenses include it
- A well-tuned WAF with SQL injection rulesets *may* catch trivial payloads, though sophisticated injection techniques (e.g., time-based blind, out-of-band) routinely bypass signature-based WAFs
Inject arbitrary SQL via unsanitized input
sqlmap can automate exploitation once the injection point is identified. The attacker gains direct read/write access to the underlying database.- Injection point accepts attacker-controlled input without parameterization
- Database user context has sufficient privileges to read/write across tables
- No public PoC or exploit code has been released as of September 25, 2026
- ServiceNow's internal DB architecture may limit the SQL dialect available (e.g., MariaDB vs. Oracle backend differences)
Exfiltrate sensitive data from the ServiceNow database
sys_user (usernames, hashed passwords, email addresses), sys_user_has_role (admin role assignments), cmdb_ci (full CMDB inventory), sys_properties (integration credentials, API keys, LDAP bind passwords stored as system properties), sn_hr_core_case (HR case records with PII), and incident (security/IT incident data). This is a full organizational data breach from a single injection point.- Database user context permits cross-table reads
- Sensitive data is stored in accessible tables (standard in ServiceNow)
- Column-level encryption on specific fields may limit cleartext extraction of some secrets
- ServiceNow's encryption key management (instance-specific KEK) may protect some encrypted fields
Escalate to admin access or pivot laterally
sys_user and sys_user_has_role, or modifies an existing account's role. With ServiceNow admin access, the attacker can execute server-side scripts (GlideRecord, background scripts), access MID Server configurations for lateral movement into the internal network, extract stored integration credentials for Active Directory, LDAP, cloud APIs, and SIEM systems, and potentially pivot to connected infrastructure.- SQL INSERT/UPDATE privileges are available
- MID Servers are deployed connecting the instance to internal networks
- MID Server compromise requires additional exploitation steps
- Two-factor authentication on ServiceNow admin accounts does not prevent direct DB-level user creation
The supporting signals.
| In-the-Wild Exploitation | No known exploitation. ServiceNow states: *'We are not currently aware of malicious exploitation against ServiceNow instances.'* Not listed on CISA KEV. However, the related CVE-2026-6875 (pre-auth RCE in the same AI Platform) saw active exploitation within 5 days of patch availability in July 2026 — expect a similar timeline. |
|---|---|
| Proof-of-Concept | No public PoC as of September 25, 2026. Disclosed only yesterday (Sept 24). Given Assetnote's track record of publishing detailed technical writeups (they documented the CVE-2026-6875 gadget chain), a PoC or detailed blog post is likely within 2–4 weeks. |
| EPSS Score | Not yet scored — CVE was published September 24, 2026. EPSS typically populates within 7–14 days of NVD publication. Expect a high EPSS given pre-auth + SQLi + high-value target profile. |
| KEV Status | Not listed on CISA KEV as of September 25, 2026. Given the ServiceNow attack surface and prior KEV additions for ServiceNow CVEs, KEV listing is plausible if exploitation emerges. |
| CVSS Vector | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N — 9.3 Critical. Network-accessible, no auth, no user interaction, low complexity. Full CIA impact on the vulnerable component. No scope change (downstream systems not directly scored, though real-world blast radius extends far beyond the DB). |
| Affected Versions | Yokohama < Patch 13 Hot Fix 5a · Zurich < Patch 10 Hot Fix 3b, < Patch 10 Hot Fix 4a W32, < Patch 11 Hot Fix 3 · Australia < Patch 2 Hot Fix 4b W32, < Patch 4 Hot Fix 3, < Patch 5 |
| Fixed Versions | Yokohama Patch 13 HF5a+ · Zurich Patch 10 HF3b+, Patch 10 HF4a W32+, Patch 11 HF3+ · Australia Patch 2 HF4b W32+, Patch 4 HF3+, Patch 5+. Cloud-hosted instances patched by ServiceNow. Self-hosted customers must apply manually via the Now Support Portal (KB3159623). |
| Exposure / Scanning | ServiceNow serves 8,800+ customers globally, including 85% of Fortune 500. The vast majority run on ServiceNow's SaaS cloud (already patched). Self-hosted Private Stack deployments are the residual attack surface — exact count not publicly disclosed, but Private Stack spans 28 countries and is used in sovereign/air-gapped/compliance-restricted environments. Internet-facing self-hosted instances are discoverable via Shodan (http.title:ServiceNow). |
| Disclosure Date | September 24, 2026 (CVE reserved June 23, 2026). Part of a September 2026 advisory batch that also includes CVE-2026-86860, CVE-2026-86858, CVE-2026-86859, and CVE-2026-86857. |
| Researcher | Adam Kues, Assetnote. Assetnote has been the dominant external researcher on ServiceNow AI Platform security in 2026, also credited with the CVE-2026-6875 pre-auth RCE chain that was actively exploited in July 2026. |
Sources.
- ServiceNow September 2026 CVE Advisory (KB3159623)
- SecurityOnline — Critical ServiceNow Vulnerabilities Fixed in AI Platform
- OffSeq Threat Radar — CVE-2026-13016 Live Intelligence
- Strix.ai — CVE-2026-13016 Detail
- The Hacker News — Three CVSS 10.0 ServiceNow Flaws
- BleepingComputer — ServiceNow Warns of Max Severity Vulnerabilities
- CybersecurityNews — ServiceNow Critical Flaws
- ThreatInt CVE Database — CVE-2026-13016
Why this verdict
- Pre-auth, zero-friction entry: The attack requires no credentials, no user interaction, and low complexity. Any network-reachable instance running an affected release train with the AI Platform module enabled is exploitable. There is no authentication gate, no CSRF token, no rate limit that changes the equation. This is the most dangerous class of web vulnerability.
- Role multiplier: ServiceNow is *canonically* a high-value-role component. It is not incidentally deployed on a server that happens to be important — it IS the ITSM nerve center for 85% of Fortune 500 companies. The database behind a ServiceNow instance contains the CMDB (full asset inventory), HR case records (PII), security incident data, integration credentials for AD/LDAP/cloud services, and workflow automation configs. SQLi against this database is organizational-scale data egress. On deployments with MID Servers, the blast radius extends to lateral movement into the internal network. The chain succeeds in the high-value role by definition, and the outcome is mass data egress + credential theft + potential domain compromise via extracted AD integration credentials. This floors the verdict at CRITICAL.
- Threat-intelligence trajectory: Assetnote's Adam Kues discovered the closely related CVE-2026-6875 (pre-auth RCE, CVSS 9.5), which saw active exploitation within 5 days of patch availability in July 2026. The same researcher found this SQLi. The pattern — Assetnote disclosure → rapid weaponization → mass scanning — is well-established for ServiceNow in 2026. The absence of a public PoC today does not mean safety; it means a shrinking window.
Why not higher?
A 9.3 is already near-ceiling. The CVSS 4.0 vector correctly identifies no scope change (SC:N/SI:N/SA:N), meaning the downstream impact on connected systems is not formally scored. In practice, the blast radius extends to AD and internal networks via MID Server pivots, but this requires additional exploitation steps beyond the SQLi itself. A 10.0 would require confirmed scope change or zero friction to full infrastructure compromise in a single step.
Why not lower?
Every friction point that might reduce severity fails to meaningfully narrow the exposed population for the component class at risk. Cloud-hosted instances are patched — but self-hosted Private Stack deployments are not, and these are disproportionately high-value targets (sovereign, regulated, air-gapped environments with the most sensitive data). The absence of a public PoC is a *temporary* condition, not a structural defense. The 'certain circumstances' qualifier in ServiceNow's advisory likely refers to AI Platform enablement, which is standard on enterprise-tier licenses. No credible friction point reduces this below CRITICAL for self-hosted deployments.
- MFA on ServiceNow login — irrelevant because the SQLi endpoint is pre-auth; the attacker never touches the login page or SSO flow.
- ServiceNow ACLs and role-based access controls — these operate at the application layer, not the database layer; SQLi bypasses the entire application authorization stack and queries the DB directly.
- Network segmentation of the ServiceNow database tier — the SQLi is executed through the application's own database connection; the attacker does not need direct network access to the database server.
- IP allowlisting on ServiceNow — only effective if the instance is behind a VPN/ZTNA; if the instance is internet-facing, the attacker's IP is not known in advance and cannot be preemptively blocked.
Crowdsourced verification payload.
Run this script from any workstation or CI runner with curl installed. It checks the target ServiceNow instance's build version via the stats.do diagnostic page. Usage: bash check_cve_2026_13016.sh https://your-instance.service-now.com. No authentication is required if stats.do is accessible (default). If stats.do is locked down (glide.security.diag_txns_acl=true), run from an admin session or check the build tag manually under System Diagnostics > Stats.
#!/usr/bin/env bash
# CVE-2026-13016 Checker — ServiceNow AI Platform SQL Injection
# Determines whether a ServiceNow instance is on a vulnerable release train.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -uo pipefail
if [ $# -lt 1 ]; then
echo "Usage: $0 https://your-instance.service-now.com"
exit 2
fi
INSTANCE="${1%/}"
echo "[*] Target: ${INSTANCE}"
echo "[*] Fetching build info from stats.do ..."
RESPONSE=$(curl -skL --max-time 20 "${INSTANCE}/stats.do" 2>/dev/null)
if [ -z "$RESPONSE" ]; then
echo "[!] ERROR: Could not reach ${INSTANCE}/stats.do"
echo "UNKNOWN"
exit 2
fi
# Extract build name (e.g., "glide-australia-02-04-2026__patch5-hotfix0-09-18-2026")
BUILD=$(echo "$RESPONSE" | grep -ioP '(?:Build name|Build tag)[:\s]*\K[^\s<"]+' | head -1)
if [ -z "$BUILD" ]; then
echo "[!] stats.do reachable but build info not parseable."
echo "[!] Likely locked via glide.security.diag_txns_acl."
echo "[*] Check manually: System Diagnostics > Stats > Build name."
echo "UNKNOWN"
exit 2
fi
BUILD_LOWER=$(echo "$BUILD" | tr '[:upper:]' '[:lower:]')
echo "[*] Build: ${BUILD}"
# Determine release train
TRAIN="unknown"
if echo "$BUILD_LOWER" | grep -q 'yokohama'; then TRAIN="yokohama"
elif echo "$BUILD_LOWER" | grep -q 'zurich'; then TRAIN="zurich"
elif echo "$BUILD_LOWER" | grep -q 'australia'; then TRAIN="australia"
fi
if [ "$TRAIN" = "unknown" ]; then
echo "[*] Release train not in affected set (Yokohama/Zurich/Australia)."
echo "[*] If running a newer release, likely not affected."
echo "[*] If running an older EOL release, check separately."
echo "UNKNOWN"
exit 2
fi
echo "[*] Release train: ${TRAIN}"
echo ""
echo "=== Patched versions for ${TRAIN} ==="
case "$TRAIN" in
yokohama)
echo " Yokohama Patch 13 Hot Fix 5a or later"
;;
zurich)
echo " Zurich Patch 10 Hot Fix 3b or later"
echo " Zurich Patch 10 Hot Fix 4a W32 or later"
echo " Zurich Patch 11 Hot Fix 3 or later"
;;
australia)
echo " Australia Patch 2 Hot Fix 4b W32 or later"
echo " Australia Patch 4 Hot Fix 3 or later"
echo " Australia Patch 5 or later"
;;
esac
echo ""
echo "[!] Instance is on affected release train: ${TRAIN}"
echo "[!] Verify your exact patch+hotfix level against the list above."
echo "[!] If your build predates the fix, this instance is:"
echo "VULNERABLE"
exit 1