# ServiceNow Security Incident Exposes Customer Data Through Unauthenticated API Flaw


ServiceNow, the enterprise software platform managing IT operations, HR workflows, and critical business processes for thousands of organizations worldwide, has disclosed a significant security incident stemming from an unauthenticated API endpoint vulnerability. The flaw allowed attackers to query and access sensitive customer instance data without valid credentials, compromising information including support tickets, employee records, credentials, API tokens, and internal documentation.


The company applied a security update to hosted customer instances on June 5, 2026, after detecting anomalous activity exploiting the vulnerability. ServiceNow has notified affected customers through private support bulletins rather than public disclosure, raising questions about the scope and severity of the breach.


## The Threat


On June 5, 2026, ServiceNow deployed a security patch to address what the company describes as "a security issue that could allow an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended." The vulnerability stemmed from improper API endpoint configuration that exposed authenticated resources to unauthenticated requests.


According to ServiceNow administrators discussing the incident on public forums, the vulnerable endpoint is located at /api/now/related_list_edit/create. The critical misconfiguration was the parameter requires_authentication=false, which allowed any attacker to make requests to this endpoint without providing valid credentials or session tokens. The security update changed this setting to requires_authentication=true, effectively closing the exploit path.


System administrators have identified indicators of compromise, with multiple reports of suspicious API requests originating from the IP address 51.159.98.241. These requests specifically targeted the vulnerable endpoint, suggesting attackers were actively exploiting the flaw to extract data from affected instances.


## Background and Context


ServiceNow is a critical enterprise platform used by over 8,000 organizations globally, managing operations across IT service management (ITSM), human resources, financial services, customer service management, and security operations. The platform acts as a central repository for enterprise workflow data, making it an attractive target for threat actors seeking to compromise entire organizations through a single breach.


The vulnerability affects customers running the Australia platform release or those on older releases who applied certain custom configuration changes to their instances. This suggests the flaw may have existed for an extended period, particularly impacting organizations with non-standard deployments or those on legacy versions.


ServiceNow's quiet notification approach—using a support portal bulletin rather than public disclosure—has drawn criticism from security researchers. The company initially stated it is "still evaluating whether it will publish a CVE" for the issue, meaning enterprises may not have formal vulnerability tracking for remediation purposes.


## Technical Details


The vulnerability centers on REST API endpoint misconfiguration, a common but potentially devastating security flaw. The /api/now/related_list_edit/create endpoint was designed to handle data modifications within ServiceNow instances but was incorrectly configured to permit unauthenticated access.


How the Attack Works:


| Stage | Description |

|-------|-------------|

| Discovery | Attackers identify the API endpoint through instance enumeration or public documentation |

| Exploitation | Attackers craft HTTP requests to the endpoint without authentication headers or tokens |

| Data Extraction | The misconfigured endpoint returns data from database tables that should require authentication |

| Escalation | Attackers systematically query multiple tables to access sensitive information |


