how it happened
- whoanyone onlineno login
- the gapmissing access attributeknowledge articles open
- the result1,000+ instancessome exposed live credentials
what everyone assumed
A reputable platform arrives with sensible defaults, so the secure path and the default path are the same path. It is a reasonable belief. The vendor knows the product better than any customer does, the setup screens guide you through, and nobody hands you a platform configured to leak. Configuration feels like the vendor’s responsibility because the vendor built the configuration.
what happened
The public-facing widget could reach knowledge base articles without an authentication step, because those articles were missing the attribute that gates access elsewhere on the platform. An unauthenticated visitor could capture a token, query the widget, and walk the article IDs in sequence. Nothing about this looked like an attack. It looked like a web request to a public page, which is what it was, repeated across instance after instance where the same default sat unchanged.
step by step
- knowledge base articles lack the access attributeA public widget can reach them without authentication.the assumption breaks here
- a visitor walks the article IDs in sequenceIt looks like ordinary web requests.
- September 2024AppOmni finds 1,000 plus instances exposedAbout 45 percent tested. Some articles hold live credentials.
- the fix is a customer settingNo vendor patch needed.
how it surfaced
Researchers at AppOmni reported the pattern in September 2024: more than 1,000 ServiceNow instances exposing knowledge base data this way, roughly 45 percent of the instances they tested. The articles that came back held personally identifiable information, internal system details, and in some cases active credentials and tokens to live production systems. The fix was an access setting the customer controlled, not a flaw the vendor had to patch.
A secure default and a secure configuration are not the same thing.
The platform ships with a setting, and whether that setting fits your data is a decision only you can make, because only you know what is in the articles.
picture it at a company like yours
The company here is made up. The other two paths are not: they happened, and each links to the story.
- in this storythe day it mattersSomeone walks through article numbers one by one from the public page.what it costs youYour internal notes, credentials included, are read by strangers.
- or it goes like thisit happenedMicrosoft AI data exposure, 2023howA share link meant for one folder opens the whole storage account.what leavesbackups, passwords and private messageswho ends up with itanyone who finds the link
- or it goes like thisit happenedPower Apps misconfiguration, 2021howA default on a no-code app leaves its data readable without logging in.what leavespersonal records you collectedwho ends up with itanyone who looks
sources
your turn
what you can do about it
this week
Take your most-used SaaS platform and find the one screen that says who can see this without an account.
Somewhere in your stack is a SaaS tool that someone set up months ago, accepted the defaults on, and has not opened the sharing settings of since. The question the quiet months ask is narrow: which of your tools can be read without logging in. The ServiceNow exposure was findable by anyone willing to open that screen and read it honestly.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →