Leaking Tickets: Secrets Exposure in ServiceNow (Part 1)

Real Incidents & Lessons Learned

ServiceNow is the nerve-center of IT for thousands of enterprises. Every ticket, asset record and HR request flows through it. That centrality means the platform holds troves of sensitive data, from user personally identifiable information (PII) and internal project info to ticket attachments, chats and secrets for apps and services.

In recent years, security incidents and research findings have highlighted how secrets and non-human identities get unintentionally exposed in ServiceNow environments. In this blog we’ll explore some notable incidents and unpack what happened, why and what we should learn before we talk about mitigations in Part 2.

What Is ServiceNow?

ServiceNow, commonly known as SNOW, is an industry-leading IT service management (ITSM) platform (SaaS & on-prem) used by organizations to streamline workflows across IT, HR, security and DevOps. It acts as a centralized hub for handling support tickets, managing IT assets, automating requests and integrating solutions. Because it connects so many internal processes and users, it often becomes a quiet repository for highly sensitive data like secrets, user credentials, logs, PII and system access details.

Incidents of Secrets and Data Exposure in ServiceNow

Several high-profile and under-the-radar incidents have revealed that sensitive data, including secrets, can slip through the cracks in ServiceNow environments. From misconfigured knowledge bases leaking credentials to the public, to vulnerabilities that enabled direct access to cases of stolen credentials being used to access ServiceNow instances.

The examples below highlight five such incidents: what happened, why it mattered and what they reveal about ServiceNow as a potential exposure surface.

Public Knowledge Base Data Leak (2020)

• What happened: A security researcher found that many organizations’ ServiceNow Knowledge Base (KB) articles were publicly accessible – no login or any authentication required. By iterating through article IDs, the researcher accessed internal documents, passwords, access tokens, configuration files, and even some customer PII. 
• Cause:  Misconfigured access controls on the kb_view , which was often left open to the internet even when SSO protected the main instance.
• Impact (potential): Sensitive internal data leaked – Internal procedures, network diagrams, and credentials for internal systems were exposed across multiple organizations. 
• Source: Th3G3nt3lman’s blog, the researcher and bounty hunter who reported these findings.

“Help The Help Desk” Credential Exposure (2020)

• What happened: A vulnerability in ServiceNow’s Help The Help Desk feature exposed login credentials including admin usernames and passwords directly in client-side JavaScript. The feature, meant to collect endpoint data, embedded credentials into public JS files on affected instances. More than 600 enterprises, universities and government agencies inadvertently had their ServiceNow login credentials (some with admin privileges) publicly accessible.
• Cause:  A now patched vulnerability in a ServiceNow feature (now deprecated). 
• Impact: Admin credentials exposed – an attacker finding these plaintext credentials could gain admin access to the ServiceNow instance. Taking full control reading or modifying all tickets, knowledge articles, employee records, etc. and even running commands on integrated servers. ServiceNow issued a patch to remove the credential exposure, but until patched, affected organizations were at risk of full compromise. The feature has been deprecated and is no longer active in current SNOW versions.
• Source: The Daily Swig coverage, a patch was released in October 2020.

RCE Vulnerabilities – CVE-2024-4879 chain (2024)

• What happened: A series of critical vulnerabilities (CVE-2024-4879, CVE-2024-5178, CVE-2024-5217) in the ServiceNow platform that allowed unauthenticated remote code execution (RCE) and arbitrary data access. Attackers could exploit an input validation flaw to inject code and then bypass mitigations to read sensitive files and database records. 
• Cause: Public exploits were released soon after disclosure, and threat actors began actively targeting vulnerable instances (including government and corporate ServiceNow tenants) within weeks.
• Impact: Data theft and credential dumps – successful exploitation gave attackers full DB access to the ServiceNow instance. In observed attacks, criminals dumped user account lists and account credentials from ServiceNow DBs in most cases hashed, but in some instances secrets were stored in plaintext and were directly exposed. Security firms noted intense chatter in hacker forums about using these flaws to target IT service desks and portals. ServiceNow released patches and hotfixes in July 2024 and even pre-emptively patched its hosted customers’ instances urging everyone to upgrade quickly.
• Sources: BleepingComputer, NIST

Misconfigured Knowledge Bases (2024)

