← Back to Feed CACHED · 2026-09-25 06:37:42 · CACHE_KEY CVE-2026-86860
CVE-2026-86860 · CWE-862 · Disclosed 2026-09-24

ServiceNow has remediated a missing authorization vulnerability that was identified in the ServiceNow AI…

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

Like leaving the master key cabinet unlocked, but only in the branch offices that haven't switched to electronic locks yet

CVE-2026-86860 is a missing authorization flaw (CWE-862) in the ServiceNow AI Platform that lets an unauthenticated, remote attacker extract instance data beyond intended boundaries and escalate privileges — all without credentials or user interaction. Affected releases span Yokohama (before Patch 13 Hot Fix 5a), Zurich (before Patch 10 Hot Fix 3b, Patch 10 Hot Fix 4a W32, or Patch 11 Hot Fix 3), and Australia (before Patch 2 Hot Fix 4b W32, Patch 4 Hot Fix 3, or Patch 5). The vendor's own CVSS 4.0 self-assessment is 9.3/Critical, but no NVD or authoritative third-party score exists yet. ServiceNow disclosed this alongside four other AI Platform flaws (CVE-2026-13016, -86857, -86858, -86859), signaling a systemic authorization-boundary weakness in the AI subsystem.

The vendor's 9.3 Critical label is directionally correct but overstates real-world risk for most organizations. The critical nuance: ServiceNow auto-patched all cloud-hosted instances before public disclosure. The remaining attack surface is Private Stack / self-hosted deployments — roughly 500+ organizations across 28 countries per ServiceNow's own marketing. That's a small fraction of ServiceNow's ~8,000+ enterprise customer base. The vendor's qualifier *'in certain circumstances'* further narrows exploitability to specific configuration states not fully documented. With no PoC, no in-the-wild exploitation, and the majority of the installed base already patched, this is a HIGH-severity issue for the self-hosted minority, not a fleet-wide CRITICAL emergency.

"Unauth data extraction from ServiceNow AI Platform; cloud-hosted already patched, self-hosted exposed."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify a Self-Hosted ServiceNow Instance

The attacker locates a ServiceNow instance running on customer infrastructure (Private Stack) rather than ServiceNow's cloud. Self-hosted instances are identifiable via HTTP response headers, login page fingerprinting, or Shodan/Censys queries for ServiceNow-specific endpoints like login.do or stats.do. Cloud-hosted instances on *.service-now.com are already patched and not exploitable.
Conditions required:
  • Target must be a self-hosted (Private Stack) ServiceNow instance
  • Instance must be network-reachable (typically internet-facing or reachable from internal network)
Where this breaks in practice:
  • Only ~500+ orgs run Private Stack out of ~8,000+ ServiceNow customers
  • Many Private Stack deployments are air-gapped or behind VPN by design — that's often WHY they chose self-hosted
Detection/coverage: Shodan/Censys queries for ServiceNow login pages; GreyNoise community feeds for ServiceNow reconnaissance patterns
STEP 02

Probe the AI Platform Authorization Boundary

The attacker sends unauthenticated API requests to ServiceNow AI Platform endpoints. The missing authorization check means certain API calls that should require authentication are processed without credential validation. The attacker crafts requests targeting the AI Platform's data-access layer to enumerate accessible data sets.
Conditions required:
  • ServiceNow AI Platform module must be enabled on the instance
  • Instance must be running a vulnerable version (pre-patch)
  • The 'certain circumstances' configuration state must be present
Where this breaks in practice:
  • Not all ServiceNow instances have the AI Platform module enabled — it's an add-on capability
  • The vendor's 'certain circumstances' qualifier suggests additional configuration prerequisites beyond just running a vulnerable version
  • No public PoC or technical writeup exists to guide exploitation
Detection/coverage: WAF rules for anomalous unauthenticated API calls to /api/ or AI Platform endpoints; ServiceNow system logs for unauthenticated data access attempts
STEP 03

Extract Instance Data Beyond Authorization Boundaries

