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 ?

[Daniel Oderbolz]

Hi @EshikaAgrawal 
This is a good question. My feeling is that this is (currently?) not implemented. 
Note that GlideRecord does not respect any ACLs (unless you check yourself) because it is not executed in a users context (in contrast to GlideRecordSecure). (Basically, SN should rename GlideRecord to GlideRecordInsecure and GlideRecordSecure to GlideRecord).

The documentation for GlideElement.canRead()  does not make it clear if it considers all kinds of ACLs.

But I think it is not a good idea to assume that it works as expected...