ServiceNow Yokohama patch Query Range ACL Update – Issue Summary

[Taha El alami]

Hi Community,

• Overview
  While working on a customization, I added two new date fields to a ServiceNow table. When I
  tried to query the table using these fields with range conditions, I encountered the following
  error:  "Part of the query has been ignored because of insufficient access for 'query_range' operation."
  This unexpected behavior led me to investigate and uncover a significant platform change
  introduced by ServiceNow (Yokohama patch) in May 2025 : a security update that restricts
  range-based queries unless explicitly permitted through new ACLs.
• What Changed?
  ServiceNow introduced two new ACL operations to mitigate the risk of sensitive data exposure
  through filtered queries:
  - query_range
  - conditional_table_query_range
  These control the ability to run queries using range operators like >, <, >=, <=, and BETWEEN.

• Key Implications
  - Stricter Defaults: Range queries are now blocked by default unless explicitly permitted via
  these new ACLs.
  - Error Messaging: Users without the appropriate ACLs will see messages like the one I
  encountered.
  - Required Action: Admins must define query_range ACLs for fields where range queries are
  needed and assign them to the appropriate user roles.

• Why It Matters
  This update closes a security loophole where attackers could infer sensitive data by
  manipulating query ranges. With this change, ServiceNow ensures that only users with explicit
  permissions can perform such queries — enhancing data protection across the platform

Thanks.

Taha Elalami : Servicenow Consultant

LinkedIn 

[shantanu_patel8]

@Taha El alami Very informative 🙂

[Daniel Oderbolz]

Hi @Taha El alami 

Thanks for your post, but as already discussed on Linkedin, that's not the full picture.

The ACL type "query_range" was introduced already some major versions ago (as early back as Washington D.C.).

What Service Now did was that they created a large amount of new ACLs that in fact use this query type.

You are right about "conditional_table_query_range" - however, nobody really seems to know what it does.

(The long name alone suggests a creative approach that I do not quite approve of).

There is a discussion about this operation here but noting conclusive yet.

This KB Article sheds some light on this: May 2025 Maintenance Information 

[EshikaAgrawal]

Hi @Taha El alami  / @Daniel Oderbolz ,

Suppose in our table we have read and query range acls , so in code we use canRead() check with gliderecord , Is there any way where we can check for query_range acl like canread?

Also, from code how will we determine that now query range needs to be checked ?

For example: in read acl whenever we use .getvalue() , we know, better to check canRead() before getvalue () so any similar way to know where to check for query_range in code or it gets applied automatically? Even when not using gliderecordsecure ?