With the authorization check bypassed, the attacker extracts data from the ServiceNow instance that should be restricted. This could include CMDB records (complete infrastructure topology), incident/change records, HR data, integration credentials, or AI model configurations. The CVSS vector indicates HIGH confidentiality impact on the vulnerable system and HIGH confidentiality/integrity impact on subsequent systems.
Conditions required:
  • Successful bypass of authorization check in Step 2
  • Instance contains sensitive data (nearly universal for production ServiceNow)
Where this breaks in practice:
  • Data extraction scope may be limited by the specific authorization boundary that's missing — not necessarily full database access
  • ServiceNow's data classification and access control layers may still restrict some data sets
Detection/coverage: ServiceNow audit logs for bulk data access patterns; DLP/CASB solutions monitoring outbound data from ServiceNow infrastructure; SIEM correlation of unauthenticated access events
STEP 04

Escalate Privileges on the ServiceNow Instance

Using the extracted data — which may include admin credentials, API tokens, or session information — the attacker escalates to an authenticated administrative session on the ServiceNow instance. This provides full control over the ITSM/ITOM platform including the ability to modify records, create backdoor accounts, and pivot to integrated downstream systems via stored integration credentials.
Conditions required:
  • Extracted data includes credential material or session tokens
  • Or: the missing authorization directly allows write operations (the CVSS vector indicates SC:H/SI:H — high integrity impact on subsequent systems)
Where this breaks in practice:
  • Privilege escalation path depends on what data was extractable
  • Not all instances store plaintext credentials — ServiceNow supports credential encryption
Detection/coverage: ServiceNow login audit trail for new admin sessions from unexpected IPs; ServiceNow security center alerts for privilege changes; integration credential usage monitoring
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone observed. ServiceNow states *'We are not currently aware of malicious exploitation against ServiceNow instances.'* Not listed in CISA KEV.
Proof of ConceptNo public PoC exists. No exploit code on GitHub, Exploit-DB, or researcher blogs as of 2026-09-25. The vulnerability was disclosed only 1 day ago.
EPSS ScoreNot yet computed. FIRST.org EPSS model evaluation is in progress for this newly assigned CVE ID. Expect initial scoring within 7-14 days of publication.
KEV StatusNot listed. CVE-2026-86860 is not in the CISA Known Exploited Vulnerabilities catalog. No federal patching mandate exists.
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N (ServiceNow self-assessed, 9.3 Critical). Network-accessible, no auth required, no user interaction. High confidentiality impact on target; high confidentiality and integrity impact on downstream systems. No availability impact.
Affected VersionsYokohama < Patch 13 HF 5a · Zurich < Patch 10 HF 3b / HF 4a W32, < Patch 11 HF 3 · Australia < Patch 2 HF 4b W32, < Patch 4 HF 3, < Patch 5
Fixed VersionsYokohama Patch 13 Hot Fix 5a, Zurich Patch 10 Hot Fix 3b (or 4a W32) / Patch 11 Hot Fix 3, Australia Patch 2 Hot Fix 4b W32 / Patch 4 Hot Fix 3 / Patch 5. Cloud-hosted instances were auto-patched before disclosure.
Scanning / ExposureServiceNow Private Stack deployments (~500+ orgs, 28 countries) are the remaining attack surface. Cloud-hosted instances (*.service-now.com) are already remediated. Shodan queries for ServiceNow login pages can identify self-hosted instances.
Disclosure Date2026-09-24 (CVE reserved 2026-09-08). Part of a batch of 5 ServiceNow AI Platform CVEs disclosed simultaneously.
Reporting ResearcherNot publicly credited. ServiceNow's advisory does not name a reporting researcher or organization.

Sources.

  1. ServiceNow CVE-2026-86860 Advisory (KB3159623)
  2. ServiceNow CVE Security Advisories Landing Page
  3. SecurityOnline — Critical ServiceNow Vulnerabilities Fixed in AI Platform
  4. Strix.ai — CVE-2026-86860 Analysis
  5. OffSeq Threat Radar — CVE-2026-86860
  6. TheHackerWire — CVE-2026-86860 PoC & Exploit Status
  7. ThreatInt CVE Database — CVE-2026-86860
  8. ServiceNow Private Stack Announcement
04 · The Call

Final Verdict
↓ DOWNGRADED to HIGH (8.5/10)

