ServiceNow has become a backbone of enterprise IT, helping organizations manage everything from HR workflows to IT service delivery. Its cloud-based platform touches nearly every department in large organizations, making it a central hub for sensitive business data.
That centrality is exactly what makes the newly disclosed “Count(er) Strike” vulnerability so concerning. Discovered by Varonis Threat Labs and tracked as CVE-2025-3648, the flaw allows low-privileged—and in some cases, even unauthenticated—users to extract data from backend tables they should never be able to access. The root of the problem lies in how ServiceNow handles Access Control Lists (ACLs), and how overlapping permissions can quietly expose more than intended.
Anatomy of Count(er) Strike
The flaw stems from the way ServiceNow enforces its ACLs. If just one ACL rule is too permissive, users with minimal or even anonymous access can run table queries that return sensitive data.
This isn’t a privilege escalation vulnerability—attackers don’t need to gain elevated rights to cause harm—and it requires no malware, no deep system access, and no sophisticated exploitation chain. All it takes is a carefully crafted request to a vulnerable endpoint, and an attacker can start pulling data well outside their intended scope.
“Teams should treat this as a high priority because it’s the kind of flaw that attackers love,” J Stephen Kowski, Field CTO at SlashNext. “It’s simple to exploit and can give them access to sensitive data without raising red flags.”
The Role of Misconfigured ACLs
ServiceNow ACLs are designed to regulate who can access what. They evaluate conditions based on user roles, scripts, and other attributes to determine whether a request should be allowed. In theory, this should prevent unauthorized users from viewing or interacting with sensitive data.
In practice, however, ACLs are often misconfigured. One common issue is overly broad permissions, such as granting read access based on weak or incomplete conditions. Another is the assumption that if a table isn’t meant to be exposed, it won’t be queried, leading teams to skip applying granular controls. ServiceNow’s default behavior of returning partial results from table queries can also compound the problem, leaking bits of data even when full access isn’t granted.
This is where low-privilege accounts become dangerous. A user with basic or self-registered access might appear low risk on paper, but if just one ACL is too loose, they can run queries that pull back sensitive content.
ServiceNow’s Response
ServiceNow released a patch for Count(er) Strike in July 2025. The fix addresses the core vulnerability by tightening how ACLs are evaluated during table queries. In addition, the company introduced new access control frameworks in its Xanadu and Yokohama releases, aimed at giving administrators more precise tools to define and manage data access.
Alongside the technical fixes, ServiceNow issued guidance urging customers to review their ACL configurations and adopt a stricter, least-privilege approach. That includes limiting table access wherever possible, using deny-by-default policies, and regularly auditing ACL logic for unintended exposures.
“The real lesson here is that patching alone isn’t enough; organizations need continuous monitoring that can spot when users are accessing data they shouldn’t, even through legitimate-looking requests,” Kowski said. “Smart security teams are already implementing real-time analysis tools that can detect these subtle data extraction patterns before they become major breaches.”
The Broader Lesson: SaaS Security and the Human Factor
The Count(er) Strike vulnerability is a reminder that organizations still struggle to put least privilege into consistent practice. In fast-moving enterprise environments, it’s common for permissions to be granted broadly just to keep work flowing. Over time, these shortcuts add up, and access controls drift from their intended state.
That’s why continuous auditing and monitoring of ACLs is essential. It’s not enough to set permissions once and forget them. Access logic must be reviewed regularly, especially in platforms like ServiceNow, where a single permissive rule can quietly expose large volumes of data.
Meanwhile, SaaS sprawl continues to expand the attack surface. Most organizations rely on dozens of cloud platforms, each with its own security model and configuration quirks. That makes it easy for gaps to form, and hard for IT teams to keep track of who has access to what. Count(er) Strike may have hit ServiceNow, but the underlying risk applies to the entire SaaS ecosystem.
Steps Organizations Should Take Now
The first step is simple: patch immediately. Any ServiceNow instance not yet updated with the July 2025 fix is still vulnerable. Next, security teams should review all table-level permissions and restrict access wherever it’s not explicitly needed. That includes tightening ACLs, disabling unused accounts, and testing queries from low-privilege roles to identify blind spots.
Longer term, organizations should move toward a zero-trust model. Regular audits of access logic and role definitions should be part of routine operations. Bringing in third-party security experts to assess your configuration can help spot issues internal teams might miss.
Finally, don’t underestimate the value of education. Administrators need ongoing training to stay current with evolving access control models, especially as SaaS platforms like ServiceNow continue to roll out new frameworks. End users should also be trained to recognize the risks of unnecessary data access, even when it seems convenient.
A Wake-Up Call for SaaS Security
The Count(er) Strike vulnerability reveals a major blind spot in SaaS security. When access controls are layered but loosely defined, even minimal permissions can be enough to expose sensitive data. And because these flaws don’t require brute force or deep system compromise, they’re easy to miss and easy to exploit.
As enterprise platforms like ServiceNow grow more powerful and complex, the potential for misconfiguration grows with them. Patching vulnerabilities is important, but it’s not a substitute for vigilance. Organizations need to treat access control as a living system that requires constant attention, regular testing, and a mindset that assumes nothing is locked down unless you’ve checked.
