Editor’s Note

Hi, this month we talk about a breach that needed no exploit.

One boolean flag. One REST API endpoint. ServiceNow shipped it with authentication turned off, had an internal record of it for at least six weeks, patched it quietly on June 5, and notified customers four days later, behind a login wall.

The community found the indicator of compromise on Reddit before most enterprises received a vendor notification. That gap is the story.

 

Lavanya Chandrasekharan,
Siemba

TLDR

• ServiceNow's June 2026 incident traced to a single API endpoint where requires_authentication was set to false.  No password, no token, just the URL.

• Internal records suggest ServiceNow documented the vulnerability on April 7, 2026, 6 weeks before the patch landed.
  
  
• Patched June 5, disclosed June 9 behind a customer login wall, a four-day gap that breaks GDPR, SEC, and HIPAA notification timelines for regulated organizations.
  
  
• Gartner reports that 99% of cloud security failures stem from misconfiguration, not zero-day attacks. Most security budgets are weighted toward the wrong threat.
  
  
• This is the third critical unauthenticated vulnerability in ServiceNow in eight months, two of them authentication bypasses.
  
  
• The same structural failure hit the software supply chain in June: the Shai-Hulud worm and its copycat variants (such as Miasma) compromised 100+ trusted npm and PyPI packages after its source code was released publicly.

Three Strikes in 2026. All Unauthenticated. All Trusted Channels

June Was a Bad Month to Trust Your Vendor

1. ServiceNow, June 2-3, 2026

Between June 2 and June 3, 2026, data was queried from enterprise ServiceNow instances without a single valid credential.

The root cause: a Scripted REST Resource shipped with requires_authentication set to false.

"The API never asked who you were. It just answered."

That one flag meant any HTTP request to /api/now/related_list_edit/create bypassed the login layer entirely.

The platform logged the activity under a Guest user account, which is part of why it took time to appear in logs.

What was accessible?

Support tickets, employee records, asset inventories, security incident reports, workflow documentation, and credentials and API tokens that engineers routinely paste into ticket comments during troubleshooting.

The access required no privilege escalation.

It was already reading tables that fully authenticated users could see.

Key Takeaway: The risk is not what you configured at deployment. It is what the platform looks like after last Tuesday's vendor release. Verify continuously, not quarterly.

How it worked: one flag, no login, full table access

ServiceNow patched on June 5, disclosed on June 9 - the advisory gated behind a customer login wall.

Community researchers on Reddit identified the vulnerable endpoint around the same time internal records suggest the company had already documented the flaw since April 7 and classified it as non-urgent, scheduling remediation for a later release.

A customer who reproduced the exposure live on a screen share accelerated the timeline.

Organizations subject to GDPR's 72-hour notification window or SEC cybersecurity disclosure requirements cannot start the regulatory clock from a gated advisory.

A silent patch is not vendor notification.

ServiceNow later attributed the queries to security researchers conducting bug bounty research, not malicious actors.

That distinction does not change the exposure. The data was accessible to anyone with the URL.

The researchers just happened to find it first.

From first report to customer notification: eight weeks and a four-day silent window

2. The pattern before it - October 2025 and January 2026

This was not ServiceNow having a bad month.

In October 2025, the platform patched CVE-2025-12420 - a flaw that allowed an unauthenticated attacker to impersonate any user using only an email address, bypassing MFA and SSO entirely.

Aaron Costello, Chief of Security Research at AppOmni, described it at the time as the most severe AI-driven security vulnerability uncovered to date.

In January 2026, CVE-2026-0542 - a critical sandbox bypass enabling remote code execution without authentication, was patched before confirmed exploitation.

Three critical unauthenticated flaws in eight months. In a platform where your engineers store IT runbooks, incident response procedures, internal API tokens, and credentials shared during troubleshooting calls.

Key Takeaway: Three critical unauthenticated flaws in eight months on the same platform is not bad luck.

It is a signal that your continuous verification posture needs to cover the SaaS layer, not just the applications your team built.

3. The Shai-Hulud supply chain escalation (June 2026)

The same trust failure runs through the development layer. In June 2026, the Shai-Hulud supply chain worm entered a new escalation phase after its original authors released the source code publicly. Copycat variants (such as Miasma) compromised 100+ packages across npm and PyPI, including Red Hat Cloud Services npm packages.

Developers pulled dependencies from the same registries they have always trusted.

The packages were signed, published, and present. The compromise was in the build chain, not the binary.

