Snowpick scanner detects exposed ServiceNow instances
Learn how Snowpick scans for exposed ServiceNow instances. Discover how this tool found 31% of instances exposed sensitive data.
Security researchers at Bishop Fox released an open-source scanner called Snowpick to test for data exposure on ServiceNow instances. The tool checks ServiceNow portals for vulnerabilities that allow unauthorized users to retrieve records without logging in. The researchers tested 166 ServiceNow instances during authorized penetration tests and found that 31% of those instances exposed sensitive data.
How Snowpick Works
ServiceNow delivers data through two main public surfaces: Service Portal widgets and the Table REST API. Widgets live at paths like /api/now/sp/widget/{widget_id} and handle knowledge base searches, ticket forms, and attachment views. The Table REST API at /api/now/table/{table_name} queries internal tables like sys_user, incident, and oauth_entity directly. Each surface evaluates access control on its own path, meaning an instance can lock down widgets while still allowing table queries.
Snowpick requests the public login page to extract a session token, then reuses that token for follow-on API calls. The tool probes a set of default widgets plus 26 built-in table and field pairs. It can also ask the instance which widgets are installed and add those to the list. This approach catches custom widgets that organizations build themselves, as those widgets often carry access rules that never passed through platform review.
Related: ZoneAlarm boosts mobile security with content filters
Most of the data exposures Snowpick identified came through the ticket-attachments widget. This stock widget returns metadata about files attached to tickets, including titles and descriptions that often contain internal process details like onboarding guides and access request procedures. The scanner also found exposed knowledge base articles, incident ticket metadata, service catalog items, department structures, and facility locations. Record counts per finding ranged from dozens to the thousands.
Some findings showed that the system confirmed records exist but refused to return them. This “count oracle” behavior allows an attacker to infer the existence of data without seeing it. Varonis Threat Labs documented this blind inference through count behavior as CVE-2025-3648. Snowpick saves the reported total, a bounded sample of rows, and a curl command that reproduces the request for each finding.
The researcher behind Snowpick, Emilio Gallegos, noted that the row-returning exposures were not new zero-days. They were access-control and configuration issues across public ServiceNow surfaces. Two instances in the dataset successfully blocked widget probes while still allowing table queries, demonstrating that the two surfaces operate under different security rules.
Related: New Cybersecurity Tools Debut This Week
The Need for Snowpick
Gallegos said his team started with the idea that releasing Snowpick would not materially change attacker capability. The underlying techniques were already public, with Aaron Costello documenting widget-simple-list exposure in October 2023. AppOmni followed with analysis of ServiceNow ACL mechanics. Keeping the tool internal would not slow anyone probing systems they do not own.
Gallegos explained that keeping the tool secret would only keep the people accountable for these systems from finding and fixing that exposure before it becomes an incident. ServiceNow can reduce the number of unsafe patterns through guardrails around public widgets and table access, but the platform is designed to be customized. Organizations add their own widgets, tables, roles, and ACLs over time, and those combinations can behave differently than expected when reached from an unauthenticated session.
Remediation work requires checking public Service Portal widgets that return ticket, attachment, knowledge base, catalog, or list data. Table-level, field-level, and row-level ACLs need a separate pass. A widget blocked on direct load can still be reachable through another widget that loads it, so security teams must test their public-facing instances from the outside to catch these issues.
