ServiceNow KB3067321 shows how unauthenticated APIs bypass IAM

At a glance

What this is: ServiceNow KB3067321 is a platform flaw that let unauthenticated API calls reach data behind normal access controls, exposing a broader identity governance problem in ticketing systems.

Why it matters: It matters because ITSM platforms often accumulate credentials, integrations, and sensitive operational data, so one exposed API path can collapse both NHI governance and incident response assumptions.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

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

Context

ServiceNow's June 2026 KB3067321 issue is best understood as an unauthenticated API problem, not simply a software defect. When an endpoint does not verify the caller, the access model above it becomes irrelevant, which is why this incident belongs in the identity security conversation.

For teams running ITSM platforms, the deeper issue is governance drift. Service desks, ticketing workflows, and related-list APIs often hold secrets, tokens, and operational data that behave like credentials even when the platform is not managed as a vault.

The article's central warning is straightforward: if your enterprise treats a system of record as a workflow tool, you may already have an identity store you are not governing. That assumption is common, and it is exactly why this kind of flaw becomes so disruptive.

Key questions

Q: What breaks when an API endpoint does not require authentication?

A: When an API endpoint does not require authentication, every control that depends on knowing the caller becomes unreliable. Roles, ACLs, and session policies only work after identity is established, so an open endpoint bypasses the access hierarchy rather than merely weakening it. In practice, the flaw turns a platform into a publicly reachable data path.

Q: Why are service desks and tickets risky for NHI governance?

A: Service desks are risky because they often store secrets that still authenticate elsewhere, including API keys, passwords, tokens, and connection strings. Those items can outlive the original task, remain searchable in work notes or attachments, and escape normal vault lifecycle controls. That makes ticket data part of the NHI attack surface.

Q: How do security teams know whether a SaaS access event was read or exfiltration?

A: Teams need durable transaction logs, REST request metadata, and response-size visibility to tell the difference between a successful query and confirmed exfiltration. Without those records, you can infer that data was accessed, but you cannot reliably prove how much left the environment. That uncertainty directly affects notification and response decisions.

Q: Who is accountable when a vendor delays disclosure of a platform flaw?

A: Accountability is shared, but the enterprise still owns its notification posture once it becomes aware of potential exposure. Vendor delay does not pause regulatory obligations, and controller duties can begin before a full root cause is published. That is why internal detection and evidence preservation matter even when a supplier is still investigating.

Technical breakdown

Unauthenticated REST paths and access control bypass

The reported /api/now/related_list_edit/create issue was dangerous because requires_authentication=false removed the need to prove identity before the request reached the resource. That bypass does not merely skip login. It nullifies the role, ACL, and session logic layered on top of authentication, because those controls only work once the caller is known. In practice, an unauthenticated read or create path is an identity posture failure, not an authorization nuance. The security boundary is the authentication gate itself, and when that gate is open, downstream governance is moot.

Practical implication: audit every exposed REST resource for authentication requirements, not just role mappings.

Ticket data as an ungoverned credential store

ServiceNow and similar ITSM systems often contain pasted API keys, service account passwords, connection strings, and tokens inside descriptions, work notes, and attachments. Those items are secrets even when they are stored in a ticket, because they can authenticate elsewhere and often outlive the operational task that created them. The core problem is structural: tickets inherit workflow governance, while the contents inside them behave like NHI artifacts. Once the platform is reachable, every past credential in that data plane becomes part of the attack surface.

Practical implication: treat ITSM exports, work notes, and attachments as secrets-bearing data sources in your inventory and rotation processes.

Query visibility versus exfiltration visibility

ServiceNow's statement that it detected anomalous activity and evidence of successful queries matters because a query is not the same as confirmed exfiltration. To make that distinction, defenders need transaction logs, response-size visibility, and request metadata before the incident window closes. Without that telemetry, teams cannot reliably tell whether data was read, copied, or removed, and notification decisions become uncertain. This is why SaaS identity incidents are also logging and evidence-preservation incidents. The technical weak point is not only the endpoint but the absence of durable access evidence.

Practical implication: enable verbose REST logging and preserve transaction records before the next vendor bulletin arrives.

Threat narrative

Attacker objective: The attacker aimed to read operational data from ServiceNow instances without needing valid credentials or an authenticated session.

1. Entry occurred through an unauthenticated REST endpoint that accepted calls without verifying the requester.
2. Escalation was unnecessary because the access control boundary had already been removed, allowing low-friction queries against instance tables.
3. Impact followed through exposure of sensitive ticket and instance data, with affected customers receiving evidence of successful queries.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Unauthenticated access is not a narrow defect, it is a governance collapse. The moment a platform endpoint accepts requests without verifying identity, every control built on top of authentication becomes conditional rather than real. In identity terms, the system no longer has a caller to govern, which means role design, access reviews, and ACL tuning all rest on a false premise. Practitioners should read this as a structural failure in access architecture, not a one-off misconfiguration.

