ServiceNow moved quickly last week to patch a configuration error in its platform. The flaw let outsiders pull information from customer instances without passwords or other checks. Some organizations received direct alerts from the company. Others learned of the problem through industry chatter.
The software provider disclosed the matter in a restricted knowledge base note. It described how a security update on June 5 altered an endpoint to demand proper login. Before that fix, unauthenticated visitors could reach deeper into hosted data than planned. ServiceNow detected odd behavior tied to the weakness. For a limited group of clients, logs showed successful table queries.
The Technical Misstep and Its Reach
At its core, the problem stemmed from a Scripted REST Resource. The path /api/now/related_list_edit/create shipped with a flag set to requires_authentication = false. That single setting opened the door. It affected those running the Australia platform release or anyone who applied specific tweaks on earlier versions. Not every customer instance sat in scope. But those that did faced real risk.
Enterprise customers store a lot inside ServiceNow. Incident tickets. Employee profiles. Workflow histories. Asset lists. Security reports. Configuration maps for internal systems. A successful query could expose any of it. The company has not detailed exactly which records moved. Yet the potential spans sensitive operational and personal details.
ServiceNow told affected parties through individual cases. If no case arrived, the firm saw no evidence of queries against that instance. No further steps required right now. The advisory carries a FAQ section. It confirms the firm weighs whether to assign a CVE. Updates will follow if more customer work becomes necessary. One Reddit thread shared the full text after the login wall blocked outsiders. Discussions there quickly turned technical.
Community members spotted an IP address, 51.159.98.241, linked to probes. They advised checking transaction logs for hits on the related_list_edit path. Five attempts seemed common among impacted tenants. Alerts built around the Guest user might have missed the traffic entirely. Without REST message logging turned on, teams lack payload visibility. The gap leaves security leaders guessing at full exposure.
But here’s the sharper point. ServiceNow had an internal problem report open since April 7. A customer security team claims it surfaced the issue first and pushed for action. Screenshots circulated in forum posts. The timeline shows weeks passed before the patch rolled out over a weekend. That delay raises questions inside regulated industries where documentation of response speed matters.
Recent coverage adds color. BleepingComputer reported that attackers exploited the flaw to query tables directly. The piece notes instances often hold IT support tickets, HR records, and workflow data. It stresses the unauthenticated API endpoint as the entry vector.
Customer Trust Meets Platform Complexity
ServiceNow built its reputation on streamlining enterprise operations. Large firms depend on it for everything from help desk flows to compliance tracking. A single endpoint misconfiguration ripples across that trust. One bug can surface records meant to stay locked inside corporate perimeters.
Analysts watching the space point to patterns. Earlier research uncovered similar data leaks tied to Access Control List setups. Public widgets and list views sometimes granted read access without roles. This latest event echoes those findings even if the root cause sits in a different layer. Configuration drift inside complex SaaS platforms creates openings. Operators must audit their own instances now.
Forum contributors urged peers to review every Scripted REST API where authentication remains unchecked. Especially those untouched since before 2022. The advice lands as practical. ServiceNow itself says most customers face no immediate follow-up. Still, the incident serves as a reminder. Hosted platforms concentrate data. They also concentrate risk.
The company described the activity as anomalous rather than a broad breach. Some social media posts suggested security researchers hunting bug bounties instead of criminals. ServiceNow declined to characterize it as a hack when asked by reporters. That distinction matters for legal and reputational reasons. It does not erase the fact that queries succeeded against a subset of instances.
Enterprise technology buyers demand transparency after events like this. They also expect faster triage from vendors who manage critical workflows. ServiceNow’s advisory stays brief by design. It avoids speculation on data types or volume. Future updates could fill those blanks. Customers who received cases hold the most urgent need to investigate logs and consider notifications under privacy rules.
And the broader market takes notice. ServiceNow shares often react to security headlines. This one arrives amid steady growth in the platform’s adoption. Boards ask harder questions when vendor incidents touch their own data. CISOs now add this IP and endpoint to hunting lists. They review instance hardening guides with fresh eyes.
One detail stands out from the advisory language. The update “changes an endpoint configuration to limit access to authenticated users.” Simple wording. Heavy consequences. It underscores how often cloud vulnerabilities trace back to overlooked settings rather than novel code flaws. Teams that treat configuration as code gain an edge here. Manual tweaks at scale invite exactly this sort of exposure.
Industry reporting captured the sequence well. TechCrunch first broke the customer notification story on June 10. It highlighted the hidden knowledge base article and its Reddit spread. The Hacker News emphasized threat actor exploitation and evidence of successful queries. Cybernews noted user claims that the company sat on the vulnerability for weeks before acting.
Those accounts align on facts while offering different angles. None speculate beyond available evidence. The absence of a published CVE leaves security teams without a standard identifier for now. ServiceNow says it evaluates the decision per internal policy. That process can take time. In the interim, defenders rely on the KB number and the June 5 patch date.
Organizations running ServiceNow should act regardless of whether they received a case. Pull logs. Search for the flagged IP and path. Enable stricter auditing if not already active. Test authentication requirements on custom REST resources. The incident may prove contained. The lessons extend further. Platform providers and their customers share responsibility for configuration hygiene. One unchecked flag should not expose enterprise data to the open internet. Yet it did.
ServiceNow promises updates if more action becomes necessary. Customers who subscribe to the knowledge base will see them first. For everyone else, the event adds to a growing list of SaaS configuration incidents. Each one chips at assumptions about vendor-managed security. Each one prompts tighter controls. The data inside these systems matters too much to treat any endpoint lightly.
WebProNews is an iEntry Publication