ServiceNow's Secret Advisory Left Enterprises Unaware Their IT Data Was Exposed

On June 9, 2026, BleepingComputer published details of a ServiceNow security incident that the company had patched four days earlier without any public announcement. The vulnerability: a Scripted REST Resource endpoint configured with requires_authentication = false, meaning any unauthenticated HTTP request could query customer instance tables — the same tables that store IT support tickets, employee records, security incident reports, and in many cases, credentials and API tokens embedded in ticket descriptions.

The affected endpoint was /api/now/related_list_edit/create. Suspicious activity was detected June 2–3. ServiceNow pushed a fix to hosted instances on June 5. The support bulletin — KB3067321 — was gated: visible only to logged-in ServiceNow users and employees, not the general public. Most enterprises running ServiceNow learned about it from news coverage, not from their vendor.

Key Takeaways

• ServiceNow identified suspicious activity on June 2–3, 2026, traced to unauthenticated queries against customer instance tables via a misconfigured API endpoint.
• The same vulnerability had been reported through ServiceNow's bug bounty program on April 22, 2026 — 44 days before the patch was deployed.
• Data at risk includes IT support ticket content, employee names and email addresses, internal documentation, security investigation records, and any credentials or tokens embedded in ticket notes or attachments.
• ServiceNow serves more than 8,000 enterprise customers, including a majority of the Fortune 500, and processed 85% of its customers on cloud-hosted instances affected by this release configuration.
• ServiceNow's attribution: the company said the activity was conducted by security researchers submitting bug bounty reports, not malicious actors — though a third IP address, 51.159.98.241, remains unexplained.
• Compliance teams at affected organizations face a potential GDPR 72-hour notification clock, depending on whether personal data was accessed and in which jurisdiction the affected employees reside.

What Data Lives in a ServiceNow Instance?

ServiceNow is not a peripheral SaaS tool. For most enterprises, it is the central nervous system of IT operations: the platform where employees submit password reset requests, report phishing emails, log security incidents, and document internal processes. Understanding what gets stored there helps explain why read access to customer instance tables is a serious exposure, not a theoretical risk.

A typical enterprise ServiceNow deployment contains: full names and email addresses of every employee who has ever submitted a support ticket; device information, IP addresses, and operating system details submitted with tickets; internal documentation including network diagrams, runbooks, and configuration guides; security incident records describing past attacks, vulnerability disclosures, and remediation steps; and in many cases, plaintext API keys, passwords, and authentication tokens that employees paste into ticket descriptions — despite policies prohibiting it.

The employee email directory problem is particularly acute. IT support systems accumulate years of ticket history. An attacker with authenticated read access to the ServiceNow instance table can effectively reconstruct a complete employee roster with email addresses — the same data used for spear-phishing and business email compromise campaigns. The Pitney Bowes breach illustrated how a single phished employee email entry point became 8.2 million exposed customer records; the ServiceNow exposure creates precisely the employee-email intelligence that makes those initial phishing campaigns possible.

The 44-Day Window

The timeline is the most damaging part of this story for ServiceNow. On April 22, 2026, a security researcher submitted a bug bounty report describing the authentication bypass in the Scripted REST Resource endpoint. ServiceNow received that report, triaged it, and did not deploy a fix until June 5 — 44 days later.

What was happening in that window? ServiceNow has not said publicly. The company's post-incident statement attributed the observed suspicious activity specifically to security researchers submitting additional bug bounty reports on June 7. But the activity detected on June 2–3 predates those submissions. The unexplained IP address — 51.159.98.241 — was flagged in incident reports as the source of the June 2–3 queries. ServiceNow has not addressed it specifically in public communications.

The patch was deployed to hosted instances — meaning cloud-hosted customers got the fix automatically on June 5. Self-hosted customers running affected releases had to apply it manually. ServiceNow's advisory (KB3067321) identified two impacted populations: customers on the "Australia" platform release, and customers on earlier releases who had made specific configuration changes. The advisory did not specify how many organizations fell into each category, and because it was gated, self-hosted customers who were not actively monitoring ServiceNow's support portal may not have seen it at all.

