On 5 June 2026, ServiceNow applied a security update to its hosted customer instances. Four days later, a bulletin appeared behind the customer support login, identified as KB3067321, describing a security issue "that could allow an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended." The company confirmed it had detected anomalous activity and, for a subset of customers, evidence of successful queries against instance tables. No malware was involved, and no zero-day was chained through stolen credentials. An API endpoint simply did not ask who was calling.

Most coverage is treating this as a platform vulnerability story, and at one level, it is. For the teams running ServiceNow, it is something more uncomfortable: a forced audit of what has accumulated inside their tickets over the years. That second story is the one worth dwelling on.

How one flag bypassed all layers of access control

The technical detail beneath the careful language came from the community. Administrators comparing notes on Reddit identified a REST endpoint at /api/now/related_list_edit/create configured with requires_authentication=false, and reported that the fix set the flag to true. Administrators also shared indicators of compromise, most notably API requests originating from IP address 51.159.98.241. The issue primarily affects customers on the Australia platform release or earlier releases with certain configuration changes. Affected customers have been contacted through support cases. No CVE has been assigned; ServiceNow says it is still evaluating whether to publish one.

One flag. That is the part that should give every architecture review pause. An unauthenticated read path does not merely bypass the login screen. It bypasses the entire access control hierarchy built on top of authentication, every role and ACL that assumes a known caller. The attacker did not need to escalate privileges because the permission boundary had already been removed from the equation. Reading was enough. ServiceNow has since disclosed that it received a confidential bug bounty submission describing this issue on April 22. The security update was not applied until June 5, after anomalous activity against customer instances on 2 and 3 June. Six weeks between confirmed disclosure and patch deployment. The window was not a zero-day. It was a known issue. The patch came six weeks later.

One claim deserves to be flagged precisely because it is unconfirmed. A Reddit user has claimed their security team reported the flaw to ServiceNow and that the company had been aware of it internally since early April, initially classifying it as non-urgent. The Hacker News has reported the claim; ServiceNow has not commented on it. Treat it as an allegation, not a finding. The confirmed timeline is damaging enough on its own.

How tickets became the most ungoverned credential store in your environment

To understand why queries against instance tables matter, look at what those tables hold. ServiceNow instances are the operational memory of an enterprise: IT support tickets, employee records, asset inventories, security incident reports, integration configurations, workflow data. And inside the tickets themselves sits a quieter category of data. API keys were pasted by an engineer reproducing a failed integration. Service account passwords are shared between teams during an outage. Database connection strings, kubeconfig fragments, screenshots of admin consoles, attachments captured during troubleshooting sessions. Engineers do not put secrets in tickets out of carelessness. They do it because the ticket is where the work is, and pasting the credential is what unblocks the next step at 2 a.m.

Measure that store against the properties you would demand from an actual vault. Per-secret access scoping: absent; anyone who can read the ticket can read the credential. Rotation: none; the pasted value never expires. Read auditing: partial at best and rarely reviewed. Retention: indefinite by default. A password pasted into a ticket in 2023 still authenticates today unless someone deliberately rotated it, and the person who pasted it has probably changed teams since. This is not a hypothetical attack surface. In October 2023, attackers breached Okta's support case management system and harvested HAR files that customers had uploaded for troubleshooting.

Those files contained session tokens; the attackers used them to hijack live sessions at five customers and accessed the files of 134 organizations. The entry point, fittingly, was a service account stored inside the support system itself. The support platform was the vault nobody had thought to call a vault. Two and a half years later, the same lesson arrives through a different vendor. BleepingComputer made the broader pattern explicit in its coverage: support case data has become a favored target precisely because tickets carry credentials, tokens, and internal documentation. Attackers have read the architecture correctly. Most defenders have not caught up.

Why ticket-resident credentials escape every control you already run

Three structural reasons explain why ticket-resident credentials escape every control you already run.

Secrets in tickets are unstructured data. Secret scanning points at repositories and storage buckets. DLP points at email and endpoints. The ITSM platform, which holds more live credentials than most of those systems combined, is rarely on either list. It is classified as a workflow tool, so it inherits workflow-tool governance.

The platform's permission model only governs authenticated callers. Your last access review of ServiceNow roles and ACLs may have been thorough and accurate. This incident revolved around all of it because the review assumed every caller passes through authentication first. The review was both correct and irrelevant.

Queried is not the same as exfiltrated, and the difference depends on whether you enabled logging. ServiceNow confirmed successful queries for a subset of customers. Whether data was read, copied, or removed is a distinction that matters enormously for notification decisions, and it can only be reconstructed from transaction and REST logs. If verbose API logging was not enabled before the incident, that evidence does not exist. Notification decisions end up being made on guesswork.

How vendor disclosure timing breaks your GDPR notification posture

The patch shipped on 5 June. The bulletin appeared on 9 June, behind a customer login. That four-day gap matters beyond the operational inconvenience.

Under GDPR Article 33, a data controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach. The processor's obligation is to notify the controller without undue delay upon becoming aware of a breach. Both obligations are triggered by awareness, not by the completion of an investigation, nor by patch deployment.