Why this verdict

  • Unauthenticated remote vector with zero friction at the protocol level: The CVSS 4.0 vector is AV:N/AC:L/AT:N/PR:N/UI:N — an attacker needs nothing but network reachability. No credentials, no user click, no race condition. This alone justifies a HIGH floor.
  • Role multiplier: ServiceNow is canonically a high-value enterprise component — 100% of production instances serve as the ITSM/ITOM/CMDB hub containing complete infrastructure topology, incident records, HR PII, and integration credentials to downstream systems. A successful data extraction from ServiceNow yields domain-level reconnaissance data and potentially stored credentials for identity providers, databases, and cloud platforms. The blast radius is tenant-to-domain scale. This sets the verdict floor at HIGH.
  • Cloud auto-patching eliminates ~85-90% of the exposed population: ServiceNow patched all cloud-hosted instances before public disclosure. Only Private Stack (self-hosted) deployments — approximately 500+ organizations out of ~8,000+ customers — remain vulnerable. This massive reduction in attack surface is the primary reason this is not CRITICAL.
  • 'Certain circumstances' qualifier narrows exploitability further: The vendor's own description includes the hedge *'in certain circumstances,'* indicating that not all unpatched self-hosted instances are exploitable. Without a PoC or technical writeup, the specific triggering configuration is unknown, adding real-world friction not captured in the CVSS vector.
  • No PoC, no exploitation, 1-day-old disclosure: Zero public exploit code exists. No researcher has published technical details. No in-the-wild exploitation has been observed. The weaponization timeline is measured in weeks to months, not hours.
  • Adjacent CVEs compound risk for self-hosted customers: This CVE sits alongside CVE-2026-13016 (SQLi, 9.3), CVE-2026-86858 (privesc via GraphQL, 8.7), CVE-2026-86859 (unauth record disclosure, 8.7), and CVE-2026-86857 (auth bypass, 8.4). Self-hosted instances unpatched for -86860 are likely unpatched for all five, creating a composite attack surface that's worse than any single CVE.

Why not higher?

A CRITICAL assessment would require either active exploitation, a public PoC shortening the weaponization window, or a majority of the installed base being exposed. None of these conditions are met. Cloud auto-patching removed the vast majority of ServiceNow instances from the vulnerable population before disclosure. The remaining self-hosted footprint (~500+ orgs) is significant but not fleet-scale, and many Private Stack deployments are behind VPN or air-gapped by design. The 'certain circumstances' qualifier further limits exploitability within that already-small population.

Why not lower?

A MEDIUM assessment would understate the risk for the self-hosted minority that IS exposed. The vulnerability is unauthenticated, requires no user interaction, and targets a platform that by definition contains crown-jewel enterprise data — CMDB, HR records, integration credentials. The CVSS 4.0 vector shows subsequent-system impact (SC:H/SI:H), meaning successful exploitation doesn't just read data — it enables downstream compromise. For any organization running an unpatched Private Stack instance, this is a genuine emergency. The deployment-role floor of HIGH is binding.

05 · Compensating Control

