When people search "ServiceNow hacked," they are usually reacting to a handful of high-profile data exposure incidents, and in most of them the ServiceNow platform itself was not breached, misconfiguration and known API flaws were. That distinction matters, because the fix is different depending on which one you are dealing with. This guide walks through the real incidents, separates researcher-driven disclosures from active exploitation, and gives you a concrete hardening checklist.
What actually happened
There are three separate events that fueled the "ServiceNow hacked" headlines, and conflating them leads to the wrong response.
The first, disclosed publicly in October 2023, was a widespread data exposure tied to how Access Control Lists (ACLs) and User Criteria were applied to Knowledge Base articles and public widgets. The UserIsAuthenticated condition was not applied to KB articles by default in older configurations, which meant a public-facing widget could return internal article content to an unauthenticated visitor. This was a configuration weakness, not a code exploit, and it affected a large number of instances precisely because the insecure default went unnoticed for a long time.
The second was a set of critical vulnerabilities disclosed in mid-2024, tracked as CVE-2024-4879, CVE-2024-5217, and CVE-2024-5178. These were genuine software flaws in the Now Platform involving input validation and access issues, and they were chained together in active exploitation to read data from vulnerable instances. Security researchers reported dozens of organizations being probed once proof-of-concept code circulated.
The third is a more recent incident in which attackers reached customer data through an unauthenticated API endpoint. In that case the attacker queried records without ever authenticating, which is the nightmare scenario for any multi-tenant SaaS.
Was it a "hack" or a misconfiguration?
Language matters here. A misconfigured ACL that leaks Knowledge Base content is a data exposure that you own, because the platform gave you the controls and the defaults let you down. An unauthenticated API bypass is a platform vulnerability that the vendor owns and patches. Both end with sensitive data leaving the building, so from a customer standpoint the practical answer is the same: assume your ServiceNow instance is internet-reachable, and treat every default as something to verify rather than trust.
The 2023 KB exposure is the most instructive because it was preventable entirely on the customer side. Names, email addresses, and internal documents were reachable because widgets rendered content the visitor should never have been able to request.
The access control model you need to understand
ServiceNow's authorization model rests on a few layers, and a gap in any one of them can produce an exposure:
- ACLs control read, write, create, and delete on tables, fields, and records.
- User Criteria control who can see Knowledge Bases, catalogs, and portal content.
- Public pages and widgets can render server-side data, and if they call records without enforcing authentication, they short-circuit the whole model.
The 2023 issue lived at the intersection of User Criteria and public widgets. A widget marked public that queried KB articles without the UserIsAuthenticated check would happily serve internal content. The remediation was to explicitly apply the authenticated-user condition and to audit every public page for what data it can reach.
How to check whether your instance is affected
Start with the public attack surface, because that is what an anonymous visitor sees.
1. Enumerate every public page and widget:
Navigate to Service Portal > Pages and filter for Public = true.
2. For each public widget, review the server script for GlideRecord
queries that read business data (kb_knowledge, sys_user, incident, etc.).
3. Confirm User Criteria on every Knowledge Base excludes anonymous
access unless the KB is intentionally public.
4. Verify the "glide.knowman.apply_article_read_criteria" and related
properties enforce read criteria on article bodies, not just lists.
Then move to patch state. For the 2024 CVEs, confirm your instance version is at or above the fixed release your ServiceNow support portal lists for CVE-2024-4879, CVE-2024-5217, and CVE-2024-5178. ServiceNow hosts most instances, so many customers were patched automatically, but self-hosted and delayed-upgrade instances are the ones that stayed exposed.
Hardening your ServiceNow instance
A few controls close the majority of the risk that these incidents exploited.
Lock down public content. Treat every public page as hostile-facing. If a widget does not need to serve data to anonymous users, it should not query business tables at all.
Apply read ACLs at the field level. Table-level ACLs are not enough when a single exposed field, such as an email address on a user record, is the sensitive item. Field-level read ACLs limit blast radius.
Enforce MFA and IP access control. The unauthenticated API incident is a reminder that authentication gaps are catastrophic, but for everything that does require login, MFA and instance IP allowlisting sharply reduce credential-based intrusion.
Monitor for anomalous queries. High-volume record reads from a single session or unusual API calls against sys_user or KB tables are early signals of scraping.
Keep dependencies and integrations in view. ServiceNow rarely lives alone. It pulls from and pushes to CI/CD, identity providers, and custom apps, and a vulnerable component in one of those integrations can become the path in. Software composition analysis across your integration code helps here, and an SCA tool such as Safeguard can flag a vulnerable library in a custom scoped app before it ships.
Lessons that apply beyond ServiceNow
The through-line of every "ServiceNow hacked" story is the same lesson that applies to every enterprise SaaS platform: the vendor secures the platform, but you configure the tenant, and insecure defaults are your problem to find. Salesforce, Jira, and Confluence have all produced near-identical exposure stories rooted in overly permissive public access. Build a recurring configuration review into your security calendar, version-control your ACL and User Criteria changes where the platform allows it, and never assume a default is safe because it shipped that way. Our repository security guide covers the same defense-in-depth mindset for the code side.
FAQ
Was ServiceNow's core platform breached?
In the most publicized incidents, no. The 2023 event was a customer-side misconfiguration of ACLs and User Criteria, and the 2024 CVEs were platform flaws that ServiceNow patched. A later incident did involve an unauthenticated API endpoint, which is a platform-side issue.
What data was exposed in the 2023 incident?
Reports described names, email addresses, and internal documents reachable through public widgets that queried Knowledge Base content without enforcing authentication.
How do I know if my instance is patched for the 2024 CVEs?
Check your instance version against the fixed releases ServiceNow lists for CVE-2024-4879, CVE-2024-5217, and CVE-2024-5178 in the support portal. Hosted instances were largely patched automatically; verify anyway.
What is the single most important hardening step?
Audit every public page and widget. Anonymous-reachable content that queries business tables is the recurring root cause across these incidents.