A silent patch starts no clocks. A gated advisory starts them late and unevenly. This is not a verdict on ServiceNow's triage, which happened under uncertainty that cannot be seen from the outside. It is a structural point about the dependency that enterprise SaaS creates. A breach notification posture that assumes vendors will promptly and publicly disclose incidents is built on a dependency most vendors will not reliably meet. ServiceNow is not unusual here. Most operate the same way.

The notification gap is an argument for internal detection that does not depend on vendor disclosure timing, specifically REST API logging and behavioral baselines that surface anomalous access to systems of record before any bulletin arrives.

Where identity security intersects with this

Strip the incident to its identity skeleton, and three checkpoints emerge. This is the lens we build Unosecur around, and it applies whether or not you run our platform.

Inventory. A credential at rest inside a ticket is a non-human identity in your estate, no different in consequence from a service account key in a config file. You cannot rotate what you have not discovered, and discovery must extend to SaaS data planes, not just cloud IAM. If your NHI inventory has never looked inside your ITSM platform, it is an inventory of the identities that were easy to find.

Posture. requires_authentication=false is not a quirk of one vendor's REST framework. It is an identity posture finding, the same class of failure as a public storage bucket: a resource reachable without a verified identity. Posture management should surface unauthenticated read paths continuously because they are created continuously.

Detection. The reported access pattern, a single origin issuing low-volume queries across many tenants, is exactly the shape behavioral detection exists to catch. Identity threat detection that baselines normal access to a system of record can flag an anomalous reader in hours, not in the four-day window between a patch and a bulletin.

The investigation playbook for affected ServiceNow instances

1. Confirm notification status, then trust it only as far as it goes. Check whether ServiceNow has opened a support case against the instance. No case means ServiceNow observed no targeting within their detection coverage. Proceed with the remaining steps regardless.

2. Preserve and query logs before anything else changes. Export transaction logs covering at least 1 June through the patch date. Filter for requests to /api/now/related_list_edit (this catches all sub-paths including /create) where user = guest, user = anonymous, user is empty, or session ID is null. Cross-reference against IP 51.159.98.241. A 200 response from an unauthenticated session confirms data was returned. Flag all requests with large response sizes. Default retention windows are short, and every configuration change made before this export pollutes the record.

3. Audit every scripted REST resource for the same pattern. The patched endpoint is one instance of a class. Enumerate custom and platform REST resources, verify the authentication requirements for each, and determine what an unauthenticated caller could access. Fix the class, not the headline.

4. Treat ticket-resident secrets as exposed and rotate in priority order. Integrate service accounts and credentials with administrative scope first. Then API keys, connection strings, and tokens found in ticket descriptions, work notes, and attachments. Search all three fields; attachments are where the most sensitive material tends to accumulate. Redeploy dependent services after rotation, or the old secrets remain live.

5. Enable verbose API logging now. Not for this incident. For the next one. Without request and response logging for REST resources, the distinction between queries and exfiltration is permanently unknowable, and notification decisions are made without the evidence to support them.

6. Get secrets out of tickets structurally. Reference vault entries instead of pasting values. Put redaction on the intake path. Point secret scanning at ITSM exports on a schedule. Set retention limits on closed tickets. The goal is to make the vault link the easy path and the pasted credential the expensive one, because engineers will always take the easy path at 2 a.m.

The patch closed an endpoint. The habit stays open.

ServiceNow fixed the flag within days of detecting the activity. The engineering response looks competent. The structural condition it exposed is not theirs to fix. Every enterprise runs a system of record where people paste whatever unblocks the next step. Nearly every one of those systems is governed like a workflow tool rather than the credential store it has quietly become. The next unauthenticated read path will open somewhere else, through some other forgotten flag. When it does, whether your vendor ships a fix in four days will matter far less than what a reader found in your tickets during those four days. That audit is available to you today, before any bulletin requires it.

How Unosecur approaches non-human identity governance

The credential exposure this incident revealed is not a ServiceNow problem. It is a non-human identity governance problem that exists in every enterprise running an ITSM platform, a support workflow, or a ticketing system where engineers paste what they need to unblock the next step.

Unosecur's Unified Identity Fabric builds a complete inventory of every non-human identity across cloud, SaaS, and on-premises environments, including service accounts that were never formally provisioned and credentials that entered the estate through workflows rather than vaults. Each NHI is scored based on privilege level, activity pattern, and access scope. Accounts that carry admin-equivalent permissions with no documented owner, no rotation schedule, and no recent usage are surfaced immediately.

On posture, Unosecur continuously monitors the NHI lifecycle from creation through deprovisioning, flagging permission changes, detecting when credentials are used outside expected behavior, and identifying over-privileged accounts before they become incident evidence. Unauthenticated access paths and misconfigured endpoint permissions are the same class of posture finding as an orphaned OAuth grant or a service account with standing admin access.

On detection, Unosecur's ITDR module baselines normal access behavior across every human and non-human identity at runtime. When a service account that normally accesses one system suddenly queries another, or when an access pattern deviates from its established baseline, the anomaly is flagged, and remediation is available in one click. Credential rotation, access revocation, and account suspension are automated responses, not manual tasks. The governance gap that turns a pasted credential into a reachable attack surface is discoverable, measurable, and closeable. That work does not start with a bulletin.

‍