CVE-2025-3648: Exploiting ACL Logic in ServiceNow to Infer Sensitive Data

Inside the "Count(er) Strike" Vulnerability That Challenges Traditional Access Controls

Introduction

On July 8, 2025, Varonis Threat Labs publicly disclosed a critical flaw in the ServiceNow Now Platform, assigned CVE-2025-3648. Nicknamed "Count(er) Strike," the vulnerability exposes a fundamental weakness in how Access Control List (ACL) logic is evaluated, allowing threat actors to infer sensitive data by manipulating record count outputs. Despite being patched months earlier, many ServiceNow deployments remain vulnerable due to the subtleties of the exploit and the reliance on legacy ACL configurations.

This post dives into the technical aspects of CVE-2025-3648, illustrating how the flaw works, the risks it presents, and what steps organizations must take to mitigate it.

Understanding the ACL Evaluation Logic in ServiceNow

ServiceNow uses ACLs to determine which users can access specific records or fields. The evaluation sequence involves four checks:

  1. Required Roles
  2. Security Attributes
  3. Data Conditions
  4. Script Conditions

If any of these checks fail, access to the data is denied. However, CVE-2025-3648 exploits a logic gap when only the last two conditions—Data and Script—are responsible for denying access. In such cases, while the actual records are not shown, the system still reveals the number of records that match a query.

This opens the door to inference attacks: by crafting strategic queries with filters such as STARTSWITH, CONTAINS, or !=, an attacker can use the record count as a side channel to reconstruct data character by character.

How the Exploit Works

The attack does not require administrative privileges or authenticated sessions in many cases. Even low-privileged, self-registered, or anonymous users can exploit the flaw if ACLs are misconfigured.

For example, consider a user table with records containing usernames. If an attacker queries with usernameSTARTSWITH=A, and the system returns a count of 2, they know two usernames begin with "A." By incrementally modifying the query (usernameSTARTSWITH=AA, usernameSTARTSWITH=AB, etc.), the attacker can gradually enumerate all usernames in the system.

Because the actual data is not returned, this exploit bypasses traditional data leak detection mechanisms. The ability to infer information through aggregate responses makes the attack particularly insidious.

Scope and Severity

The National Vulnerability Database rates CVE-2025-3648 with a CVSS v4.0 score of 8.2, classifying it as High severity. The vulnerability affects virtually all ServiceNow instances that use ACLs with only data or script conditions for sensitive records.

ServiceNow issued patches in the September 2024 and March 2025 security releases. However, many organizations have not yet adopted these updates or revised their ACL strategy accordingly.

Mitigation and Defense

ServiceNow administrators must go beyond simple patching. The core issue lies in how ACLs are structured. To fully mitigate the risk, organizations should:

  • Audit ACLs to ensure that access restrictions include Required Roles or Security Attributes, not just data or script conditions.
  • Implement the newer Query ACLs, Security Data Filters, and Deny-Unless ACL features introduced in the Xanadu and Yokohama releases.
  • Disable or restrict self-registration and anonymous access if not strictly required.
  • Monitor logs for abnormal use of range-based queries, especially from accounts with limited privileges.

Final Thoughts

CVE-2025-3648 represents a paradigm shift in how we think about access control in cloud-native platforms. The idea that data inference via record counts can constitute a breach challenges conventional security assumptions.

For security and platform teams, this is not just a patch-and-forget situation. It requires a thorough re-evaluation of how ACLs are designed and enforced across the ServiceNow environment. With attackers increasingly exploiting logic flaws rather than code bugs, defensive strategies must evolve accordingly.

As a best practice, organizations should consider adopting a deny-by-default model and explicitly grant access based on role and attribute-based controls. The \"Count(er) Strike\" vulnerability underscores that partial enforcement is no enforcement at all.