Introducing snowpick: Testing ServiceNow for Public Data Exposure

TL;DR

ServiceNow portals can expose backend records through public widgets and API endpoints that query backend tables, even when the visible portal appears locked down.
snowpick is a Bishop Fox-built tool that checks those paths from an unauthenticated session and separates real row access from count-only leaks. It produces small, reproducible evidence packages so testers can prove impact and defenders can fix the exact misconfiguration without bulk data collection. Get the tool on GitHub.

ServiceNow runs a large share of enterprise IT operations. Organizations use it for incident management, HR workflows, asset tracking, service catalogs, knowledge bases, and customer service. That makes ServiceNow a valuable source of operational data, and a permissive access control list (ACL) can expose more than a single record type.

Bishop Fox built snowpick to help security teams test this class of issue systematically during authorized assessments. The tool checks two independent ServiceNow paths, identifies publicly reachable records, adds impact context, and generates reproduction details defenders can use to verify and fix issues.

snowpick is intended for systems you own or have explicit permission to test. It should not be used against third-party ServiceNow instances without authorization.

The ServiceNow Exposure Problem

ServiceNow exposes data through two API surfaces with independent access control paths.

The first is the Service Portal widget API. Widgets power ServiceNow self-service portals, including knowledge base search, ticket submission forms, service catalogs, and attachment views. Each widget is accessible at /api/now/sp/widget/{widget_id} and accepts POST requests with a JSON payload. If a widget is configured for public access, unauthenticated users may be able to retrieve the data it serves. In many cases, a caller only needs a ServiceNow session token issued by the login page.

The second is the Table REST API at /api/now/table/{table_name}. This API is the direct interface for querying ServiceNow tables such as sys_user, incident, kb_knowledge, oauth_entity, and many others. The Table REST API has a separate ACL evaluation path from the widget API. An instance can have widgets locked down while still exposing table data or have the reverse problem.

These issues are easy to miss because ServiceNow access control is layered. Table-level ACLs, field-level ACLs, row-level ACLs, widget-level ACLs, and API-level controls can all interact. Many organizations also add custom widgets, custom tables, and custom roles. Each customization creates another place where public access may be unintentionally granted.

Prior public research established the techniques snowpick builds on. Aaron Costello documented ServiceNow data exposure through widget-simple-list in October 2023, including session token bootstrapping and table enumeration. AppOmni later published deeper analysis of ServiceNow ACL mechanics and public Service Portal widget exposure. Varonis Threat Labs documented count-based blind inference through the filterText parameter in Count(er) Strike, tracked as CVE-2025-3648.

Why We Built snowpick

Existing tools can detect parts of this issue, but using the research during assessments still required manual work. Testers had to bootstrap sessions, choose candidate widgets, guess useful table and field pairs, check whether the Table REST API behaved differently, and decide how much evidence was enough without collecting more data than needed.

bsysop/servicenow checks a static list of table and field pairs through widget-simple-list. That approach is useful, but it can miss custom widgets, non-default tables, and Table REST API exposure.

snowpick turns that workflow into a repeatable check: it tests widgets and table APIs, discovers installed widgets where possible, separates row access from count-only behavior, and saves bounded evidence for review.

How snowpick Works

snowpick follows the path an unauthenticated tester would take by hand, but makes it repeatable: get a public session, ask the portal what it will return, check whether table data is reachable through widget behavior or the Table REST API, and preserve just enough evidence to support remediation.

Starting With a Public Session

snowpick starts by requesting the public ServiceNow login page, extracting the ServiceNow session token, and reusing that token and its associated cookies for follow-on API requests.

That setup is the core of the test. The question is not whether a valid employee account can read a record. The question is whether a public session can reach data that should require authentication or stronger authorization.

Treating Widgets Like Data APIs

Service Portal widgets are usually discussed as page components, but for testing purposes they behave like data APIs. A direct request to /api/now/sp/widget/{widget_id} can return ticket metadata, knowledge base content, catalog data, attachment details, or other records if the widget is public and the underlying ACLs are too permissive.

snowpick probes built-in widget candidates such as ticket-attachments, kb-article-page, kb-search, kb-category-list, sc-category, and simple-list. It can also ask the target instance which widgets are installed and add those IDs to the probe list. That discovery step matters because mature ServiceNow environments are rarely stock; custom widgets often encode organization-specific assumptions about who should be able to see the data they return.

Checking Tables from Two Angles

snowpick checks table-oriented access through both widget-simple-list and the Table REST API.

For widget-simple-list, snowpick uses curated table and field pairs covering users, incidents, departments, companies, assets, attachments, catalog items, customer records, and operational tasks. This is the path highlighted in Aaron Costello's original research: a public widget can become a way to ask for records by table and field name.

Separately, snowpick can query /api/now/table/{table}. The Table REST API has its own authorization path, so a target can look clean through widgets and still return records there. In our testing, this check identified two instances that had no widget findings.

Preserving the Shape of the Result

The output preserves what the instance actually returned instead of flattening everything into a yes-or-no result.

• exposed means snowpick received records and evidence fields.
• count_oracle means ServiceNow confirmed that matching records exist but did not return the rows themselves.
• not_exposed means the check did not identify accessible data. snowpick also uses explicit states for missing widgets, token errors, and request errors.

A count oracle is not the same as full row exposure, but it is still a finding. Varonis Threat Labs showed in Count(er) Strike that count-only behavior can support blind inference when an attacker can vary filters and observe count changes. snowpick labels count-only results separately so operators and clients do not mistake confirmed record counts for retrieved records.

Evidence Without Bulk Collection

For findings that return rows, snowpick records the total count when ServiceNow provides one, the number of rows sampled, evidence fields, bounded sample records, and reproduction material. For count-only findings, snowpick records the count behavior and reproduction steps without implying that row data was retrieved.

The split between total count and sample count is deliberate. If ServiceNow reports thousands of matching records and snowpick collects only a small sample, the output preserves both facts. That gives the consultant a defensible impact statement without requiring bulk data collection.

snowpick also adds impact hints. These are triage signals, not authoritative data classifications. Current categories include:

• PII: user records, email addresses, and contact data
• Credentials: OAuth tables, API keys, bearer tokens, and secret-like values
• Infrastructure: CMDB entries, asset records, departments, and facility metadata
• Internal operations: incident tickets, work orders, service requests, and knowledge base content

Each hint has a basis. observed means snowpick saw matching content in returned sample data. inferred means the hint came from metadata such as a table name, field name, or widget name.

review_required means snowpick found exposed or count-only evidence, but no built-in hint rule matched and the operator should inspect the result manually.

Finally, for findings, snowpick emits structured JSON and reproduction-ready curl commands where applicable. The output shows the affected surface, what evidence was collected, why the result may matter, and how defenders can reproduce the behavior during authorized validation.

Findings from 166 Authorized ServiceNow Assessments

We used snowpick during authorized penetration tests across 166 ServiceNow instances. These were real enterprise environments, not opportunistic internet scans, and the results show that mature teams can still miss public ServiceNow exposure paths.

31% had at least one finding. Fifty-two of 166 instances returned data or count-only evidence that should not have been publicly accessible. Those affected instances represented roughly 15 organizations, or about 75% of the organizations in the dataset.

Row exposure was confirmed with bounded sample records and reproducible requests. Count-only findings were preserved separately with reproduction steps that show the count behavior without claiming row access.

The ticket-attachments widget was the dominant vector. Most positive findings came through the ticket-attachments widget (ff26f2b1db12220099f93691f0b8f5ce). This widget returns metadata about files attached to tickets, including titles and descriptions that can reveal internal process details.

The Table REST API caught issues that widget scans missed. Two instances had no widget findings but returned data through /api/now/table/, which is why snowpick checks both surfaces.

Observed exposure clustered around operational data. We saw exposed knowledge base articles, incident ticket metadata, service catalog items, department structures, and facility locations. Record counts ranged from dozens to thousands per finding.

We did not observe credentials or authentication material in this dataset. Most findings were internal operations or infrastructure exposure. However, the same surfaces can expose higher-sensitivity tables such as oauth_entity or sys_user if ACLs are misconfigured, so defenders should not treat the absence of credentials in this sample as a limit on the risk.

