As a versatile cloud-based platform, ServiceNow handles a vast amount of sensitive customer data, from personal details like addresses and phone numbers to critical business information such as strategic plans and employee HR records. This, of course, means the company must be extra diligent and proactive when it comes to any potential threats to their system.
In February 2024, cybersecurity company Varonis Threat Labs discovered a serious vulnerability within ServiceNow that could have potentially exposed vast amounts of sensitive data to underprivileged users.
Dubbed as Count(er) Strike, this system flaw enabled low-privileged users to extract sensitive data from tables to which they should not have access. Varonis followed responsible disclosure procedures and quickly informed ServiceNow, who have been working extensively to mitigate the issues and patch the vulnerability.
Let’s take a closer look at the details and what ServiceNow has done to fix it.
How Count(er) Strike Happened
As you may already know, the majority of ServiceNow’s data is stored in structured tables. This means that every ticket, user, record, configuration, or process step is essentially a row in a specific table.
To control who can access its tables and the data within them, ServiceNow uses Access Control Lists (ACLs), which are essentially permission rules. Each ACL evaluates four specific conditions:
- Required roles
- Security attributes
- Data conditions
- Script conditions
Together, they act as a layer of governance to prevent sensitive information from ending up in the wrong hands.
However, Varonis uncovered a major flaw in this system: if a user met just one ACL condition, they could gain access, even if other rules should have blocked them.
This allowed users different levels of access, with some getting full access and others gaining a partial view.
Interestingly, Varonis’ research found that partial access was still sufficient enough to cause serious damage, as hackers could still enumerate the data by observing the number of records and use clever URL tricks to deduce the information inside.
In an example used by Varonis, they showed that if a user fails the data condition or script condition, ServiceNow still returns the record count in the UI and source HTML.
Using the partial data that was exposed, Varonis began experimenting with URL-based filters – like STARTSWITH, CONTAINS, =, and != – to gradually uncover the contents of records, one character or condition at a time.
In a blog post on the Varonis website, security researcher Neta Armon provided some important context regarding the nature of this vulnerability, stating:
“This vulnerability impacted several popular and common ServiceNow solutions and tables and is relatively simple to exploit as it only requires minimal access to the target tables. This makes the vulnerability a major concern for organizations using the platform as sensitive data could be accessed and exploited unknowingly by users who are unaware they have access to it.
“Prior to the patch, this vulnerability could have potentially affected all ServiceNow instances, impacting hundreds of tables. Most concerning, this vulnerability was relatively simple to exploit and required only minimal table access, such as a weak user account within the instance or even a self-registered anonymous user, which could bypass the need for privilege elevation and resulted in sensitive data exposure.”
Speaking to BleepingComputer, Varonis claims that they tested the attack against ServiceNow’s ITSM product, but stated that it should also apply to all ServiceNow products that utilize the same ACL logic.
What Has ServiceNow Done to Fix It?
Despite the severity of the situation, this system flaw was discovered in February 2024, which has given ServiceNow ample time to act accordingly and ensure that they patch the issue.
Having started the patchwork in September 2024, ServiceNow formally published its CVE on July 8, 2025, which officially introduced:
- ‘Deny Unless’ ACLs: All users must pass all ACLs to gain full access to a dataset.
- Query ACLs: Enumeration queries using range operators are now fully restricted.
- New Data Security Fields recommendations: New advice is being explicitly recommended to customers to start using them more seriously to prevent data enumeration attacks, hide sensitive data from low-privileged users, and reduce the chance of inference through record counts.
Varonis has also confirmed that there’s no evidence that this vulnerability has impacted any ServiceNow users, and has been successfully mitigated by ServiceNow before any data breach could have been performed by bad actors.
Final Thoughts
This vulnerability had the potential to cause serious damage for ServiceNow. But by acting thoughtfully and discreetly, the company was able to address the issue effectively, without any major disruption to the platform or its users.
As mentioned, it’s essential to double-check your own ServiceNow permissions to ensure that:
- Access Control Lists (ACLs) aren’t overly permissive.
- Sensitive tables and fields are properly locked down.
- Security Data Filters are in place to prevent data leakage.
- Your instance is updated to the latest version with the relevant patches applied.
Staying proactive with your security configurations is the best way to protect your data, even when the platform itself is doing its part.