• What happened: Despite prior fixes, misconfiguration of KB permissions persisted. A research disclosed in Sept 2024 by AppOmni found that over 1,000 enterprise ServiceNow instances (nearly 45% of those tested) had KBs exposing data. Attackers could exploit public KB widgets to bypass access controls and get the content of supposedly internal articles. 
• Cause: Outdated or cloned access control configurations, many organizations failed to set proper “authenticated user” criteria on KB articles and public-facing widgets weren’t covered by recent ACL security updates.
• Impact: PII, NHI tokens and secrets leaked at scale – the exposed KB articles contained everything from internal system details and employee PII to active secrets and tokens for live production systems. ServiceNow’s CISO acknowledged the issue and worked with customers to lock down their KB access settings. This incident was a wake-up call that default settings and admin oversight were still insufficient to prevent data leakage in ServiceNow KBs.
• Source: DarkReading, “Thousands of ServiceNow KB Instances Expose Sensitive Corporate Data”

Microsoft ServiceNow Breach/Stolen Credential (2024)

• What happened: In October 2024, a security researcher accessed Microsoft’s internal ServiceNow instance using a single set of stolen employee credentials sourced from infostealer logs. Although Microsoft’s ServiceNow was configured with Single Sign-On (SSO), the instance still permitted fallback authentication via the standard login page, allowing the researcher to authenticate without SSO enforcement. Upon logging in, the UI appeared broken, however by directly interacting with ServiceNow’s REST APIs, the researcher was able to enumerate data and access two API endpoints using the compromised account’s privileges.
• Cause: Although Microsoft’s ServiceNow was SSO-enabled, the instance still allowed fallback login via the standard /login.do page meaning SSO was not enforced.
• Impact: Massive internal data exposure – using the compromised credentials, the researcher pulled down thousands of support ticket attachments (including internal support chat transcripts, incident reports and onboarding documents) and over 250,000 employee email records with personal details. This breach, resolved by Microsoft with no bounty paid, demonstrated how a single leaked non-human identity or user credential could lead to a severe data leak.
• Source: Medium blog by the researcher. 

ServiceNow, SecurityLater? 4 Ways SNOW Exposes Secrets

ServiceNow’s design and everyday usage make it particularly vulnerable to secret sprawl and data leakage. Here’s why:

Secrets Shared in Tickets

Ticketing is ServiceNow’s primary use case, and in the heat of troubleshooting, users often paste sensitive info into those tickets – also called Incidents, Requests or Tasks. For example, a frustrated employee might open a ticket saying “Can’t access a critical S3 bucket, here is the IAM token I tried <token>” or share a config file with credentials in an attachment. Because tickets are seen as internal and are almost never audited for sensitive content, they become long-term repositories for forgotten secrets. A well-meaning IT/support workflow becomes a long-term security liability.

Misconfigurations and Access Control Gaps

As seen in multiple Knowledge Base incidents, even a small misconfiguration – like leaving a KB article or attachment accessible to “any user” – can expose internal data. ACLs and user criteria must be manually set for each module, but features built for self-service (like portals or KBs) are easy to “mis-scope”. In AppOmni’s 2024 study, 60% of tested instances still allowed public KB access – often due to unaware or overworked admins.

Non-Human Identities in Automation

To accelerate productivity, ServiceNow is frequently integrated with other systems like CI/CD tools, cloud platforms and monitoring solutions that require ServiceNow to store non-human identities’ credentials like API keys and service account tokens. These are often saved in “Credential” tables or scripts. Before newer Vault features were introduced, many of these secrets were accessible to admins or retrievable via script. In the 2024 RCE attacks, threat actors exploited this exact weakness – dumping configuration files and extracting DB credentials from within ServiceNow itself.

A Broad, Mixed-Skill User Base

Unlike source code repositories (used mainly by developers), ServiceNow is used by a broad range of personnel – from IT engineers to HR reps to customer service agents. Many of these users may not recognize a secret if they see one. A support agent or project manager might copy-paste a snippet of config or an email thread into a ticket, not realizing it includes an access token in the headers. This broad user base increases the chance of human error and sensitive data mishandling.

What These Incidents Revealed

The five incidents we covered weren’t edge cases, they were symptoms of how modern ITSM platforms like ServiceNow are used by organizations: rapidly, by many hands, and often without visibility into what sensitive data slips through the cracks.

Secrets and non-human identities don’t just get exposed on code repos or CI/CD pipelines, they show up in support tickets, KB articles, automation scripts and forgotten config tables. And once they do, few teams have the tooling or processes to detect them, let alone respond.

In Part 2, we’ll explore how security and IT teams can reduce this exposure. We’ll cover mitigation strategies, best practices for secrets hygiene in ServiceNow and how Entro helps discover and protect NHIs and secrets across ServiceNow.