Preventing ServiceNow Public Data Exposure

The fix is not a single patch or one endpoint block. ServiceNow data leakage usually comes from how public portal functionality, widgets, tables, and ACLs interact.

Security teams should review public Service Portal widgets for unauthenticated access, especially widgets that return ticket, attachment, knowledge base, catalog, or list data. Custom widgets deserve the same scrutiny as platform-provided widgets, and often more, since their access rules were written in-house and never vetted as platform defaults.

Teams should also review Table REST API access separately from widget access. The two surfaces do not behave identically, and a clean result on one does not prove the other is safe. Table-level, field-level, and row-level ACLs should be tested from an unauthenticated perspective, not only reviewed from the admin interface.

Finally, test the paths users do not normally browse directly. If a widget is blocked when loaded directly, verify that it is also blocked when reached indirectly, such as through a widget that can load other widgets. ServiceNow's own guidance on securing public-facing widgets and AppOmni's ServiceNow remediation guidance are useful references for teams hardening these entry points,

Acknowledgments

snowpick builds on research published by several individuals and teams.

• Aaron Costello (Enumerated.ie, October 2023) documented the original widget-simple-list data exposure technique, including session token bootstrapping and table enumeration.
• AppOmni (technical analysis, November 2023; KB article exposure, September 2024), also authored by Aaron Costello, published deeper analysis of ServiceNow ACL mechanics and public Service Portal widget exposure. ServiceNow has since remediated the modal path- public wrappers now enforce the wrapped widget's access controls— so snowpick focuses on the widget and Table REST API surfaces that remain exploitable when misconfigured.
• Varonis Threat Labs (Count(er) Strike research, CVE-2025-3648) documented the blind data inference technique using record counts and the filterText parameter.
• bsysop maintains a ServiceNow scanner that checks table exposure through widget-simple-list.

snowpick is open source at github.com/BishopFox/snowpick. Pull requests for new widget candidates, table candidates, or hint rules are welcome.

FAQs

Can ServiceNow expose data without requiring authentication?

Yes. ServiceNow includes public-facing functionality such as login pages, Service Portals, and knowledge bases. If widgets, APIs, or access control lists (ACLs) are misconfigured, unauthenticated users may be able to retrieve information that should only be available to authenticated users. In most cases these exposures come from configuration, not a flaw in the ServiceNow platform itself, which is why they surface during configuration review and authorized testing rather than patch management.

What does snowpick test?

snowpick is an open-source tool developed by Bishop Fox to identify publicly accessible data in authorized ServiceNow environments. It evaluates both the Service Portal widget API and the Table REST API from the perspective of an unauthenticated user, then generates bounded evidence that security teams can use to validate findings, understand potential impact, and support remediation.

Why does snowpick test both Service Portal widgets and the Table REST API?

These interfaces evaluate access controls independently. An organization may properly secure its Service Portal widgets while unintentionally exposing the same information through the Table REST API—or vice versa. During our authorized testing, some instances exposed data through only one of the two interfaces, so testing both is necessary.

What did Bishop Fox find?

Across 166 authorized ServiceNow assessments, 31% of instances returned data or count-only evidence through at least one ServiceNow API surface. Most findings involved operational information such as ticket attachment metadata, knowledge base articles, service catalog data, and organizational structure. We also found that testing only widgets would have missed some exposures that were accessible through the Table REST API.

What types of ServiceNow data can be exposed?

The data exposed depends on an organization's configuration and access controls. In our testing, the most common findings included ticket attachment metadata, knowledge base content, service catalog information, and organizational data. While we did not observe exposed credentials in this dataset, the same APIs and access paths can expose more sensitive tables if ACLs are misconfigured.

How can organizations reduce the risk of ServiceNow data exposure?

Reducing risk requires more than reviewing ACLs in the administrative interface. Organizations should validate public Service Portal widgets, test the Table REST API independently, review custom widgets for unintended anonymous access, and evaluate permissions from an unauthenticated perspective. Testing from an unauthenticated perspective confirms whether the configuration actually behaves as the admin interface implies.