ServiceNow's Unauthenticated API Endpoint Left Tenant Data Exposed for Months
An API resource shipped with authentication disabled by default. Now enterprises are asking whether the 'security researcher' explanation fully covers what got accessed.

ServiceNow has patched a vulnerability in which an internet-facing API endpoint could be queried without any authentication — no token, no session, no SAML assertion required. Just the URL and a correctly structured request.
The affected endpoint, reportedly /api/now/related_edit_list/create, shipped with requires_authentication = false. That's not a subtle misconfiguration buried in a YAML file. That's a flag.
ServiceNow's bug bounty program surfaced the flaw in April. Hosted customers received security update KB3067321 on June 5; self-hosted operators got remediation guidance under KB3067372. The company initially attributed suspicious activity logged against affected tenants entirely to security researchers validating their findings.
That attribution is where things get complicated.
Cory Michal, CISO at AppOmni, noted that at least one system publicly linked to exploitation of this vulnerability had also targeted other SaaS platforms with similar unauthenticated-access weaknesses. That's not a researcher fingerprint. Researchers don't typically pivot across platforms. "I would be cautious about saying all observed activity was benign research until the investigation is complete," Michal said.
ServiceNow's own advisory hedges accordingly: "Our investigation is ongoing, however, and subject to additional validation."
The company initially framed the exposure as limited to its Australia release. Customers weren't convinced. The requires_authentication setting is a configuration flag, not a release-specific code path — meaning any instance where that checkbox was cleared, regardless of release, could plausibly have been exposed. Self-auditing your Scripted REST API table for resources with that flag unset, especially anything untouched since before 2022, is the practical takeaway there.
ServiceNow stores IT service requests, HR records, and internal security tooling data. Unauthenticated read access to those tables is a serious incident-response trigger, not a routine patch event.
Michal's recommended response scope is worth quoting directly: review access and transaction logs for unauthenticated requests to the affected endpoint and unusual table or field queries, covering at least the last 90 days. If something surfaces, treat it as a full incident investigation.
Would MFA have helped here? No. The issue was pre-authentication entirely — the endpoint bypassed the auth layer before any credential or second factor could be evaluated. This is an authz problem baked into an API definition, and MFA doesn't reach that layer.
ServiceNow says a subset of customer instances were queried successfully and that it has opened dedicated support cases for those customers. Patch first. Then look at what touched your logs.



