List Calculation is exposing sensible data, although ACL is correct.

[Christoph Lang]

This issue is based on a Known Error article and something I have raised some time ago.

However I did not find any suitable workaround nor did the TSE in a Case resolve my issue.

Therefore I would like to ask if anyone has an idea.

Known Error Article:

KB2696799 : List Calculation is exposing sensible data, although ACL is correct. - Support and Troub...

Also the Problem behind is "Won't Fix".

The issue can be shown quite simple:

So the user should not see the cell value here. The field level ACL denies the read access.

However the aggregate just does not care and uses it in the sum.

Of course a Sum of only one value can be easily "guessed".

Also another example

We know the profit of "Canada" is now "15.2249" although we should not be able to see that.

If we dig into the data (e.g. "Show Matching") we can easily "reveal" all data.

Personally I think this is a Security Issue.

Also the workaround provided by ServiceNow is not really helpful:

This is existing behavior - ACLs are not applied when computing aggregate data.

The recommended approach is to hide that specific column completely with column-level ACL:

field-level ACL: core_company.profits; answer = false; - ACL is applied in list view to each row in that column, but not in aggregate object
column-level ACL: core_company.profits; role = nobody; - column is excluded from list view, aggregate object not available

The say we should remove the field from the list.

But this is not our use case as we require the field to work with.

Business Use Cases are:

1. See all Projects but only the project cost of projects where I am the Project Manager
2. See all Users but only see the salary of me or users I am the manager
3. *....

So there are a lot of use cases where all records should be visible, but only in certain situations an field value should be visible.

Also the Calculation is something we often use as it makes working with certain lists way more convenient. 

So basically my question is on how we can restrict the access as read / query_match / query_range ACLS are not honored in the aggregate object.

Any idea?

Thanks.

[Achim4]

Thanks for sharing! Wondering if ServiceNow shouldn't treat this somewhat similar than the May 2025 Maintenance (see May 2025 Maintenance Information) which seems to be rather similar, albeit to a more limited extent...

[Christoph Lang]

Hi @Achim4 ,

thought so, too.

Still ServiceNow constantly claims that this is "Working as designed". 😀

Also I agree that it is similar to the May 2025 Maintenance. Maybe a little less critical ... but still an security issue in our environment.

[RyanP6973377016]

@Christoph Lang 

Did you figure out a workaround that you would mind sharing? I have the same issue, and it is mind boggling that ServiceNow does not address this issue. At the moment, we're just removing the list calculations all together since there is no good way to lock these down other than before query business rules that tax the system. 

[Christoph Lang]

I have a hunch that the problem simply hasn't received enough public attention yet.

I assume that if there had been public articles or discussions about it, ServiceNow would have already addressed it.

In my view, this is just as critical as the query* ACLs that were introduced specifically for this purpose as it will expose data that should not be available.

Why this hasn't been fixed is a complete mystery to me.
We don’t have a workaround either, except to completely disable the calculations… which comes at the expense of usability.