Key Takeaway: The attack surface has shifted into trusted channels: SaaS platforms and the software supply chain. Two incidents in the same month in different layers made that impossible to ignore.

Your Security Budget Is Aimed at the Wrong Target

Gartner reports that 99% of cloud security failures stem from misconfiguration, not zero-day exploitation. The ServiceNow incident is a precise illustration: the vulnerability was a configuration state, not a novel exploit.

The implication is uncomfortable. Most security budgets are weighted toward detection and response, toward catching the attacker after entry.

But when 99% of failures are configuration failures, the highest-leverage investment is continuous verification of configuration state, before the attacker arrives.

41% of SaaS breaches trace back to permission drift and 29% to misconfiguration, issues that consistently slip between periodic reviews. 52% of organizations still rely on point-in-time audits rather than continuous monitoring.

By the time the quarterly review runs, the configuration has already changed.

The confidence gap is the real problem. 91% of security teams report confidence in their SaaS security posture.

75% of those same teams suffered a SaaS-related security incident in the past twelve months. Confidence and coverage are not the same thing.

For most teams, confidence comes from having deployed the platform correctly once.

Coverage would require verifying it is still configured correctly after every vendor update.

A spearate figure: Broken authentication accounts for 29% of API security incidents industry-wide.

Over 70% of organizations report they cannot fully track sensitive data across their API integrations.

The average enterprise now manages hundreds of SaaS applications.

Most security teams have near-zero continuous visibility into authentication configuration across that estate.

The Security Model You Inherited Wasn't Built for This

The ServiceNow incident is not a story about an unusually careless vendor.

It is a story about a structural gap between how enterprise security programmes were designed and where the actual risk now lives.

Security teams inherited a model built for perimeter defense. You protect the edge. You monitor the endpoints. You run penetration tests against your own applications.

What almost no programme does continuously is verify whether the SaaS platforms handling your most sensitive operational data are still configured correctly, including after every vendor release.

The Reddit thread that surfaced the ServiceNow IOC before most enterprise customers received vendor notifications illustrates the gap precisely.

The community identified the vulnerable endpoint, shared the IP address, and posted detection guidance faster than the vendor's formal advisory reached customers.

That is not unique to ServiceNow.

It is what happens when the security model assumes vendors will catch their own configuration errors before exploitation occurs.

"If the vulnerable endpoint shipped in a vendor platform update, how would our quarterly configuration review have caught it?" - CISO, financial services firm, 2,000-person engineering organization

The honest answer is, it would not have.

The authentication flag changed inside a Scripted REST Resource, a layer of the platform that standard enterprise assurance processes do not inspect between releases.

The activity logged as Guest user traffic, a pattern that does not trigger breach detection without knowing exactly what to look for.

This is the structural gap. The attack surface has moved into the SaaS layer and the software supply chain.

Most security programmes have not moved with it.

Stop Auditing. Start Testing Continuously.

1. Test your SaaS API surface continuously, not periodically

The ServiceNow vulnerability was not introduced by your team, it shipped in a vendor update.

Your assurance process needs to continuously validate authentication state across your SaaS platforms, running API-level tests against your integrations the same way GenPT tests APIs you build in-house.

For ServiceNow specifically: review transaction logs for Guest user activity and requests to /api/now/related_list_edit/create going back at least 90 days. IOC IP: 51.159.98.241.

Rotate any credentials or API tokens stored in support tickets or knowledge base articles, even if your instance was not confirmed affected. Data accessed in June can fuel follow-on attacks months later.

2. Build a notification process that does not depend on vendor email

GDPR, SEC cybersecurity disclosure rules, and HIPAA Business Associate Agreement obligations require organisations to start the regulatory clock at awareness - not at vendor notification.

A support portal advisory behind a login is not reliable awareness.

The ServiceNow IOC circulated on Reddit before most enterprises received a vendor notification.

If your security operations center waits for a vendor email before beginning log review, you are likely already behind on regulatory timelines in a real breach.

Build proactive IOC triage against community-surfaced indicators into your incident response process.

3. Gate your CI/CD pipeline against security findings before production

The Shai-Hulud escalation in June shows the build chain is now an active attack surface. Packages from trusted registries are being compromised.

If your current pipeline has no severity-threshold gate that blocks a build when a critical finding is detected, findings surface in incident reports instead of being stopped at the commit.

The fix is a gate, not a faster response after the fact.

The workflow that stops vulnerable builds before they reach production.