1
HIGH 8.5→MEDIUM 5.5
SEVERITY REDUCED
Restrict network access to ServiceNow AI Platform API endpoints — Place self-hosted ServiceNow instances behind a WAF or reverse proxy and block unauthenticated access to AI Platform API paths (/api/now/ai/, /api/sn_ai_platform/, and related endpoints). This breaks Step 2 of the attack path by preventing unauthenticated probing of the authorization boundary. Deploy within 30 days per the noisgate mitigation SLA for HIGH-severity findings.
2
HIGH 8.5→IGNORE 0.0
SEVERITY REDUCED
Apply the vendor patch to all self-hosted instances immediately — Install the appropriate hot fix for your release branch: Yokohama Patch 13 HF 5a, Zurich Patch 10 HF 3b/4a W32 or Patch 11 HF 3, Australia Patch 2 HF 4b W32 / Patch 4 HF 3 / Patch 5. Cloud-hosted instances are already patched. Self-hosted customers must install manually. Prioritize within 30 days per noisgate mitigation SLA.
3
HIGH 8.5→HIGH 7.5
SCORE ONLY
Enable enhanced audit logging on ServiceNow instances — Turn on system audit logging for all unauthenticated API access attempts and configure alerts for bulk data access patterns. This doesn't prevent exploitation but ensures detection within minutes, enabling rapid incident response. Configure SIEM ingestion of ServiceNow syslogs.
4
HIGH 8.5→HIGH 7.0
SCORE ONLY
Rotate integration credentials stored in ServiceNow — If your ServiceNow instance stores credentials for downstream systems (LDAP bind accounts, cloud API keys, CMDB discovery credentials), rotate them proactively. This limits the blast radius of a potential data extraction by invalidating any credentials an attacker may have already obtained.
5
HIGH 8.5→IGNORE 0.0
SEVERITY REDUCED
Verify cloud-hosted instance patch status — Even though ServiceNow states cloud instances were auto-patched, verify your specific instance is running a fixed version by checking stats.do or the System Diagnostics page. Trust but verify — confirm the build tag matches a patched release.
What doesn't work
  • IP allowlisting alone — ServiceNow instances must be accessible to authorized users, often from diverse networks. Overly restrictive IP rules break legitimate access without addressing the authorization flaw itself.
  • MFA/SSO hardening — This vulnerability is *unauthenticated*. The attacker never hits the login flow. MFA, SSO, and session management controls are entirely bypassed by the missing authorization check.
  • ServiceNow ACLs and business rules — The vulnerability operates below the application-layer access control model. ServiceNow's built-in ACL system is the control that's broken; adding more ACLs to a broken authorization engine doesn't fix the underlying flaw.
06 · Verification

Crowdsourced verification payload.

Run this script from any workstation with curl and network access to the target ServiceNow instance. Usage: ./check_cve_2026_86860.sh https://your-instance.service-now.com — no authentication required. The script queries the instance's build information endpoint and compares the detected version/patch level against known-fixed releases.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_86860.sh — ServiceNow AI Platform Missing Authorization Check
# CVE-2026-86860 | CWE-862 | noisgate verification script
# Usage: ./check_cve_2026_86860.sh <instance_url>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

