ServiceNow discloses security incident exposing customer data

1. Executive summary

ServiceNow has confirmed a security incident wherein threat actors exploited an unauthenticated access flaw in a specific API endpoint to query data from customer instances. The vulnerability allowed unauthorized users to bypass authentication controls, potentially exposing sensitive enterprise data including IT support tickets, employee records, and internal documentation. ServiceNow applied a corrective update to hosted instances on June 5, 2026, and is notifying impacted customers directly. For EMEA financial services, the primary risk involves the exfiltration of operational secrets, credentials, or PII stored within support cases and configuration tables, triggering potential incident reporting obligations under DORA and NIS2 depending on data sensitivity and scope.

2. Regulatory framing

3. Attack chain

1. Reconnaissance/Access: Threat actors identified and targeted a vulnerable API endpoint within the ServiceNow environment that did not enforce strict authentication checks.
2. Exploitation: Actors exploited the unauthenticated access flaw to send queries to the API endpoint.
3. Data Exfiltration: Successful queries allowed actors to retrieve data from customer instance tables. The specific tables accessed vary by customer configuration but commonly include IT support tickets, employee records, and asset inventories.
4. Remediation: ServiceNow detected "anomalous activity," applied a security update on June 5, 2026, to restrict the API endpoint to authenticated users only, and began notifying affected customers.

Unconfirmed Details

Community discussion on Reddit suggests the specific vulnerable endpoint may be /api/now/related_list_edit/create. However, ServiceNow has not publicly confirmed this specific path in their official bulletin, and this attribution remains unverified by the vendor. The exact scope of data exfiltrated per customer is also unconfirmed and relies on individual forensic analysis of instance logs.

4. Mitigation & containment

Priority 1 (Within 24h): Verification and Log Analysis

• Confirm Notification Status: Check for direct communication from ServiceNow Support. If no support case has been opened by ServiceNow regarding this incident, the instance is currently believed to be unaffected, but verification is required.
• Log Review: Immediately query ServiceNow instance logs (System Logs > All or sys_log table) for entries corresponding to the timeframe prior to June 5, 2026. Filter for API calls originating from unexpected IP ranges or lacking valid session tokens.
• Data Scope Assessment: Identify which tables (e.g., incident, alm_asset, sys_user) are accessible via the suspected endpoint and assess the sensitivity of stored data (PII, credentials, secrets).

Priority 2 (Within 72h): Configuration and Access Review

• ACL Verification: Manually verify Access Control Rules (ACLs) for all custom and out-of-box API endpoints. Ensure no other endpoints have inadvertently been configured to allow public or unauthenticated access.
• Credential Rotation: If logs indicate potential exposure of support tickets containing secrets, API keys, or passwords, initiate immediate rotation of those credentials across all connected systems.
• Vendor Engagement: Engage with ServiceNow account representatives to request specific details on the query volume and data types accessed for your specific instance ID.

Priority 3 (Within 7 days): Long-term Hardening

• API Hygiene: Conduct a full audit of all active REST and SOAP APIs. Disable unused endpoints and enforce strict authentication policies (OAuth 2.0 or Basic Auth with IP restrictions) for all remaining interfaces.
• Third-Party Risk Update: Update the ICT third-party risk register to reflect this incident and review ServiceNow's adherence to SLAs regarding incident notification timelines under DORA Article 28.

5. Indicators of compromise

No specific network IOCs (IPs, Domains) or file hashes have been released by ServiceNow or observed in the source material. The primary indicator is the presence of unauthenticated API requests to specific endpoints.

No indicators of compromise available in the source material.

6. Detection

While specific attacker IPs are unavailable, detection can be built around the unauthenticated access pattern and the suspected endpoint structure mentioned in community reports.

YARA Rule

Note: This rule targets potential script artifacts or logs containing the specific API path structure mentioned in community discussions. It is not a binary rule but useful for log scanning or script identification.

rule Servicenow_Unauth_API_Attempt {
    meta:
        author = "Adverse Trace"
        date = "2026-06-09"
        reference = "https://www.bleepingcomputer.com/news/security/servicenow-discloses-security-incident-exposing-customer-data/"
        description = "Detects references to the suspected vulnerable ServiceNow API endpoint used in the June 2026 incident."
    strings:
        $api_path = "/api/now/related_list_edit/create" ascii wide
        $endpoint_generic = "/api/now/" ascii
        $unauth_context = "unauthenticated access" ascii wide
    condition:
        $api_path or ($endpoint_generic and $unauth_context)
}

Sigma Rule

Detects potential exploitation attempts via web logs focusing on the API endpoint and HTTP 200 responses without prior authentication context (logic to be tuned per SIEM).

title: ServiceNow Unauthenticated API Access Attempt
id: 9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects HTTP requests to the vulnerable ServiceNow API endpoint associated with the June 2026 incident.
author: Adverse Trace
date: 2026/06/09
references:

    - https://www.bleepingcomputer.com/news/security/servicenow-discloses-security-incident-exposing-customer-data/
logsource:
    category: webserver
    service: apache
    # Applicable to any web server logging ServiceNow access
detection:
    selection:
        c-uri|contains:

            - '/api/now/related_list_edit/create'
            - '/api/now/'
        c-status: 200
    # Note: Further filtering for missing authentication headers is required based on specific log schema
    condition: selection
falsepositives:

    - Legitimate automated internal tools if not properly authenticated in logs
level: high
tags:

    - attack.initial_access
    - attack.t1190
    - dora.article17

7. Sources

• BleepingComputer, "ServiceNow discloses security incident exposing customer data", https://www.bleepingcomputer.com/news/security/servicenow-discloses-security-incident-exposing-customer-data/, 2026-06-09.
• ServiceNow (via BleepingComputer citation), "Support Bulletin regarding security update applied June 5, 2026", Accessed via customer portal.

8. Adverse Trace position

We assess the severity of this incident as High for entities utilizing ServiceNow for ITSM, HR, or Security Operations, given the high likelihood of sensitive data residency within these modules. While the vendor has patched the vulnerability, the window of exposure prior to June 5, 2026, presents a tangible data leakage risk. The lack of public technical specifics necessitates proactive log analysis by clients rather than reliance on signature-based blocking alone. Adverse Trace will monitor for further vendor disclosures regarding the specific CVE or attack vectors and will update this advisory if confirmed IOCs emerge. Clients should prepare for potential DORA Article 17 notification requirements should internal forensics confirm data exfiltration.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.