Varonis Threat Labs discovered a high-severity vulnerability in ServiceNow’s platform that could lead to significant data exposure and exfiltration, including PII, credentials, and other sensitive information.
ServiceNow is a widely used platform with 85% of its customer base being in the Fortune 500.
Our researchers were able to exploit the record count UI element on list pages, using enumeration techniques and query filters to infer and expose sensitive data from various tables within ServiceNow.
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.
Varonis researchers initially discovered and informed ServiceNow of this vulnerability, which we’ve named Count(er) Strike, in February 2024. ServiceNow issued a security update in May 2025. They issued a CVE on July 8, 2025 (CVE-2025-3648).
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.
Varonis and ServiceNow recommend that ServiceNow customers review their custom and standard tables and apply the new security mechanisms created by ServiceNow to address the vulnerability, such as Query ACLs and Security Data Filters, which we briefly cover in the ServiceNow Response section.
We aren’t aware of cases where this vulnerability was exploited before ServiceNow issued the patch.
This example demonstrates how, with limited permissions, we could extract credentials to production servers.
This example demonstrates how, with limited permissions, we could extract credentials to production servers.
Continue reading to learn more about ServiceNow’s platform and how the Count(er) Strike vulnerability was discovered by our team.
What is ServiceNow?
ServiceNow is a versatile cloud-based platform that offers a wide range of SaaS solutions to optimize and automate business processes, offering a unified system of records for diverse functions.
While ServiceNow is well-known for its IT service management (ITSM), which IT teams use to streamline the handling of incidents, requests, and changes, the platform offers a wide variety of functions that routinely handle sensitive information, including IT Operations Management (ITOM), Customer Service Management (CSM), Human Resources Service Delivery (HRSD), Governance, Risk, and Compliance (GRC), Healthcare and Life Sciences Service Management (HLSSM), and more.
The numerous business functions supported by ServiceNow require each solution to store and process a variety of sensitive data. This includes PII such as addresses, phone numbers, social security numbers, and PHI like medical records and insurance details.
ServiceNow's customer service management solutions regularly store financial data like bank accounts and credit card information, along with credentials and access data, while its IT solutions include usernames, passwords, security/incident data, and API keys.
Additionally, ServiceNow can contain confidential business information, such as proprietary data, strategic plans, and intellectual property, and can handle HR data, including employment history, performance reviews, and payroll information.
How does ServiceNow organize data?
ServiceNow organizes virtually all information into tables, including elements like incidents and requests, instance properties and configurations, user data, application credentials, and much more. Each of these items is stored as a record within its respective table.
ServiceNow creates connections between tables using reference fields, which allow records to be shared across different tables. For example, a reference field in the Incidents table might link to a specific user record in the Users table, allowing that related data to be viewed across multiple tables.
ServiceNow provides access to data through records and fields within tables.
ServiceNow provides access to data through records and fields within tables.
How is access controlled in ServiceNow?
Access to ServiceNow tables is managed mainly through Access Control List (ACL) rules. These rules determine what data users can access and how they can interact with it.
A ServiceNow instance can contain tens of thousands of ACL rules, each specifying the conditions under which a user can access a particular piece of data. For example, an ACL rule might be set to allow only users in a specific role, such as an HR leader, to read a table containing employee compensation.
The key components of an ACL rule in ServiceNow are the resources you want to protect (such as a table, field, or record), the operation, which specifies the type of access being controlled (like read, write, create, or delete), and the conditions that must be met for the rule to apply.
Four conditions in each ACL determine whether a user meets the requirements to access a specific resource:
- Required roles: This condition specifies the roles required to access a particular resource. If a user has one of the roles listed in the ACL, they are granted access.
- Security attribute condition: This condition uses security attributes to determine access. Security attributes are built-in properties or tags that can be used to enforce security policies. For example, a security attribute might specify that only users from a certain department can access specific data.
- Data condition: This condition evaluates specific criteria related to the data itself. For instance, you might set a condition that limits access to only records with a certain status or within a specific date range.
- Script condition: This condition allows for the execution of custom logic. You can write scripts to implement complex security rules beyond simple role or data conditions. These scripts can check various factors and make dynamic decisions about access. For example, a script can be written to grant access only when a certain configuration in the instance is set or only when a user is authenticated.
The four ACL conditions are evaluated in a specific order: starting with roles, followed by security attributes, data condition, and finally, script condition. All four conditions must be satisfied to gain access. If a condition is left empty, it will be treated as if there is no restriction, but all the other conditions should be met for access to be granted.
Each resource or table in ServiceNow can have numerous ACLs, each defining different conditions for access. However, if a user passes just one ACL, they gain access to the resource, even if other ACLs might not grant access. If there is no ACL present for the resource, access will default to the default access property which is set to deny in most cases.
The ACL evaluation process: Access is granted if all conditions are met. At least one condition shouldn’t be empty.
The ACL evaluation process: Access is granted if all conditions are met. At least one condition shouldn’t be empty.
After our discovery of Count(er) Strike, ServiceNow added additional access control mechanisms, some of them to address this vulnerability. We discuss the relevant ones in the ServiceNow Response section.
These new access control mechanisms are:
- ACL Type: which can be set to “deny unless” which require the user to meet this specific ACL’s condition as well as all others “deny unless” ACLs to gain access to the resource or to be set to “allow if” in which only complying with one ACL is enough to gain access.
- Query ACLs: which define more granular access control by explicitly defining who can query the data. A query ACLs have their operation set to either query_range or query_match. Query ACLs are a defense mechanism against blind query attacks, where an attacker blindly queries the data to extract information from results, even when they can't see the values.
- Security data filters restrict access to records based on role or security attribute-related assertions. They are applied in-query and filter the results to remove results that should not be exposed to the user and suppress the "rows removed by security" message.
Digging into the details
During the research, we found that ServiceNow denies access depending on which ACL conditions are unmet. If access to a resource is blocked due to either of the first two conditions — the "Required Roles" or "Security Attribute Condition” — a blank page displays the message, “Security constraints prevent access to requested page.” This indicates the user lacks the necessary roles or attributes to view the page.
Response page 1: Access to the requested data is restricted; no information is shown.
Response page 1: Access to the requested data is restricted; no information is shown.
However, if access is denied due to failing the "Data Condition" or "Script Condition", the outcome is different.
Instead of a blank page, the user is presented with a page that shows the total count of records that apply, even if no records are visible. The page includes a note stating, “Number of rows removed from this list by Security constraints,” highlighting that while the data exists, it’s inaccessible due to the security rules applied. The difference between the two response pages gives us insight into which ACL access conditions are unmet.
Response page 2: Access to the requested data is restricted; record count and fields are shown.
Response page 2: Access to the requested data is restricted; record count and fields are shown.
Query parameters and filtering
In ServiceNow list pages, query parameters filter and refine the data returned from tables, allowing users to retrieve specific records based on defined criteria. These parameters are appended to the query URL and consist of key-value pairs that specify the conditions for filtering. For example, a query might filter the records in the Incidents table to show only those with a particular priority level or assigned to a specific user.
ServiceNow supports various operators in these queries, such as =, !=, LIKE, STARTSWITH, and ENDSWITH, which can be used to build complex filters. Additionally, multiple query parameters can be combined using logical operators like AND, and OR to create more detailed and precise data retrieval conditions.
Exploiting the vulnerability
- When a threat actor encounters a table page displaying the total number of records, they can use query parameters to infer detailed data through enumeration.No special configurations or plug-ins are needed; just a user account in the ServiceNow instance with partial table or column access. A malicious actor can start by identifying a table in your ServiceNow instance that shows the total record count, even if it does not display the actual records. In our example, we used the table Tasks: {my_company}.service-now.com/task_list.do The bottom of the page will display the total number of records in the table Tasks. In a typical ITSM instance, there are hundreds of tables that, by default, have ACL configurations that enable visibility into the total record count.
- To filter the results, we then built a query that starts by guessing the contents of a specific field of a record. For example: {my_company}.service Now.com/{table_name_case_list.do}?sysparm_query={field1}STARTSWITHa The count, also found in the HTML source as grand_total_rows, will be updated to reflect tasks with short descriptions starting with the letter a. This will help us automate this exploit later.
- More conditions can be added to retrieve more details and specific results. In our research, we used the following query to filter all tasks to show incidents opened by a C-level user that contained the substring “password” in their description.{my_company}.service-now.com/{table_name_case_list.do}?sysparm_query= sys_class_name=incident^opened_by.u_c_level=true^descriptionCONTAINSpasswor d
- Search results can be refined with additional conditions like STARTSWITHab or STARTSWITHac to narrow the results and ultimately reveal specific record data in the table. If the result is 0, then the current filter yields no results; if the result is 1 or higher, then a field matches the query.
- This approach can be applied to all field types and combined with multiple conditions. For example, the query below will return the number of inactive users:
{my_company}.service-now.com/ {table_name_users_list.do}?sysparm_query=active=false To enumerate the IDs of inactive users, we began with a query like this:
{my_company}.service-now.com/ {table_name_users_list.do}?sysparm_query=active=false^sys_idSTARTSWITH1
You can then use queries like these repeatedly to uncover the data digit-by-digit until all IDs of inactive users are exposed.
Automating the vulnerability and access data
Although using query parameters and filtering to expose and exfiltrate data might seem tedious, a threat actor can automate this process by writing a simple script for enumeration, allowing them to retrieve full record data from table. They can then begin to retrieve the results from the HTML source.
The script should receive a base query to narrow down the desired data and a targeted field from which to extract data, which could then be executed to unveil otherwise protected table data.
You can efficiently script the enumeration process to infer the ticket content.
You can efficiently script the enumeration process to infer the ticket content.
Any user in an instance can exploit this vulnerability, even those with minimal privileges and no assigned roles, as long as they have access to at least one misconfigured table. This vulnerability applies to any table in the instance with at least one ACL rule where the first two conditions are either left empty or are overly permissive — a common situation.
Threat actors can identify the many vulnerable tables through guesswork or systematically via tools like Burp Suite. By running these tools on known table names, you can detect page responses that reveal the total count of record results, indicating a potential vulnerability.
You can use a tool like Burp Suite to automate testing for vulnerable tables.
You can use a tool like Burp Suite to automate testing for vulnerable tables.
When this attack is executed on a table, any fields can be accessed (excluding fields explicitly protected by field-level ACLs), allowing the attacker to use a script to retrieve an entire table copy.
Widening the scope with dot-walking and self-registration
ServiceNow has several features that inadvertently increase the blast radius of this vulnerability. The first is dot-walking, which allows a user to access more data by following reference fields.
The second is user self-registration, which allows new users to create accounts and gain access to an instance without needing prior approval from an administrator.
Dot-walking
Dot-walking in ServiceNow lets users access data from related tables via reference fields, allowing the retrieval of linked record information without manually joining tables. For example, this feature can display a user's email in an incident record, streamlining data retrieval across the platform.
Attackers can use dot-walking to access additional data from referenced tables, even when that data is not directly accessible through ACLs. By navigating these relationships, users can pull information from otherwise restricted tables, expanding their access to data across the system.
Self-registration: Attacking from the outside in
ServiceNow's self-registration feature allows new users to create accounts and access an instance without prior administrator approval. This feature, which is not enabled by default, simplifies onboarding for external users, such as retail customers, public services, or students, by allowing them to sign up and automatically receive basic access.
Suppose the automatic self-registration feature is enabled in an instance (which can be easily detected with a script). In that case, anyone can register as a new user and gain credentials for the organization’s instance. Once inside, the attack can be carried out using the newly created self-registered user with basic table access. This allows virtually any anonymous user to extract data from various tables across the organization.
Though it is rare for instances to allow anonymous registration and access, this configuration was found in the ServiceNow systems of several Fortune 500 companies.
ITSM service portals sometimes allow for self-registration in the cases of public services or offerings.
ITSM service portals sometimes allow for self-registration in the cases of public services or offerings.
Self-registration to ServiceNow enables vulnerability exploitation to the public.
Self-registration to ServiceNow enables vulnerability exploitation to the public.
The impact and blast radius
This vulnerability impacts several popular and common ServiceNow solutions and can be exploited by any user in an instance, even those with minimal table privileges and no assigned roles. It can expose sensitive and regulated data, including PII, SSNs, PHI, credentials, and financial information depending on the accessible data.
Tables susceptible to the attack are those with ACLs with empty or overly broad "Requires Roles" and "Security Attribute Condition" sections. This means any table protected only by data or script condition is fully exposed to the attack. Many critical tables are configured this way by default. Any user in the organization instance, whether internal, compromised, or self-registered, can fully access all data in these tables.
When ServiceNow is used as a customer service or support platform, all customer users could potentially access the internal data, including PII, system properties, emails, and financial information, of other customer companies or the organization, which should remain confidential.
Given the features and components of this Count(er) Strike vulnerability, its widespread reach makes many organizations susceptible. The consequences could be severe, potentially exposing large amounts of sensitive data to unauthorized access.
ServiceNow’s Response
Following Varonis Threat Labs’ identification of this data inference vulnerability, we alerted ServiceNow, and they introduced several mechanisms to mitigate data inference attacks.
ServiceNow recommends that customers promptly review the access controls within their instance, including the mechanisms detailed below. This review should include validating ACLs for new or custom tables to ensure that customers’ configurations meet their specific requirements.
Query ACL
Query ACLs are a new type of ACL that is used as a defense mechanism against data inference blind query attacks, where an attacker blindly queries the data to extract information from results, even when they can't see the values.
This mechanism works by adding restrictions on the queries a user can execute on table to retrieve records.
Query ACLs have their operation set to either query_range or query_match. And each can be set to allow or deny.
Query_range is composed of range operators like STARTS_WITH, CONTAINS, >=, <=, etc. which are dangerous as they allow users to query for more records by adjusting the boundary values.
Query_metch is composed of: EQUALS, NOT_EQUALS, IN, NOT_IN, SAMEAS, NSAMEAS, ANYTHING, ISEMPTYSTRING, ISEMPTY, ISNOTEMPTY, ISNULL, ISNOTNULL. query_match is made of the "safe operators", in a sense that they are built to fetch specific record(s) and can't be exploited to return others.
Query_metch is composed of: EQUALS, NOT_EQUALS, IN, NOT_IN, SAMEAS, NSAMEAS, ANYTHING, ISEMPTYSTRING, ISEMPTY, ISNOTEMPTY, ISNULL, ISNOTNULL. query_match is made of the "safe operators", in a sense that they are built to fetch specific record(s) and can't be exploited to return others.
Read more about ServiceNow's query ACL rule here.
Security data filters
Security data filters restrict access to records based on role, or security attributes related to assertions.
Security data filter will apply after table-level ACLs and field-level ACLs and add additional filters to the query the user tries to execute to remove results that should not be exposed to the user.
The way security data filter works is that they add filters that limit the data returning by adding AND condition that is complementing the existing conditions. For example, if we have a query with a WHERE clause has state != close it will add AND state = open to make sure only open will return.
Security data filters disable the "rows removed by security constraints" message which lets the user know if any rows were removed while applying the query filters, which we used to infer the content.
Read more about security data filters here.
Aftermath
Varonis recommends that all ServiceNow customers review their instances and apply the new security mechanisms on sensitive tables: custom and standard. ServiceNow customers should also be aware that query range Query ACLs will soon be set to default deny, so they should create exclusions to maintain authorized user ability to perform such actions. For more information, ServiceNow customers can read the following KB https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2046494
Varonis solves common ServiceNow data security challenges with our leading Data Security Platform. See how Varonis for ServiceNow can help strengthen your data security posture and eliminate risks today.