if [ $# -lt 1 ]; then
  echo "Usage: $0 <servicenow_instance_url>"
  echo "Example: $0 https://mycompany.service-now.com"
  exit 2
fi

INSTANCE_URL="${1%/}"
TIMEOUT=15

echo "[*] Checking CVE-2026-86860 patch status for: $INSTANCE_URL"
echo ""

# Attempt to fetch build info from stats.do (unauthenticated on many instances)
BUILD_INFO=$(curl -sk --max-time "$TIMEOUT" "${INSTANCE_URL}/stats.do" 2>/dev/null || true)

if [ -z "$BUILD_INFO" ]; then
  # Fallback: try xmlstats.do
  BUILD_INFO=$(curl -sk --max-time "$TIMEOUT" "${INSTANCE_URL}/xmlstats.do" 2>/dev/null || true)
fi

if [ -z "$BUILD_INFO" ]; then
  echo "[!] UNKNOWN — Could not retrieve build information from $INSTANCE_URL"
  echo "    stats.do and xmlstats.do may be restricted. Check manually:"
  echo "    System Diagnostics > Stats > Build tag"
  exit 2
fi

# Extract build tag / version info
BUILD_TAG=$(echo "$BUILD_INFO" | grep -iE '(build tag|build_tag|Build name)' | head -1 | sed 's/.*[>:] *//;s/<.*//' | xargs 2>/dev/null || true)

if [ -z "$BUILD_TAG" ]; then
  BUILD_TAG=$(echo "$BUILD_INFO" | grep -ioE '(yokohama|zurich|australia)[^<"]*' | head -1 | xargs 2>/dev/null || true)
fi

if [ -z "$BUILD_TAG" ]; then
  echo "[!] UNKNOWN — Could not parse build tag from instance response."
  echo "    Manually check: System Diagnostics > Stats"
  echo "    Compare against fixed versions:"
  echo "      Yokohama: Patch 13 Hot Fix 5a+"
  echo "      Zurich:   Patch 10 HF 3b+ / Patch 11 HF 3+"
  echo "      Australia: Patch 2 HF 4b W32+ / Patch 4 HF 3+ / Patch 5+"
  exit 2
fi

echo "[*] Detected build tag: $BUILD_TAG"
echo ""

# Normalize to lowercase for matching
BT_LOWER=$(echo "$BUILD_TAG" | tr '[:upper:]' '[:lower:]')

# Check release family and patch level
check_vulnerable() {
  local bt="$1"

  if echo "$bt" | grep -q 'yokohama'; then
    # Fixed in Patch 13 Hot Fix 5a
    local patch_num=$(echo "$bt" | grep -oE 'patch[_ ]?([0-9]+)' | grep -oE '[0-9]+' | head -1)
    if [ -z "$patch_num" ]; then return 2; fi
    if [ "$patch_num" -lt 13 ]; then return 1; fi
    if [ "$patch_num" -gt 13 ]; then return 0; fi
    # Patch 13 — check hot fix
    if echo "$bt" | grep -qiE 'hot[_ ]?fix[_ ]?([5-9]|[1-9][0-9])'; then return 0; fi
    return 1

  elif echo "$bt" | grep -q 'zurich'; then
    local patch_num=$(echo "$bt" | grep -oE 'patch[_ ]?([0-9]+)' | grep -oE '[0-9]+' | head -1)
    if [ -z "$patch_num" ]; then return 2; fi
    if [ "$patch_num" -gt 11 ]; then return 0; fi
    if [ "$patch_num" -lt 10 ]; then return 1; fi
    if [ "$patch_num" -eq 11 ]; then
      if echo "$bt" | grep -qiE 'hot[_ ]?fix[_ ]?([3-9]|[1-9][0-9])'; then return 0; fi
      return 1
    fi
    # Patch 10 — need HF 3b+ or HF 4a+
    if echo "$bt" | grep -qiE 'hot[_ ]?fix[_ ]?([4-9]|[1-9][0-9])'; then return 0; fi
    if echo "$bt" | grep -qiE 'hot[_ ]?fix[_ ]?3[b-z]'; then return 0; fi
    return 1

  elif echo "$bt" | grep -q 'australia'; then
    local patch_num=$(echo "$bt" | grep -oE 'patch[_ ]?([0-9]+)' | grep -oE '[0-9]+' | head -1)
    if [ -z "$patch_num" ]; then return 2; fi
    if [ "$patch_num" -ge 5 ]; then return 0; fi
    if [ "$patch_num" -eq 4 ]; then
      if echo "$bt" | grep -qiE 'hot[_ ]?fix[_ ]?([3-9]|[1-9][0-9])'; then return 0; fi
      return 1
    fi
    if [ "$patch_num" -le 1 ]; then return 1; fi
    if [ "$patch_num" -eq 2 ]; then
      if echo "$bt" | grep -qiE 'hot[_ ]?fix[_ ]?4[b-z]'; then return 0; fi
      if echo "$bt" | grep -qiE 'hot[_ ]?fix[_ ]?([5-9]|[1-9][0-9])'; then return 0; fi
      return 1
    fi
    if [ "$patch_num" -eq 3 ]; then return 1; fi
    return 2
  fi

  return 2
}

check_vulnerable "$BT_LOWER"
RESULT=$?

echo "======================================"
if [ $RESULT -eq 0 ]; then
  echo "PATCHED — Build tag indicates a fixed version."
  echo "CVE-2026-86860 is remediated on this instance."
  exit 0
elif [ $RESULT -eq 1 ]; then
  echo "VULNERABLE — Build tag indicates an unpatched version."
  echo "CVE-2026-86860 affects this instance. Apply the appropriate hot fix:"
  echo "  Yokohama: Patch 13 Hot Fix 5a"
  echo "  Zurich:   Patch 10 HF 3b / HF 4a W32, or Patch 11 HF 3"
  echo "  Australia: Patch 2 HF 4b W32, Patch 4 HF 3, or Patch 5"
  exit 1
else
  echo "UNKNOWN — Could not determine patch status from build tag."
  echo "Manually verify against fixed versions listed above."
  exit 2
fi
Peer Review

What defenders are saying.

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