Understanding ServiceNow’s May 2025 Query Range ACL Update: What You Need to Know

In May 2025, ServiceNow released a critical security patch focusing on Access Control Lists (ACLs) and query security. This update was driven by reports of data exposure caused by misconfigured ACLs, which allowed unauthorized “range” queries to retrieve sensitive information.

In this blog post, we’ll explain what ACLs are and why they matter, summarize the issue that triggered this patch, detail the changes (including new query_range ACL behaviors), and outline what steps ServiceNow administrators should take now. Our goal is to make this update understandable and actionable for a general IT audience with basic ServiceNow familiarity.

What Are ACLs in ServiceNow and Why Do They Matter?

Access Control Lists (ACLs) in ServiceNow are the security rules that govern who can access which data. They control access to tables and fields by defining what operations (read, write, etc.) are permitted for which users or roles. In essence, an ACL rule will only grant access if a user meets all the conditions of that rule. Properly configured ACLs ensure that users only see and manipulate data they’re authorized to – a cornerstone of any platform’s security.

However, if ACLs are misconfigured or left overly permissive—particularly when roles such as 'public' are assigned without sufficient conditions—they can accidentally expose data to unauthorized users, including guest users.

The Issue: Unauthorized Range Queries and Data Exposure

The specific issue that triggered the May 2025 patch was related to “range queries” slipping through ACL gaps.

What does this mean? In ServiceNow, users (or attackers) can craft queries on lists and reports – for example, filtering records where a field starts with a certain string or is within a numeric range. Without strict ACL enforcement, users could leverage these broader search filters to infer or retrieve data they shouldn’t see. This became a real concern when it was found that some ACLs (especially those with no specified roles/conditions) could be abused in this way, potentially revealing sensitive records.

Unauthorized range queries were a key concern – these are queries using operators like “Starts with”, “Contains”, “Greater than”, etc., which return a range of results. If a user didn’t have permission to see certain data, they shouldn’t be allowed to search for it either (otherwise they could guess values or glean information from search results). For example, a user who is only allowed to see their own HR profile should not be able to run a query for “salary between $90k and $100k” and see if any records come up – that could leak salary info. Unfortunately, before this update, the system didn’t explicitly prevent such queries in all cases.

Imagine someone trying to determine the exact salary range of a colleague named Alex, even though they don’t have direct access to salary information. 🔎 First, they filter: "User = Alex AND Salary > $100,000" → If the salary is indeed above $100,000, the system might return a message like: "Number of rows removed from this list by Security constraints: 1" Although the data isn't directly visible, this response indirectly reveals information. 🔄 Next, they adjust the filter: "User = Alex AND Salary > $150,000" → If there's no security message, they learn the salary is below this amount. 📌 Repeating this process with various salary ranges allows them to accurately deduce Alex's actual salary range.

This security gap came to a head in reports earlier this year. Admins noticed error messages like “Part of the query has been ignored because of insufficient access for ‘query_range’ operation” popping up in their instance logs. These errors were actually a byproduct of ServiceNow starting to close the loophole – the platform was denying a query that the user tried to perform on a field without proper ACL permission. One administrator noted: “We recently got our May security maintenance done and now we see ‘…insufficient access for query_range…’ errors when users filter certain lists”. This was the catalyst for the May 2025 ACL security update.

What Changed in the May 2025 ACL Security Patch?

To address the issue, ServiceNow’s May 2025 patch introduced significant enhancements to ACL behavior, particularly around query filtering. The update delivered two new ACL rule types (or “operations”) that admins can configure: query_match and query_range. These weren’t part of the traditional ACL operations set before, and their goal is to give more granular control over who can run certain kinds of queries on your data.

• query_match ACLs – A query_match rule governs exact or direct searches. This covers “safe” operators like equals (=), not equals, is empty, etc. Essentially, these are queries where a user is looking for a specific value or record. ServiceNow documentation explains that query_match ACLs allow specific, targeted lookups – for example, “Incident number = ABC123” or “State is not Closed” would fall under match queries. These are considered lower risk because they return a focused result (you’re only pulling up what you explicitly asked for).