Service desks have become de facto credential stores, and most programmes still do not govern them that way. Tickets, work notes, and attachments routinely capture API keys, passwords, and connection details because that is where operational work gets completed. The failure mode is not that someone copied a secret into a ticket once. The failure mode is that the platform lets sensitive material accumulate indefinitely outside the lifecycle, rotation, and revocation discipline applied to real secrets. The implication is that systems of record now need the same governance scrutiny as vault-adjacent NHI repositories.

Queries, not confirmed exfiltration, are often the decisive evidence gap in SaaS incidents. Once a vendor can only confirm that data was queried, the enterprise is left to reconstruct exposure from logs that may not exist or may be too thin to prove what happened. That makes logging posture part of identity governance, because identity evidence is what determines whether access was merely attempted or actually used. Practitioners should treat logging coverage as a control that defines the limit of post-incident certainty.

Unauthenticated API exposure creates identity blast radius beyond the endpoint itself. In this pattern, the blast radius is not just the direct resource behind the REST call. It extends into every ticket, attachment, integration fragment, and credential stored in the surrounding workflow. That is why platform security reviews must look at the identity-bearing data plane, not only the platform's access model. The practical conclusion is simple: the more a workflow platform stores, the more its authentication posture matters.

ServiceNow-style incidents validate a named concept we call platform credential residue. That residue is the collection of secrets, tokens, and access material that accumulates inside operational workflows after the original business need has passed. It survives because workflow governance is not lifecycle governance. The implication for practitioners is that the security boundary now includes wherever credentials are pasted, not just where they are minted or stored intentionally.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader NHI control baseline, see Ultimate Guide to NHIs , Key Challenges and Risks for how visibility gaps, sprawl, and over-privilege compound exposure.

What this signals

Platform credential residue: the industry now has to treat tickets, attachments, and support workflows as long-lived identity assets rather than transient operational notes. That shift matters because the exposed material is often not the ticket itself but the secret embedded inside it, and secrets are only as governed as the least disciplined place they are copied. The next control boundary is the workflow data plane, not just the vault.

With 27 days as the average time to remediate a leaked secret, per The State of Secrets in AppSec, every day that ticket-resident credentials remain searchable increases the chance that a platform flaw turns into an enterprise breach. For IAM and IGA teams, that means response speed must include discovery inside ITSM systems, not only in source code and cloud repos.

The forward signal is that SaaS platforms are becoming identity-bearing systems of record, which pushes REST logging, secret discovery, and access evidence into the core of programme design. Teams that already align to OWASP Non-Human Identity Top 10 should extend that discipline into workflow tooling, because the failure mode is now as much about stored credentials as it is about runtime access.

For practitioners

• Inventory credential-bearing workflow data Scan ITSM descriptions, work notes, and attachments for API keys, passwords, tokens, and connection strings, then classify those items as secrets rather than ordinary attachments.
• Audit authentication on every REST resource Enumerate custom and platform API endpoints, verify authentication requirements, and flag any unauthenticated read or create path as a governance defect.
• Preserve logs before patch windows close Export transaction and REST logs for the incident window, including request metadata and response sizes, so query activity can be distinguished from confirmed exfiltration.
• Rotate exposed secrets in dependency order Prioritise service accounts, administrative tokens, and integration credentials found in tickets, then redeploy dependent services after rotation so old values do not remain valid.

Key takeaways

• A single unauthenticated API path can collapse an entire access model when the platform is treated as trusted by default.
• The exposure surface is amplified by ticket-resident secrets, which behave like NHIs even when they sit inside workflow tooling.
• The control that changes outcomes is evidence-rich logging plus rapid secret discovery inside ITSM systems, not only faster patching.

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.
• Identity Evidence: Logs and telemetry that prove whether an identity acted, what it accessed, and how far the activity went. For SaaS and ITSM incidents, identity evidence is what separates a successful query from confirmed exfiltration and determines how confidently teams can respond.
• Platform Credential Residue: The leftover secrets and access material that accumulate in workflow platforms after the original business need has passed. It matters because the residue often survives longer than the human or machine account that created it, turning routine operations into a long-lived exposure surface.

What's in the full article

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

• Exact affected endpoint path and configuration change details behind the unauthenticated access issue
• Investigative steps for service desks, including the specific log filters and IP indicators used by administrators
• The incident timeline from disclosure to patching, including the customer-support bulletin timing
• Unosecur's product-specific response workflow for inventorying and rotating exposed non-human identities

👉 The full Unosecur post covers the attack path, log checks, and secret rotation priorities in more detail

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy, lifecycle control, or non-human identity governance, it is worth exploring.