CVE Tools
Sign in
Back to blog

Count(er) Strike: how a leaked row count exposes restricted ServiceNow data (CVE-2025-3648)

A ServiceNow ACL quirk returns the count of rows it refuses to show -- and that count is enough to reconstruct the hidden data.

CVE Tools··10 min read
Count(er) Strike: how a leaked row count exposes restricted ServiceNow data (CVE-2025-3648). A ServiceNow ACL quirk returns the count of rows it refuses to show -- and that count is enough to reconstr
Count(er) Strike: how a leaked row count exposes restricted ServiceNow data (CVE-2025-3648). A ServiceNow ACL quirk returns the count of rows it refuses to show -- and that count is enough to reconstr

A ServiceNow flaw tracked as CVE-2025-3648 -- nicknamed Count(er) Strike by the Varonis researchers who found it -- lets low-privilege, and in many deployments completely unauthenticated, users read data that the platform's access controls were supposed to hide. There is no code execution and no injection. The platform faithfully hides the restricted rows; the problem is that it keeps handing back the number of rows that matched. Watch that number move as you tweak a filter, and you can reconstruct the hidden values one character at a time (Varonis, The Hacker News).

CVE
CVE-2025-3648Data Inference in Now Platform via Conditional ACLs
7.3 EPSS 2%

Scores as of 22 July 2026live record →

What actually happened

Varonis Threat Labs (researcher Neta Armon) discovered the issue and reported it privately to ServiceNow in February 2024. ServiceNow responded with a staged, defence-in-depth redesign of how its Access Control Lists (ACLs) handle queries, and the CVE was published on 8 July 2025 (Varonis, SC Media). Varonis assessed that the weakness "could have potentially affected all ServiceNow instances, impacting hundreds of tables" -- and given how much sensitive data lives in a typical ServiceNow tenant (IT tickets, CMDB, HR cases, incident records), that is a wide blast radius (Varonis, BleepingComputer).

The reason it is back in the headlines in July 2026 is Snowpick -- an open-source scanner Bishop Fox released to test ServiceNow instances for exactly this kind of public data exposure. Across 166 authorized assessments, roughly a third of instances were still leaking (Bishop Fox, Help Net Security). The vulnerability is old; the exposure is very much current.

The bug: a count that leaks the data it hides

ServiceNow evaluates a read ACL as an ordered set of conditions: required roles, then a security attribute, then a data condition, then a script condition. Where the denial happens is everything. Deny at the roles or security-attribute stage and the user gets a clean wall -- "Security constraints prevent access to requested page," with no further detail. But deny at the data or script condition, and the platform hides the row contents while still returning the total count of matching rows -- shown in the UI as "Number of rows removed from this list by Security constraints" and in the page source as grand_total_rows (Varonis, BleepingComputer).

That leftover count is the whole vulnerability. The access decision on the data is correct, but the count still runs and escapes -- a textbook CWE-1220 (Insufficient Granularity of Access Control) (NVD). To weaponise it, an attacker appends range operators to the list view's encoded query. A request such as <table>_list.do?sysparm_query=<field>STARTSWITHa returns a count; narrow it to STARTSWITHab, then STARTSWITHabc, and the count acts as a yes/no oracle that spells out the hidden value character by character. The dangerous operators are the range family -- STARTSWITH, CONTAINS, >=, <=, != -- and dot-walking through reference fields lets the same trick reach data in related tables the account cannot query directly (Varonis, The Hacker News).

The exploitation chain

Nothing here requires an exploit kit -- just a session and patience. The chain below traces an anonymous or low-privilege session to mass data inference, and marks where a defender can break it.

Count(er) Strike exploitation chain -- anonymous session to mass data inference

  1. Low-priv or anonymous ServiceNow session — A user with partial access -- or a self-registered / public-portal session where that is enabled. **Prevent:** disable self-registration; set public roles to `nobody`.
  2. Find a count-leaking table or widget — Probe `_list.do`, the Table REST API and Service Portal widgets. A table guarded only by a data/script ACL condition returns `grand_total_rows`. **Prevent:** Deny-Unless ACLs + Security Data Filters.
  3. Does the response leak a row count? — Deny at roles/security-attribute -&gt; clean block (safe). Deny at data/script condition -&gt; data hidden but count leaked (vulnerable oracle).
  4. Range-query blind inference, char by char — Append `STARTSWITH`/`CONTAINS`/`&gt;=`/`&lt;=` to `sysparm_query` and narrow the guess, reading the count as a boolean oracle. **Detect:** alert on 100+ near-identical range-clause count queries per source in 5 minutes.
  5. Dot-walk into related tables — Traverse reference fields (e.g. `opened_by.u_c_level`) to infer data from tables the account cannot query directly -- widening the blast radius.
  6. Aggregate PII, credentials, incident data at scale — Automated iteration rebuilds full field values across hundreds of tables. Confidentiality-only, but large in aggregate. **Last line:** monitoring + recurring re-scan catches a missed table.

Am I affected?

Because exposure depends on how your ACLs are shaped rather than only on your build number, the honest answer is "audit, do not assume." The grid below is the quick triage.

QuestionWhat it means
Self-registration or public portal enabled?If yes, the oracle surface is effectively unauthenticated -- highest priority. Set public roles to nobody.
Sensitive tables guarded only by a data/script ACL condition?Empty required-roles + empty security-attribute condition is the leaky shape. Audit sys_security_acl for read ACLs of that form.
On Xanadu / Yokohama, or have the May 2025 update?The new controls (Query ACLs, Security Data Filters, Deny-Unless ACLs) live there. Washington DC and earlier lack Deny-Unless ACLs.
Reference fields on exposed tables?Dot-walking extends the oracle into related tables -- review them too.