• query_range ACLs – A query_range rule governs broad or pattern-based searches. This applies to operators like greater than/less than comparisons, “starts with”, “ends with”, “contains”, and other queries that return a range or set of results. Such queries are more powerful – e.g. filtering all incidents opened this month, or searching all users with last name starting “Smith”. Because they can reveal sets of data, they’re considered higher risk. In our HR example, searching for all salaries in a range or all SSNs that start with a certain digit would be a “range” query. The new query_range ACL type lets admins explicitly control who (if anyone) can perform those kinds of searches on a given table/field. If a user isn’t authorized via ACL to run a range query on a field, that query will now be blocked.

These new ACL types work alongside traditional ACLs (read, write, etc.) to tighten security. In effect, ServiceNow is enforcing that having read access to a field is not enough to query by that field in any way you want – you also need query access. This prevents users from using unauthorized fields as filter criteria to snoop for data.

So, what does the patch actually do? In many cases, ServiceNow pre-configured a number of baseline Query ACL rules in the update. One expert noted, “ServiceNow just deployed a large number of new query_range ACLs” to cover out-of-box scenarios – essentially, the platform added query ACL rules for many core tables and fields (especially those known to contain sensitive info or be commonly accessed via portals). However, if your instance has custom tables or unique use cases, you may need to add or adjust ACLs yourself (we’ll cover that in the next section).

It’s worth noting that the default behavior of the system, if no query-specific ACL is present, is now to err on the side of caution. By default, a global ACL rule (*.* for query operations) will check if the user has read access to the table before allowing a query. If anything about the query doesn’t pass security checks, the system will block it. In practical terms, after this patch, you might find that certain list filters or database queries that worked before are now being denied – this is the intended protective behavior (to surface any hidden access issues). Administrators will need to explicitly grant query permissions where appropriate rather than relying on implicit access.

Post-Patch Checklist: Steps for Administrators

After applying the May 2025 ServiceNow security patch, admins should take a proactive approach to ensure their instance is both secure and functional. Here’s a checklist of actions:

1. Validate Normal Operations – First, test your instance’s common functions for each user role. Have some end-users and fulfiller roles try to search and filter lists, run reports, and use the Service Portal. Pay attention to any error messages or unexpectedly missing data. A typical symptom of a missing ACL after this patch is seeing an error like “Part of the query has been ignored because of insufficient access” for a certain field or filter. If you encounter an error or a list that doesn’t return results as expected, identify which field and query are involved. This likely means you need to create or adjust an ACL for that field (e.g. add a query_range rule for that field and assign the proper roles to it) to restore the needed access. In other words, verify that authorized users can still do their job, and tighten any screws if they can’t.
   

2. Review “Public” ACLs and Anonymous Access – It’s crucial to thoroughly check ACL rules that previously permitted open or public access. Specifically, look for ACLs explicitly assigned the public role or any ACLs configured without appropriate conditions or scripts. Such configurations might inadvertently grant broader access than intended, including to anonymous or guest users. If you find ACLs that unintentionally allow anonymous access, fix them immediately. A quick fix is to add a script condition like gs.isLoggedIn(), ensuring only authenticated users can access these resources. Alternatively, assign an appropriate restricted role to the ACL. The key is eliminating overly permissive ACL rules that unintentionally allow public or anonymous access. Confirm that any ACL explicitly set with the public role is genuinely required—usually, it’s safer to remove the public role unless specifically necessary.
   

3. Audit Sensitive Data and Fields – Think about which data in your ServiceNow instance is most sensitive (customer data, employee personal information, financial records, etc.). You want to be extra sure that this information is not only protected by read ACLs but also now by query ACLs. For each sensitive field, ask: Who should be able to search or filter records by this field? For example, a Human Resources profile table might contain Social Security Number or Salary fields. Perhaps HR managers can see those fields for individuals, but no one should be able to run a query like “find all salaries between X and Y” or “list all SSNs starting with 9”. Using the new ACL controls, you can enforce that. You might create a query_range ACL on the Salary field that only HR roles have – so non-HR staff could still see their own record, but they couldn’t search salary ranges system-wide. As a rule of thumb, any field that contains particularly sensitive info should probably have a query_range ACL limiting broad searches (and in some cases a query_match ACL as well, if even exact searches should be limited). Take the time to review field-level security for these fields post-patch.
   

