Brief · Business
WorkOS's sales tools got breached, so the next fake "WorkOS" email might know your support history
WorkOS, which sells SSO and directory sync to SaaS companies, posted a security bulletin dated Nov 2 saying that on Oct 30 it "identified unauthorized access to an internal WorkOS application used by our sales team." The good news comes early, and it's the part that matters most: WorkOS says there's "no evidence that WorkOS application data was accessed, nor is there evidence that production WorkOS services were accessed or impacted." So this isn't an SSO bug and there's nothing to patch, but the data involved is exactly what you'd want if you were writing a convincing phishing email to a WorkOS customer.
What was reachable
The bulletin lists contact details, account history, operational metadata, and "Summaries and excerpts from sales calls, support discussions, and customer Slack conversations." WorkOS's customer notice, which a recipient posted on Hacker News, adds company mailing addresses, marketing contacts, support tickets and de-identified usage metrics. The notice also gets more specific about the path, saying the attacker "gained access to an internal API used by our sales and marketing tools" and through it "was able to access data from our Salesforce and Snowflake instances." The notice puts detection at Oct 30, 12:39 PM EDT.
One caution on reading those lists. They describe what the app gave access to, not a confirmed inventory of what was taken, and WorkOS says it's still "reviewing the affected records to determine the impact for individual organizations" and "will contact affected customers directly." Also, the Salesforce and Snowflake detail comes from the notice as posted on HN, not from WorkOS's website.
WorkOS says it disabled external access to the affected application, is reviewing access controls on its other internal tools, and has hired an independent forensics and incident response firm, which it hasn't named.
The ARTEX part
This is where the headlines get ahead of the facts, so it's worth being exact about who said what. The public bulletin doesn't name ARTEX. It only says the attack involved "the use of an AI-assisted offensive security framework to automate reconnaissance and exploitation attempts." The name comes from two places. WorkOS's customer notice, as posted on HN, says "the attack was likely driven by ARTEX, an AI-assisted, autonomous penetration testing framework, from IP addresses based in Hong Kong and China." And WorkOS CEO Michael Grinich, commenting on the same HN thread, wrote that "The attack involved ARTEX, an autonomous AI agent framework used to carry out offensive security operations."
So ARTEX is WorkOS's own claim, hedged as "likely" in the notice and stated flatly in the CEO's comment. WorkOS hasn't named an attacker or a group, and Hong Kong and China IP addresses tell you where the traffic came from, not who sent it. Cybersecurity News, pointing to earlier ARTEX research from Wiz and others, noted that "Neither report establishes attribution for WorkOS." If you see this story tied to a specific threat group, that link didn't come from WorkOS.
Honestly, the tool is the least useful part of the story for most readers. Whether attackers used an AI framework or a person typing by hand, the result for you is the same: someone may have been able to see your team's names, your support tickets and summaries of your calls.
On one hand there's no evidence application data was accessed and on the other an internal API was accessed. They should probably let us know how an internal API was accessed.
What to do:
-
Treat unexpected "WorkOS" or "support follow-up" requests as suspect.
- Why: the reachable data includes real contacts and summaries of real calls, tickets and Slack threads, so a fake message can sound right. WorkOS's own warning is to "verify unexpected requests before sharing sensitive information or taking action."
- How: before acting on any request about SSO or SCIM changes, invoices or credentials, confirm it through a WorkOS contact you already know or through security@workos.com, the address Grinich gave on HN. Give your finance and IT admins a heads-up, since they're the likeliest targets.
-
Check what your team put in WorkOS support tickets and shared Slack.
- Why: support tickets and Slack excerpts are among the data the app could reach.
- How: this is my suggestion, not WorkOS guidance. If anyone pasted secrets (API keys, SCIM tokens, SAML certificates) into a ticket or a shared channel with WorkOS, rotate them. Then watch for WorkOS's direct notice about your organization.
-
Look at your own internal sales tools.
- Why: per the notice, the attacker got into an internal API used by sales and marketing tools and, through it, reached data in Salesforce and Snowflake, and WorkOS's fix included disabling external access to the affected application.
- How: list the internal GTM and sales apps and APIs that can reach your CRM or data warehouse, and put them behind the same SSO and network controls you use for production. That's my inference from WorkOS's fix, not something WorkOS recommended.
Want the next one?
One email, weekly-ish. The week's briefs, how worried to be, and what to do about it. No doom.
Subscribe on Beehiiv ↗Free. Opens Beehiiv in a new tab. Unsubscribe whenever, I won't be offended.