ServiceNow KB3067321 shows how unauthenticated APIs bypass IAM

At a glance

What this is: This is an analysis of ServiceNow KB3067321, where an unauthenticated REST endpoint reportedly allowed greater-than-intended access and exposed how ticket data can become an identity security problem.

Why it matters: IAM, NHI, and PAM teams should care because unauthenticated data paths can bypass role and ACL controls, while support systems often hold pasted secrets and operational records that expand blast radius.

By the numbers:

• The article says ServiceNow disclosed the issue six weeks after a confidential bug bounty submission on April 22.

👉 Read Unosecur's analysis of ServiceNow KB3067321 and unauthenticated API access

Context

ServiceNow KB3067321 is best understood as an access-control failure, not just a software bug. The core problem is that an unauthenticated REST path can sit in front of a system that otherwise relies on roles, ACLs, and authenticated sessions to enforce who may read what.

For identity practitioners, the significance is broader than the endpoint itself. ITSM platforms often accumulate secrets, tokens, passwords, and internal records, so an unauthenticated read path can turn a workflow system into a credential exposure surface and a governance blind spot.

The article also frames the incident as a disclosure and notification problem. When evidence of querying exists but logging is limited, teams may be unable to determine whether data was merely read or actually removed, which complicates incident scoping and regulatory decisions.

Key questions

Q: What breaks when a ServiceNow REST endpoint does not require authentication?

A: The access model breaks at the first step because roles and ACLs only work after identity has been established. An unauthenticated endpoint can return data without ever evaluating who the caller is, so the platform’s normal permission hierarchy no longer protects the resource. That turns a configuration issue into an identity control failure.

Q: Why do support tickets increase credential exposure risk?

A: Support tickets often contain API keys, passwords, tokens, and connection strings pasted during troubleshooting. Those values remain readable long after the original incident, because ticketing systems are usually not built for per-secret scoping, rotation, or short retention. The result is credential persistence inside a workflow system that was never meant to act as a vault.

Q: How can teams tell whether API access became a reportable incident?

A: They need enough logging to distinguish a query from exfiltration. Request logs, response-size data, and session context show whether data was merely read, copied, or retained. Without that evidence, teams are forced to make notification and containment decisions on incomplete facts rather than on reconstructable transaction history.

Q: Who is accountable when a SaaS configuration issue exposes an API endpoint to unauthenticated access?

A: Accountability usually spans both the platform owner and the security team. Administrators own the configuration, while security leaders own the control framework, validation process, and monitoring expectations. When a setting creates unintended access, the key question is whether the organization had a reliable way to detect and remediate it before it became visible to attackers.

Technical breakdown

How an unauthenticated REST endpoint bypasses IAM controls

A REST endpoint marked requires_authentication=false accepts requests without establishing a caller identity first. That matters because the rest of the authorization stack, including roles, ACLs, and entitlement checks, assumes the request has already passed authentication. Once that assumption fails, the platform is no longer evaluating who the caller is, only whether the endpoint will answer. In practice, this creates a direct path around the access hierarchy rather than a privilege escalation inside it. The article’s central point is that one flag can turn an apparently governed application into an open read surface.

Practical implication: inventory every unauthenticated API path and treat it as an access-control exception, not a minor configuration detail.

Why ticket data becomes an NHI exposure surface

ServiceNow instances often store operational records that include API keys, service account passwords, connection strings, and other secrets pasted during troubleshooting. Those values behave like non-human identities in practice because they can authenticate systems, not people, and they often outlive the workarounds that introduced them. Tickets are poor substitutes for vaults: access is broad, rotation is absent, retention is long, and auditability is inconsistent. That combination means a single exposed read path can reveal credentials that were never meant to have platform-wide visibility.

Practical implication: search ITSM data for embedded secrets and move any credential-bearing workflow content out of ticket storage.

Why query logging determines breach scope

The difference between a successful query and confirmed exfiltration depends on whether request and response evidence exists. If REST logging is sparse, teams may see signs of access without being able to reconstruct what was returned, copied, or retained. That is not a forensic detail, it is a governance gap. Without verbose logging, security teams cannot prove scope, support notification timing, or distinguish a transient probe from a material disclosure. The article shows that access-control failures become incident-management failures when telemetry is incomplete.

Practical implication: enable REST request and response logging before the next incident, because post-event configuration will not restore missing evidence.

Threat narrative

Attacker objective: The objective is to read ServiceNow instance data that should have been protected by authentication, including operational content and any credentials embedded in tickets.

1. Entry occurred through a REST endpoint configured to allow unauthenticated access, removing the normal identity gate in front of ServiceNow data.
2. Credential access was not required because the attack path bypassed the authentication layer rather than abusing stolen accounts or malware.
3. Impact came from successful queries against instance tables, which could expose operational records and any secrets embedded in tickets.

Breaches seen in the wild

• Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Unauthenticated API access is an identity control failure, not a mere application bug. When a read path does not verify the caller, the entire access hierarchy above it becomes irrelevant. Roles and ACLs still exist, but they no longer protect the resource that matters. For identity programmes, that means unauthenticated endpoints must be treated as governance failures at the boundary where identity should have been enforced.

Ticket systems have become shadow credential stores. The article shows why support workflows routinely hold API keys, passwords, and other secrets that never belonged in the system of record. That makes ITSM data a non-human identity exposure layer, not just operational metadata. The practitioner conclusion is clear: if the workflow is carrying authenticators, it is already part of the NHI estate whether it was designed that way or not.

Visibility is the control that determines whether a query becomes a reportable incident. If REST access is not logged at the request and response level, teams cannot separate benign reads from meaningful disclosure. This is where incident governance and identity governance meet: without evidence, scoping is guesswork and notification posture weakens. Practitioners should treat telemetry completeness as part of the access model, not an afterthought.

Support platforms need an identity model that matches how people actually use them. Engineers paste values to unblock work, tickets persist for years, and vendor patch cycles do not change that behaviour. A mature programme assumes support systems will accumulate credentials and designs for that reality, rather than pretending they are ordinary workflow tools. The practitioner takeaway is to govern the data plane as tightly as the login plane.

Unosecur-style analysis of this incident reinforces a broader point about SaaS governance. Enterprises often control human access well while leaving the system’s own data plane under-governed. That mismatch creates an identity blind spot in which authentication is technically present but operationally bypassed. The implication is that governance needs to extend into SaaS content, not stop at sign-in policy.

From our research library:

• 68% of organisations do not know how to fully address NHI risks, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Unauthenticated read paths create a governance blind spot that most IAM programmes do not model. Authentication reviews often focus on login, MFA, and role assignment, while the real failure sits one layer lower in the API surface. The practical change is to treat unauthenticated data paths as an access-model defect, not just a code issue.

Support systems need to be governed as part of the NHI estate. When engineers paste credentials into tickets, the workflow platform becomes a long-lived repository of machine access. That means NHI inventory, secret discovery, and retention controls have to reach SaaS content, not stop at cloud vaults.

Ticket-resident secrets are a distinct form of credential sprawl. The attack surface is not only the system that stores the ticket, but the operational habit that leaves the secret there indefinitely. Teams should assume any readable support record may contain an authenticating value and govern it accordingly.

For practitioners

• Inventory unauthenticated API paths Enumerate REST resources across your SaaS estate and flag any endpoint that can return data without a verified caller identity.
• Search ticket data for embedded secrets Scan descriptions, work notes, and attachments for API keys, passwords, tokens, and connection strings, then move those values to governed vault references.
• Enable verbose request and response logging Keep transaction and REST logs at a level that preserves query origin, response size, and session context so query activity can be reconstructed later.
• Review support-platform retention and redaction Set tighter retention for closed tickets and redact secret-bearing fields at intake so pasted credentials do not persist indefinitely.
• Revalidate third-party and scripted REST resources Audit custom integrations for the same unauthenticated access pattern and verify that every externally reachable resource enforces authentication before data retrieval.

Key takeaways

• The incident shows how a single unauthenticated endpoint can bypass an otherwise normal IAM control hierarchy.
• Confirmed queries against instance tables matter because support platforms often contain credentials, operational records, and other sensitive content.
• The limiting control is not only patching the endpoint, but governing ticket data, logging API access, and removing secrets from workflow systems.

Key terms

• Unauthenticated Api Path: A public endpoint that accepts requests without verifying the caller first. In identity security terms, this is not just a missing login check. It is a broken trust boundary that can invalidate downstream roles, ACLs, and session controls because the system never establishes who is asking.
• Ticket-Resident Secrets: Credentials, tokens, or connection details stored inside service desk tickets, notes, or attachments. They are operationally convenient but security-sensitive because they can authenticate elsewhere, persist long after the task is complete, and escape normal vault lifecycle discipline.
• Access Hierarchy: An access hierarchy is the layered set of authentication, role, entitlement, and ACL checks that determines whether a caller may see a resource. When the top layer is removed, the lower controls still exist, but they no longer protect the same trust boundary.
• Query Versus Exfiltration: Query versus exfiltration is the distinction between data being successfully read and data leaving the environment. The difference matters for breach analysis because logging, response size, and session context determine whether teams can prove what happened and meet notification obligations.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• The exact endpoint behaviour and configuration detail behind the unauthenticated read path
• The full incident timeline, including patching, disclosure, and support-case handling
• Step-by-step investigation guidance for exporting and filtering ServiceNow transaction logs
• The broader remediation narrative for moving secrets out of tickets and into governed storage

👉 Unosecur's full post covers the endpoint details, disclosure timeline, and investigation steps for affected instances.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.