4. Test Again and Monitor – After making the above changes, run through your testing one more time. Ensure that legitimate use cases are working and that the error messages are resolved. Over the next few weeks, keep an eye on the system logs for any ACL-related warnings or users reporting inability to filter data. It’s possible you’ll discover an edge case that needs an additional ACL. Also monitor for any performance impacts – typically ACL checks are very fast and this update shouldn’t noticeably slow queries, but it’s wise to watch if any heavy reports start timing out and involve complex ACL logic. Adjust as needed (or escalate to ServiceNow if you suspect a bug).
   

Reported Issues and Troubleshooting Tips

It’s important to acknowledge that not everything may go perfectly smoothly after applying the patch. The most common issue has been users seeing errors when performing queries they used to be able to do. The error message we quoted earlier – “Part of the query on [table] has been ignored because of insufficient access for ‘query_range’” – is a clear sign that the new ACL rules are at work. Essentially, the system is saying “user X tried to filter on field Y, but according to ACLs they’re not allowed to query that field, so I ignored that filter.”

If you encounter this, the resolution is usually straightforward: create a new ACL rule to allow that query (if it’s supposed to be allowed for that user). For example, if users in the itil role need to filter incidents by a certain field and they get this error, create a query_range ACL on that field (and/or a query_match ACL, depending on the type of filter) for the incident table, and give it the itil role. Once the ACL is in place, the query will no longer be blocked and the error will disappear.

In some cases, you might be unsure which field or ACL is causing the trouble. The error message from the platform should specify the table and operation. That tells you which field on which table lacked a proper rule. With that info, you can go into your ACL list and add the needed rule. It’s a bit of detective work, but the clues are there.

What if something that was open before is now intentionally blocked? It’s possible you might decide that, after the patch, certain broad searches really should stay disallowed (for security reasons). For instance, maybe before the patch a manager could export a list of all users’ email addresses by doing a search – technically they had read access to the table, but maybe they shouldn’t be doing that. Now the patch blocks it unless you explicitly allow it. You have a choice: either grant a query ACL to restore that ability (if it’s truly needed for business), or accept that the new default improves security and leave it blocked. Many organizations err on the side of security unless a user truly needs the capability.

One word of caution: some administrators initially reacted to these errors by disabling the new query ACL enforcement entirely (there is a global ACL record *.* for query_match and query_range that one could deactivate). We do not recommend turning off the security feature except perhaps as a very temporary workaround while you implement proper ACLs. Disabling the global query ACL check would stop the errors, but it would also revert your instance to the previous vulnerable state where unauthorized queries might slip through. It’s better to configure the specific ACLs needed. Only consider modifying the global ACL if you are in a pinch and under guidance from ServiceNow support.

Speaking of support – don’t hesitate to reach out to ServiceNow or your ServiceNow partner if you run into a scenario you can’t resolve. If something doesn’t make sense – for example, you added an ACL but the error persists – open a Support case.

Conclusion: Audit Your ACLs Today

The May 2025 ServiceNow ACL security update is a vital step toward protecting your instance’s data. It closes loopholes that could have allowed unauthorized access via clever querying, and it gives administrators more control over how data can be retrieved. While the change requires a bit of effort – reviewing and updating ACL configurations – it’s effort well spent for the security gains. As we’ve seen in past incidents, something as small as an unchecked ACL can lead to major data exposure, so taking ACL management seriously is non-negotiable.

Now is the time to audit your ServiceNow instance’s ACLs. Use the checklist above as a starting point. Make sure every table and field has the appropriate protections in place. Verify that no sensitive info is accidentally left accessible. This isn’t a “set and forget” task – incorporate ACL reviews into your regular governance (especially if you add new applications or fields down the line).

By applying the patch and following up with these best practices, you’ll ensure that your ServiceNow security posture is strong. Your users will only access what they’re supposed to, and potential attackers or prying eyes will be kept out. The platform has given us finer tools to configure security (like query_match and query_range), so let’s use them effectively.

Finally, if you need any help understanding these changes or performing a thorough ACL audit, don’t hesitate to seek assistance. Our team is here to help interpret the ServiceNow security updates and can guide you in implementing them according to best practices (feel free to reach out if you’d like an expert to double-check your ACL setup).

The information in this post is based on our understanding of the ServiceNow May 2025 security update. Always refer to official ServiceNow documentation for definitive guidance and test thoroughly in sub-production instances before implementing changes in production