← Back to Feed CACHED · 2026-09-25 06:33:11 · CACHE_KEY CVE-2026-13016
CVE-2026-13016 · CWE-89 · Disclosed 2026-09-24

ServiceNow has remediated a SQL injection vulnerability that was identified in the ServiceNow AI Platform.

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Pre-auth SQLi hands the keys to every ITSM record your org owns — patch self-hosted instances now"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Discover the ServiceNow instance

The attacker identifies a self-hosted ServiceNow instance via DNS enumeration, Shodan/Censys/FOFA dorks (e.g., 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.
Conditions required:
  • Target runs a self-hosted ServiceNow AI Platform instance
  • Instance is network-reachable (internet-facing or attacker has internal network access)
Where this breaks in practice:
  • Most ServiceNow deployments are SaaS and already patched by ServiceNow
  • Private Stack instances may be behind VPN or air-gapped in sovereign environments
Detection/coverage: Shodan, Censys, FOFA, and GreyNoise all index ServiceNow login pages. Defenders can search their own exposure via http.title:ServiceNow and ssl.cert.subject.cn:*.service-now.com.
STEP 02

Identify the vulnerable AI Platform endpoint

The attacker probes known API routes associated with the ServiceNow AI Platform module. These endpoints accept user-supplied parameters that feed into database queries. No authentication token, session cookie, or CSRF check is required — the endpoint is fully pre-auth. The attacker confirms the AI Platform feature set is active by observing response behavior.
Conditions required:
  • AI Platform module is licensed and enabled on the instance
  • Vulnerable endpoint is not blocked by a WAF or reverse proxy
Where this breaks in practice:
  • 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
Detection/coverage: WAF logs showing SQLi signatures against ServiceNow AI Platform API paths. ServiceNow application logs may show malformed query errors if query audit logging is enabled.
STEP 03

Inject arbitrary SQL via unsanitized input

The attacker crafts a SQL injection payload targeting the unsanitized input parameter. Given that no authentication is required and attack complexity is low, this can be as simple as a UNION-based injection to enumerate tables and extract data, or a stacked-query injection to modify records. Tools like sqlmap can automate exploitation once the injection point is identified. The attacker gains direct read/write access to the underlying database.
Conditions required:
  • Injection point accepts attacker-controlled input without parameterization
  • Database user context has sufficient privileges to read/write across tables
Where this breaks in practice:
  • 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)
Detection/coverage: Database query audit logs showing anomalous or injected SQL patterns. SIEM rules for SQL error messages in application logs. Network IDS/IPS with deep packet inspection for SQL keywords in HTTP request bodies.
STEP 04

Exfiltrate sensitive data from the ServiceNow database

With arbitrary SQL execution, the attacker queries high-value tables: 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.
Conditions required:
  • Database user context permits cross-table reads
  • Sensitive data is stored in accessible tables (standard in ServiceNow)
Where this breaks in practice:
  • 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
Detection/coverage: Database-level audit trails for bulk SELECT operations against sensitive tables. ServiceNow platform analytics showing anomalous data access volume. DLP solutions monitoring egress for structured data patterns (SSNs, credential strings).
STEP 05

Escalate to admin access or pivot laterally

The attacker creates a new admin user via INSERT into 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.
Conditions required:
  • SQL INSERT/UPDATE privileges are available
  • MID Servers are deployed connecting the instance to internal networks
Where this breaks in practice:
  • MID Server compromise requires additional exploitation steps
  • Two-factor authentication on ServiceNow admin accounts does not prevent direct DB-level user creation
Detection/coverage: ServiceNow sys_audit table entries for new admin user creation. MID Server connection logs showing unexpected commands. Active Directory logs showing authentication from ServiceNow service accounts to unusual targets.
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNo 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-ConceptNo 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 ScoreNot 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 StatusNot 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 VectorCVSS: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 VersionsYokohama < 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 VersionsYokohama 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 / ScanningServiceNow 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 DateSeptember 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.
ResearcherAdam 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.

  1. ServiceNow September 2026 CVE Advisory (KB3159623)
  2. SecurityOnline — Critical ServiceNow Vulnerabilities Fixed in AI Platform
  3. OffSeq Threat Radar — CVE-2026-13016 Live Intelligence
  4. Strix.ai — CVE-2026-13016 Detail
  5. The Hacker News — Three CVSS 10.0 ServiceNow Flaws
  6. BleepingComputer — ServiceNow Warns of Max Severity Vulnerabilities
  7. CybersecurityNews — ServiceNow Critical Flaws
  8. ThreatInt CVE Database — CVE-2026-13016
04 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.3/10)

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.

05 · Compensating Control

1
CRITICAL 9.3→IGNORE 0.0
SEVERITY REDUCED
Apply the vendor patch immediately on all self-hosted instances — This is the only definitive remediation. Self-hosted customers should download and apply the appropriate hot fix for their release train (Yokohama Patch 13 HF5a, Zurich Patch 10 HF3b+, Australia Patch 2 HF4b W32+ / Patch 4 HF3+ / Patch 5+) from the Now Support Portal. Per the noisgate mitigation SLA for CRITICAL, deploy within 3 days. Cloud-hosted instances are already patched by ServiceNow — confirm with your TAM.
2
CRITICAL 9.3→HIGH 7.5
SEVERITY REDUCED
Deploy WAF rules blocking SQL injection patterns on ServiceNow endpoints — If patching cannot be completed within 3 days, place a WAF (e.g., Cloudflare, AWS WAF, F5 ASM, Imperva) in front of the ServiceNow instance with aggressive SQLi detection rulesets enabled. Focus on the AI Platform API paths. This is a temporary measure — sophisticated attackers can bypass signature-based WAFs with time-based blind injection, encoding tricks, and out-of-band exfiltration. Deploy within 3 days per noisgate mitigation SLA.
3
CRITICAL 9.3→MEDIUM 5.5
SEVERITY REDUCED
Restrict network access to self-hosted instances — If the self-hosted instance is internet-facing, move it behind a VPN or Zero Trust Network Access (ZTNA) gateway immediately. Only allow access from known corporate IP ranges. This eliminates the unauthenticated remote attack vector for external attackers, though internal threats remain. Deploy within 3 days per noisgate mitigation SLA.
4
CRITICAL 9.3→CRITICAL 9.0
SCORE ONLY
Enable database query audit logging and SIEM alerting — Enable ServiceNow's database query audit logging and forward logs to your SIEM. Create detection rules for: anomalous SQL patterns in application logs, bulk data access from ServiceNow DB, new admin user creation via direct DB manipulation, and errors indicating SQL injection attempts (e.g., syntax errors, UNION keyword in query logs). This does not prevent exploitation but enables rapid detection and response. Deploy within 3 days.
5
CRITICAL 9.3→HIGH 7.0
SEVERITY REDUCED
Rotate all integration credentials stored in ServiceNow — Assume that if the instance was exposed pre-patch, integration credentials (LDAP bind passwords, API keys, OAuth secrets, MID Server credentials) may have been exfiltrated. Rotate all credentials stored as ServiceNow system properties or connection records. Prioritize AD/LDAP bind accounts and MID Server service accounts. Complete within 7 days of patching.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously