WorkOS Breach: Why Every Internal API Is Now a Public API

On October 30, 2026, WorkOS detected unauthorized access to an internal application used by its sales team. The attacker did not break into Salesforce. It did not break into Snowflake either. According to a customer notice reposted on Hacker News, it reached an internal API used by sales and marketing tools, and that API already had a trusted path into both.

The route the attacker took matters more than the company's name or the attack tool's name. Salesforce and Snowflake are hardened, audited platforms with dedicated security teams. Internal APIs, like the one sitting between those platforms and WorkOS's sales tools, are rarely built to that standard. They do not need to be, as long as they stay internal. This one did not stay internal.

What happened at WorkOS

WorkOS sells SSO, directory sync, and audit features to software companies. It published a security bulletin on November 2. The bulletin confirms unauthorized access to an internal sales application and says the investigation "identified the use of an AI-assisted offensive security framework to automate reconnaissance and exploitation attempts."

According to the bulletin, the affected data included:

• Business contact details from CRM systems: names, email addresses, phone numbers, job titles, and company affiliations
• Account histories and sales relationship information
• Summaries and excerpts from sales calls, support discussions, and customer Slack conversations
• Operational metadata about how customers use WorkOS products

The customer notice reposted on Hacker News adds the detail the bulletin leaves out: the attacker reached "an internal API used by sales and marketing tools" and, through it, data stored in Salesforce and Snowflake. The notice attributes the activity to ARTEX, an open-source autonomous penetration testing framework, and says the traffic came from IP addresses in Hong Kong and China. WorkOS CEO Michael Grinich stated on the same thread that production systems were not affected and no customer platform data was accessed.

Several things remain undisclosed: how the attacker first got in, how many customers are affected, and when the access began. WorkOS has disabled external access to the affected application and is reviewing who can access its other internal tools.

Why attackers targeted an internal API instead of Salesforce and Snowflake

An internal API that connects to a system of record (the authoritative store for a type of business data, such as a CRM or a data warehouse) inherits that system's value without inheriting its defenses. The sales tool at WorkOS needed to read CRM records and warehouse data to do its job. To do that, the API behind it had to hold credentials, tokens, or service accounts that Salesforce and Snowflake already trusted. Anyone who could call that API could ask it to fetch the same data.

That path is both authenticated and easier. Salesforce enforces its own login policies, session controls, and anomaly detection. When an internal API calls Salesforce through a service account, that service account passes those checks every time, because it is supposed to. From the Salesforce side, a request triggered by a sales rep and a request triggered by an attack framework look the same when both arrive through the same service account.

The attacker skipped the hard target and went to the soft one that already had the keys. Internal APIs tend to be that soft target for predictable reasons:

• They are built fast, for a small known audience, and often by teams outside the core product engineering group.
• Their authentication assumes the network boundary does part of the work.
• They rarely appear in the API inventory that security teams review.
• Nobody watches their traffic, because nobody expects outsiders to send any.

None of these reasons requires a careless team. They follow naturally from the assumption that "internal" means "unreachable."

Every internal API is now a public API

An internal API is an API built for use inside an organization, by its own employees, tools, or services, rather than for customers or partners. The term describes who the API was built for. It says nothing about who can reach it.

That distinction is now the whole problem. Internal tools get deployed to cloud platforms, put behind a login page, opened up for a remote sales team, or connected to a third-party SaaS product. Each step makes sense on its own. Together, they turn an internal API into an internet-reachable API that still carries internal-grade security. WorkOS's own remediation confirms the sales application was reachable from outside: the company disabled "external access to the affected application."

Security and platform leaders should stop treating "internal" as a security classification. Every internal API should be held to the same design and security baseline as a public one:

• Authentication that does not depend on network location
• Authorization checked on every object, not just at login
• Rate limits and response-size limits that match real usage
• A named owner, a documented spec, and a place in the API inventory
• Runtime monitoring of who is calling it and what it returns

How the WorkOS API got into its vulnerable state is unknown. It may have been generated quickly with AI coding tools and never reviewed. It may have had a design flaw. It may have fallen outside governance entirely. None of these have been confirmed, and the bulletin does not say. What the incident does show is that an internal API with access to two systems of record was reachable and exploitable, and that this combination was enough to expose customer data from both.

For a deeper look at how APIs end up outside any inventory, see Treblle's explainer on shadow APIs.

How AI attack frameworks find internal APIs

ARTEX automates the search for these APIs. Security researchers at Wiz describe the framework as an agent that reads the target application before attacking it. It downloads "exposed source maps, runtime configurations, and Swagger/OpenAPI documentation" to map internal routes. It then tests password-reset endpoints, self-signup flows, OAuth callbacks, and predictable object identifiers to look for broken access controls.

Each of those is a well-known weakness. The OWASP API Security Top 10 has listed broken object level authorization (BOLA) as its first risk since 2019. What ARTEX adds is speed, persistence, and wide availability. Its creator made the original repository closed-source on October 8 after it had been forked more than 12,000 times, and forks still circulate. In ARTEX campaigns Wiz tracked, the median gap between authentication attempts was one second, and new IP addresses appeared within minutes whenever old ones were blocked. Google's threat intelligence team observed one ARTEX-using actor going from a first compromised account to deep system access in about four hours, and in one case in 15 minutes, according to an analysis of the WorkOS incident on DEV.

A human attacker might never find an internal sales API. An autonomous agent that reads every JavaScript bundle and every exposed OpenAPI file on a domain is built to find it early. Obscurity used to buy internal APIs some time. It no longer buys any.

How runtime visibility catches internal API abuse

Runtime visibility means observing the actual requests and responses an API handles in production, as they happen, rather than relying on its design documents or gateway configuration. Treblle's knowledgebase covers the basics of API monitoring and observability.

Some monitoring was already in place at WorkOS: the company detected the incident through anomalous traffic to an internal system. The open question for any organization is how early that kind of signal fires, and whether it covers every internal API or only the ones someone remembered to instrument.

Applied to an internal sales API, runtime visibility would surface signals like these:

• A new consumer appearing that matches no known employee, device, or tool
• Requests arriving from IP ranges the sales team has never used
• Calls spaced one second apart for long stretches, which no human user produces
• Sequential or enumerated object IDs, the signature of an authorization probe
• Response volumes far above what a sales rep pulls in a working day

None of these signals requires knowing the attacker's tool in advance. Each one is a deviation from how the API normally behaves. An internal API with a small, known set of users has a narrow normal, which makes deviations easier to spot than on a public API, provided someone is watching.

Treblle fingerprints every API consumer by device, user agent, and behavior pattern, and checks every request IP against threat intelligence. Each request also gets a threat score, so a new caller from an unfamiliar network shows up as a flagged request instead of a line in a log nobody reads.

Runtime visibility has a limit worth stating plainly. It does not stop a request that carries valid credentials. It shortens the time between the first malicious request and the moment someone acts on it. Against an agent that can reach deep access in hours, that window can be the difference between a contained incident and a full export of the CRM.

Runtime visibility also surfaces internal APIs that are missing from the inventory. An API that shows up in live traffic but not in the inventory is a shadow API. Finding it early costs far less than a breach notification.

Five checks for internal APIs connected to systems of record

The WorkOS incident is a prompt to run a short audit of internal APIs, starting with the ones closest to systems of record:

1. List every internal API that holds credentials for a CRM, data warehouse, ticketing system, or communication tool such as Slack.
2. For each one, confirm whether it is reachable from the internet, including through a login page or a SaaS integration.
3. Check whether its OpenAPI spec, source maps, or configuration files are publicly downloadable.
4. Confirm that authorization is enforced per object, and that a valid session for one record cannot fetch another.
5. Confirm that its traffic is monitored at runtime, with a baseline of normal consumers and normal response volumes.

Any internal API that fails the second check and the fifth at the same time carries the same shape of risk that WorkOS disclosed on November 2.

Treblle's ebook What Breaks in API Security goes further into where API security controls fail in practice.