The Gated Advisory Problem

ServiceNow's decision to handle the incident through a gated support bulletin rather than a public security advisory has drawn criticism from security researchers. The Non-Human Identity governance analysis from Unosecur describes the core problem: "Most enterprises running ServiceNow have no idea their data may have been accessed. They found out from the press, not their vendor."

This creates a compliance timing problem. Under the GDPR, data controllers — in this case, the enterprises using ServiceNow, not ServiceNow itself — must notify their supervisory authority within 72 hours of becoming aware of a personal data breach. If a European enterprise's employee data was accessed on June 2–3, and that enterprise learned about it on June 9 when BleepingComputer published, the notification clock started June 9. Whether ServiceNow's June 5 patch constituted adequate remediation, or whether the June 2–3 access constitutes a reportable breach, is a question enterprise legal teams are currently working through.

The practical difficulty for affected organizations is that ServiceNow has not released a comprehensive list of which customers were affected, what tables were queried, or what records were accessed. Customers who received support cases from ServiceNow know they were in scope. Everyone else is working from a gated advisory that most of them never saw.

What Security Teams Should Do Now

If your organization runs ServiceNow, the immediate action list from incident response teams and the Triskele Labs technical advisory is clear:

• Verify patch status. Confirm your hosted instance received the June 5 update. Self-hosted customers should verify they are on a patched release and review KB3067321 directly in ServiceNow's support portal.
• Pull access logs for June 2–5. Review logs for any requests to /api/now/related_list_edit/create from unexpected source IPs, particularly 51.159.98.241. Identify which tables, if any, were queried.
• Audit what's in your tickets. Conduct a search of recent ticket content for plaintext credentials, API tokens, and passwords. This is good hygiene regardless of this incident and should be a periodic review in any ITSM environment.
• Rotate exposed secrets. Any API token, password, or authentication credential that appeared in ServiceNow ticket text during or before the exposure window should be considered compromised and rotated immediately.
• Assess your GDPR notification obligations. If your ServiceNow instance stores personal data about EU residents — which virtually every enterprise deployment does — work with your DPO to determine whether the June 2–3 activity constitutes a reportable breach under Articles 33 and 34.

The Broader Pattern

The ServiceNow incident fits a pattern that defined enterprise security in the first half of 2026: attackers and researchers finding that the same ITSM and CRM platforms companies rely on for operational data are quietly accumulating sensitive employee information in ways that security teams haven't fully audited. The ShinyHunters campaign against Salesforce followed the same logic — get access to the customer-of-record platform, and you get access to everything the enterprise stored there.

ServiceNow's vulnerability was different in mechanism — an API misconfiguration rather than a vishing attack — but identical in consequence: unauthenticated query access to tables that enterprises treated as internal and secure. The non-human identity problem documented by Unosecur is the underlying issue: in complex enterprise SaaS environments, authentication configurations drift. A Scripted REST Resource added during a customization project, set to unauthenticated access for testing, gets forgotten. The platform ships a new release. Nobody audits the setting. And one day an IP address in Paris starts running queries.

For the 8,000 enterprises that depend on ServiceNow — and particularly for the Fortune 500 companies whose IT operations run through it — the real lesson of KB3067321 is not that ServiceNow was hacked. It's that enterprise security posture includes every SaaS platform in the stack, and most organizations have not audited those platforms' authentication configurations since deployment.

Sources: BleepingComputer: ServiceNow discloses security incident exposing customer data | SOCRadar: ServiceNow Breach Customer Data Exposed Through Unauthenticated API Access | Triskele Labs: ServiceNow Security Incident Technical Advisory | Unosecur: ServiceNow KB3067321 — The NHI Governance Gap It Exposed.