API endpoint misconfiguration is particularly dangerous because:


  • Hidden by default: Many organizations don't actively monitor API traffic for authentication headers
  • Persistent access: Unlike credential-based attacks, misconfigured endpoints remain exploitable until patched
  • Bulk data extraction: Attackers can systematically query entire databases rather than targeting specific records
  • Difficult to detect: Normal API usage patterns don't necessarily flag authentication-free requests

    • ## What Was Exposed


    ServiceNow instances typically store highly sensitive enterprise data. While the company has not disclosed specific types of data accessed during the attacks, support tickets and related lists commonly contain:


  • Credentials and Secrets: Passwords, API keys, and authentication tokens shared during IT troubleshooting
  • Employee Records: Names, email addresses, phone numbers, department information, and employment history
  • Internal Documentation: Architectural diagrams, system configurations, security procedures, and operational runbooks
  • IT Support Tickets: Detailed technical issues, system vulnerabilities identified by internal teams, and remediation steps
  • Asset Inventories: Hardware specifications, software licenses, and infrastructure topology
  • Security Incident Reports: Previous breaches, vulnerabilities discovered, and security testing results
  • Configuration Details: Database connection strings, server addresses, and integration endpoints for corporate systems

    • This information represents a complete blueprint for attackers to understand an organization's infrastructure, identify secondary targets, and craft targeted attacks.


    ## Implications for Organizations


    Immediate Risk:


    Organizations using affected ServiceNow instances face credential compromise as a critical concern. If support tickets shared passwords, API tokens, or SSH keys during troubleshooting—a common practice—attackers now possess valid authentication credentials for downstream systems. This transforms a single API vulnerability into a multi-system breach.


    Supply Chain Exposure:


    ServiceNow data often includes information about third-party vendors, integration partners, and external service providers. An attacker with access to this information can identify and attack these connected organizations, creating a supply chain risk for ServiceNow customers' entire business ecosystem.


    Regulatory Compliance:


    Organizations in regulated industries (healthcare, finance, government) may face compliance violations and notification obligations if personal data was accessed. GDPR, HIPAA, and industry-specific frameworks require notification within specific timeframes, yet ServiceNow's quiet approach may have delayed discovery and reporting.


    ## Recommendations


    For Immediate Action:


  • Review logs immediately: Search ServiceNow audit logs for requests to /api/now/related_list_edit endpoints, particularly from the IP address 51.159.98.241 or other suspicious sources
  • Apply patches: Ensure the June 5, 2026 security update is deployed to all hosted instances
  • Verify configuration: Confirm that requires_authentication=true is set on all API endpoints
  • Enable enhanced logging: Activate detailed API request logging to capture future suspicious activity

    • For Security Teams:


  • Credential rotation: Assume any credentials or tokens shared in support tickets have been compromised; rotate SSH keys, API tokens, and service account passwords
  • Access review: Audit which systems were referenced in exposed support tickets and implement additional monitoring on those systems
  • Incident response: Activate IR procedures to determine if attackers used exposed credentials to access other systems
  • Threat hunting: Search for lateral movement indicators from known-compromised credentials across your infrastructure

    • For Long-Term Prevention:


  • API security program: Implement systematic API discovery, authentication verification, and authorization testing across your ServiceNow environment
  • Secrets management: Use enterprise secret vaults rather than sharing credentials via support tickets; educate teams on secure credential sharing practices
  • Endpoint hardening: Disable unnecessary API endpoints and implement rate limiting to slow mass data extraction
  • Monitoring: Deploy real-time alerts for unauthenticated API requests or unusual data access patterns

    • ---


    ## HackWire Analysis


    This incident exemplifies a troubling pattern in enterprise software security: critical vulnerabilities hidden behind quiet support bulletins while defenders race to patch blind. ServiceNow's decision to defer public disclosure—still evaluating whether a CVE is warranted—treats this as an internal matter despite affecting thousands of organizations globally.


    What's particularly concerning is the vulnerability's nature. Authentication bypass at the API layer isn't a subtle edge case; it's a fundamental security control failure. The fact that requires_authentication=false existed in a production endpoint suggests inadequate security code review practices or a dangerous pattern of relaxing security constraints to "make things work."


    The targeting of support tickets deserves special attention. This shift toward stealing operational intelligence rather than just customer data represents attackers' sophisticated understanding of enterprise IT. A support ticket containing a database connection string is more valuable than 10,000 customer email addresses—it's a direct path into the organization's crown jewels.


    Organizations should assume their compromise window is unknown. The flaw may have existed for months. Threat actors with access to ServiceNow support tickets have effectively been handed a reconnaissance briefing: infrastructure layout, known vulnerabilities your own teams documented, vendor relationships, and shared secrets. The breach doesn't end with the patch; it begins there, as security teams struggle to determine what was accessed and whether attackers leveraged that access.


    ServiceNow's eventual public disclosure of technical indicators (the IP address, endpoint name, configuration details) was only forced by community detection on Reddit. Enterprises deserve better than crowdsourced vulnerability attribution.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Breaches](https://www.hackwire.news/category/breaches) coverage
  • Cross-reference with [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)