Topic starter
11/08/2026 3:17 pm
TL;DR: ServiceNow portals can expose backend records through public widgets and table APIs even when the front end looks locked down, and Bishop Fox’s snowpick tested 166 authorized assessments to separate real row exposure from count-only leaks. The core problem is that layered ACLs create false confidence when widget and table authorization paths are not validated independently.
Editorial analysis by NHI Mgmt Group, based on content published by Bishop Fox: “Introducing snowpick: Testing ServiceNow for Public Data Exposure”.
By the numbers:
- 31% had at least one finding.
- roughly 15 organizations, or about 75% of the organizations in the dataset, were affected.
Key questions
Q: What breaks when a public ServiceNow widget is treated as harmless UI?
A: The assumption breaks when the widget returns backend records through its own API path.
Q: Why do separate ServiceNow widget and table checks matter?
A: They matter because each surface evaluates access control independently.
Q: Where does ServiceNow exposure fail in practice?
A: It fails when teams rely on layered ACLs and assume the layering itself guarantees safety.
Practitioner guidance
- Audit public Service Portal widgets Review every widget reachable through unauthenticated or lightly authenticated paths, especially widgets returning ticket, attachment, knowledge base, catalog, or list data.
- Test the Table REST API separately Run independent unauthenticated checks against /api/now/table/{table_name} because a clean widget result does not prove table access is blocked.
- Classify count-only responses as findings Record count oracles alongside full row exposure so teams can see where existence leakage may support inference or follow-on probing.
Bottom line: ServiceNow exposure often comes from mismatched authorization paths, not from a visible portal failure.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 19 hours ago by NHI Mgmt Group
11/08/2026 3:30 pm
ServiceNow public exposure is an access-control mismatch problem, not a portal problem. The visible interface can look closed while the widget or table path remains reachable through a different authorization check. That gap is especially dangerous in platforms that store operational data, because the security boundary is often assumed to be the portal page rather than the API behind it. Practitioners should treat every public ServiceNow surface as a separate trust decision.
A few things that frame the scale:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should organisations respond when a ServiceNow surface returns count-only evidence?
A: Treat it as a security finding, not as a benign partial result. Count-only responses confirm record existence and can support inference, reconnaissance, or targeted probing even when rows are withheld. Teams should document the result, review the underlying ACL path, and verify whether filters or alternate endpoints turn the count signal into broader disclosure.
👉 Read our full editorial: ServiceNow public widgets and table APIs expose backend records
This post was modified 19 hours ago by NHI Mgmt Group