ServiceNow Exposure Shows Cloud Access Controls Still Fail

ServiceNow’s June exposure is not just another SaaS incident. According to The Hacker News and TechCrunch, an unauthenticated endpoint let outside parties query data in a subset of hosted instances until June 5. For cloud security teams, the lesson is blunt: vendor-managed does not mean access boundaries are sound.

Key takeaways

• ServiceNow says it applied a security update to hosted customer instances on June 5, 2026, and changed an endpoint configuration so access is limited to authenticated users, according to The Hacker News.
• The activity reportedly started on June 2, while customers submitted bug bounty findings on June 3 and June 4 that matched a confidential April 22 submission, according to The Hacker News.
• ServiceNow told TechCrunch the observed activity came from security researchers and customer research teams rather than bad actors, but that does not reduce the operational exposure for defenders who must still verify what data was reachable and what secrets lived there, per TechCrunch.

What happened

ServiceNow warned customers about a security issue that could allow an unauthenticated user, in some circumstances, to gain more access to ServiceNow instances than intended, and it says the June 5 update changed endpoint configuration to enforce authenticated access, according to The Hacker News. That is the core fact that matters: the exposure sat on the boundary between public web access and trusted tenant data.

The reported timeline is worse than the wording suggests. The Hacker News says the anomalous activity started on June 2, while customers sent bug bounty submissions on June 3 and June 4 describing the same class of issue, and that those submissions matched a confidential report sent to ServiceNow’s own bug bounty program on April 22. That gap is the part operators should remember.

ServiceNow also acknowledged that a subset of customer instances were queried successfully as part of the activity, according to The Hacker News. TechCrunch went further, reporting that the bug allowed potentially anyone on the internet to access data stored in customer instances without credentials, based on the company’s knowledge base notice and follow-up statements from ServiceNow, per TechCrunch.

Why this matters

Security teams often rate SaaS platform risk by identity controls, not by internet-exposed application behavior. That model breaks the moment a public endpoint can return tenant data before authentication. TechCrunch notes that ServiceNow environments can hold customer support tickets, credentials, keys, and other sensitive records, which means the blast radius is not abstract cloud metadata but operational data that can enable lateral movement, fraud, or follow-on phishing, according to TechCrunch.

This is why cloud teams should treat the incident as a control-boundary failure, not a PR problem. A platform can remain fully patched on the customer side and still leak high-value data if the service provider exposes it through a broken access path. If your environment still allows secrets to drift into tickets or workflow comments, the risk looks uncomfortably similar to the patterns behind stolen credentials driving a large share of breaches and the long dwell-time identity abuse we covered in Velvet Ant’s auth-stack hijacking campaign.

Exposure mechanics

ServiceNow has not publicly assigned a CVE to the issue, according to The Hacker News. That matters because many enterprise programs key their triage workflows off CVE IDs, severity fields, and vendor advisories that map neatly into scanners. Here, defenders were dealing with a vendor-side exposure that did not fit normal patch-management plumbing.

The public reporting points to a basic but dangerous failure mode: the endpoint configuration needed to be changed so only authenticated users could reach the data, according to The Hacker News. In other words, the problem appears much closer to broken access control than to a memory-corruption bug. That is exactly the kind of issue defenders miss when they trust WAFs, SSO banners, and vendor branding more than explicit authorization checks.

There is also noise around scope. TechCrunch says ServiceNow linked the issue to instances on its Australia release, while Reddit users and community members claimed they saw signs of broader exposure, per TechCrunch and ServiceNow Community. The right operational stance is to treat public forum claims as leads, not evidence, and validate scope from your own logs, instance versioning, and vendor notifications.

What to check

Start with a narrow question: what could an unauthenticated user have read before June 5? Then work outward. TechCrunch reports defenders shared the IP address 51.159.98.241 as a possible indicator of data access, but that indicator came from community investigation rather than a formal vendor IOC pack, so treat it as low-confidence hunting material rather than proof of compromise, according to TechCrunch.

1. Pull web, node, and application access logs covering at least June 2 through June 5, because The Hacker News says the anomalous activity began on June 2.
2. Inventory records that could have high downstream value, especially tickets, workflow notes, knowledge base articles, and integration tables that may contain credentials or API material, based on the data types TechCrunch says commonly live in ServiceNow environments, per TechCrunch.
3. Validate whether your instances were on the affected Australia release path cited by ServiceNow, while still checking other versions because public reporting and community posts suggest defenders did not fully trust the initial boundary, according to TechCrunch and ServiceNow Community.
4. Review outbound credential rotations and integration tokens if sensitive data was stored in reachable tables, because data exposure quickly becomes an identity problem once API keys, passwords, or admin contact details are harvested; our earlier LiteLLM analysis shows how exposed service keys become the real prize for attackers in cloud environments at this related case.

Immediate actions

The bigger operational mistake would be closing the case because ServiceNow now believes the observed activity came from researchers rather than criminal actors, according to TechCrunch. Exposure is still exposure. If researchers could query the data, another party could have done the same before the fix.

The real lesson

The confusion itself is a warning sign. TechCrunch says ServiceNow now believes the observed activity came from security researchers and customer research teams rather than bad actors, which means defenders were left separating benign research from real data access after the fact, according to TechCrunch. That is not just a monitoring problem. It is a design problem in how security teams classify vendor-managed systems.

The hard position is this: if a SaaS platform holds security-sensitive workflow data, you need the same rigor you would apply to an internet-facing internal app. Keep secrets out of records where possible, force short log-retention exceptions during vendor incidents, and require a concrete evidence trail before declaring “no compromise.” ServiceNow’s June incident is a reminder that broken access boundaries in cloud software are still among the fastest ways to turn routine workflow tooling into a breach path.

References

• The Hacker News: ServiceNow Flaw Exploited to Gain Unauthorized Access to Customer Instances
• TechCrunch: ServiceNow tells customers a bug left some of their data exposed to the internet
• ServiceNow Community discussion on suspicious activity