Timeline

From private report to public scanner

  1. Discovered and reported to ServiceNow
    Varonis Threat Labs (Neta Armon) finds the range-query count oracle.
  2. Staged patches / ACL updates
    Approximate, per secondary reporting.
  3. Broader ACL-hardening security update
    Query ACLs, Security Data Filters and Deny-Unless ACLs surface for customers.
  4. CVE-2025-3648 published
    Press coverage lands 9-10 July 2025.
  5. Bishop Fox releases Snowpick scanner
    Across 166 assessments, 31% of instances still leaking.
  6. Wider coverage of Snowpick
    Renewed attention to residual exposure.

Is it being exploited?

Not that anyone has observed. The flaw is not in CISA's Known Exploited Vulnerabilities catalog, its EPSS score is low, and Varonis states plainly it is unaware of any exploitation before the patch (Varonis, BleepingComputer). That is genuinely reassuring -- but read it correctly. KEV and EPSS reward internet-scale, fingerprintable exploitation, and a per-tenant configuration bug with no network signature simply does not show up there. The Bishop Fox 31% figure is the counterweight: the latent exposure is high even though the observed exploitation is nil.

How to fix it

  1. Kill the unauthenticated surface first. Disable self-registration / anonymous portal access where you do not need it and set public roles to nobody. This closes the highest-severity path immediately, independent of any upgrade.
  2. Confirm your release supports the new controls. Deny-Unless ACLs require Xanadu or later; Washington DC and earlier do not have them. If you are behind, plan the upgrade and lean on Security Data Filters and Query ACL restrictions in the meantime.
  3. Apply the three new frameworks. Query ACLs gate the dangerous query_range operators (STARTSWITH/CONTAINS/>=/<=) separately from safe exact-match ones; Security Data Filters suppress the removed-row count so the oracle goes dark; Deny-Unless ACLs require all matching ACLs to pass instead of any one (KB2139567, KB2046494, KB2256712).
  4. Audit the leaky ACL shape on sensitive tables -- empty roles + empty security-attribute + a data/script condition -- and run ServiceNow's QueryRangeACLAuditor Script Include to re-apply the range-query logic to newly added fields.
  5. Make it recurring. Re-scan (Snowpick or equivalent) after any ACL or schema change, since a new table or field can quietly reintroduce the exposed shape.

Detecting active abuse

The attack is thousands of near-identical count queries that differ only in a range-clause value -- a shape a rate-and-pattern rule catches well. The Sigma rule below is author-written from the documented request pattern (there is no vendor rule or IOC feed for this technique); baseline it against your own traffic before enabling.

sigmaCount-enumeration detection (author-written) · ServiceNow range-query count enumeration (CVE-2025-3648)

Behavioural detection over proxy / load-balancer access logs fronting the instance. Escalate when the source is a guest or freshly self-registered account, when one STARTSWITH clause iterates across the character set on a single table, or when a lone IP / non-browser User-Agent drives the burst.

High-volume range-operator count queries against *_list.do or the Table/Stats API from a single source Proxy/LB access logs (or ServiceNow syslog_transaction) with URI query strings
title: ServiceNow Range-Query Count Enumeration (CVE-2025-3648)
logsource:
  category: proxy
detection:
  sel_target:
    cs-uri-stem|endswith: '_list.do'    # also: /api/now/table/ , /api/now/stats/
  sel_rangeop:
    cs-uri-query|contains: 'sysparm_query='
    cs-uri-query|re: '(STARTSWITH|ENDSWITH|CONTAINS|LIKE|%3E%3D|%3C%3D|!%3D)'
  condition: sel_target and sel_rangeop | count(cs-uri-query) by c-ip, cs-username, table &gt; 100
  timeframe: 5m
fields: [c-ip, cs-username, cs-uri-query, cs(User-Agent)]
level: high
# ServiceNow-side: query syslog_transaction for high-volume url like '%_list.do%STARTSWITH%'
# or repeated /api/now/stats count calls grouped by user/session in a short window.
Author-written (behavioural, unofficial)
  • Responses being parsed for grand_total_rows or the "rows removed by Security constraints" banner.
  • Monotonic iteration of a range clause -- a, b, aa, ab -- the classic character-at-a-time oracle.
  • Low-privilege, guest, or newly self-registered accounts querying sensitive tables with no business reason.
  • Hundreds to thousands of count queries a minute with no matching record-open events -- the attacker wants the count, not the row.

FAQ

Is CVE-2025-3648 a remote code execution bug?
No. It is a data-inference flaw -- confidentiality only. An attacker reads or infers restricted data via a leaked record count; nothing is written or executed. That is why NVD's CVSS 4.0 vector shows High confidentiality impact but zero integrity/availability.
Do I need to be authenticated to exploit it?
Not necessarily. A low-privilege account works, but where self-registration or anonymous/public portal access is enabled the surface is effectively unauthenticated -- which is why the advisory names both unauthenticated and authenticated users.
Is it being exploited in the wild?
No confirmed exploitation, and it is not in CISA KEV. But Bishop Fox found 31% of tested instances still leaking, so the exposure is real even without observed attacks. Treat it as proactive hardening.
What is the single fastest mitigation?
Disable self-registration / anonymous portal access and set public roles to nobody. That removes the unauthenticated path immediately, independent of upgrading to get Deny-Unless ACLs.

Sources

Tagged
servicenowdata-exposureaccess-controlcve-2025-3648cwe-1220saas-security