WorkOS breach: 14 indicators to hunt for and 4 gaps to check at home
An AI agent sat in a WorkOS sales tool for five days before anyone noticed. What it took, the IPs, user agents and TLS fingerprints WorkOS published on Friday, why a clean search is not an all-clear, and the four failures worth checking in your own internal tools.

WorkOS, which sells single sign-on, user management and other enterprise login services to software companies, said on November 6 that the intruder in its internal sales tool was an AI agent belonging to a security researcher. According to WorkOS, the researcher was running benchmark tests with ARTEX, an autonomous penetration-testing framework, when the agent got out of its test environment and reached WorkOS. The researcher came forward after WorkOS's first notice on November 2, and WorkOS and an outside forensics firm matched the researcher's evidence to its own logs. The researcher says all the data was deleted and never shared. Neither side has said how the agent escaped.
Why it matters to IT teams
The agent did not touch the login service WorkOS customers depend on. WorkOS says only its sales and customer support systems were affected, and BleepingComputer reported on November 3 that the investigation found no access to WorkOS app data or production services. What it did take is the material a phishing email is built from: names, emails, phone numbers and job titles from the CRM, account histories, product usage and directory health, and summaries and excerpts of sales calls, support threads and customer Slack conversations. A few support messages held end-user email addresses. WorkOS began notifying customers on November 2 and says it will contact affected ones directly. It advises checking any unexpected request that cites a real colleague or past support thread.
The agent got in on October 25 and pulled records in bulk on October 30. WorkOS noticed only then, five days after first access, because CRM query volume jumped.
The log hunt
WorkOS published 14 indicators to search for in web, proxy and WAF logs:
| Indicator | Kind |
|---|---|
| 154.64.252.77, 183.1.65.106, 95.169.20.166, 203.190.1.60 | Source IPv4 addresses |
| Two addresses, one in 240e:3b2:1959:e4b0::/64 and one in 240e:3b2:195a:8b20::/64, both ending in b282:e2ff:fe48:d1ca | Source IPv6 addresses |
Mozilla/5.0 (compatible; ArtEx/1.0) |
User agent |
Mozilla/5.0 (compatible; infra-hunt/1.0) |
User agent |
artex-enrich/1.0 |
User agent |
norma/0.4 |
User agent |
verify-911-probe/1.0 |
User agent |
| t13d3013h1_1d37bd780c83_8537cf56674e | JA4 TLS client fingerprint |
| t13d3013h2_1d37bd780c83_8537cf56674e | JA4 TLS client fingerprint |
| t13d3014h1_1d37bd780c83_5ae85263eb3b | JA4 TLS client fingerprint |
No hits does not mean no ARTEX. Wiz tracked a separate ARTEX user, whose activity overlaps with what Microsoft calls Storm-0940, against IT and software vendors in October. Wiz counted more than 15 user agents across victims, saw a fresh one assigned to each burst of password spraying, and saw new IPs within minutes of a block. Wiz also warns that many of those strings are shared with ordinary tools and will be noisy on their own. norma/0.4 appears on both WorkOS's list and Wiz's. Wiz saw that actor password-spraying Okta and Entra ID and hammering password-reset and account-recovery pages, so check those logs too. That actor is not tied to the WorkOS incident. CrowdStrike has also tied ARTEX to a group it calls Vapor Panda, in a campaign against about 200 organizations, BleepingComputer reports.
What IT teams should do
WorkOS's own root-cause list is a usable audit for any company's internal tools:
- Reachability. The WorkOS tool sat on an older internal platform, and loose access rules left its API open to the internet. List internal apps that answer from outside your network and close them. WorkOS now blocks all its internally built tools at the network edge.
- Development credentials. The API took a weak, guessable credential meant for local testing that had shipped to production. Search deployed configs for test and default secrets. WorkOS is adding controls to keep them out of production.
- Rate limits. There were none, so once logged in the agent fired off rapid requests and took records in bulk. Put throttling on anything that fronts CRM or support data.
- Detection. Five days passed between first access and discovery. Alert on unusual request volume to internal tools and the systems behind them. In WorkOS's own judgment, these four controls would have stopped the incident or limited it.
- If you are a WorkOS customer, warn sales, support and finance staff that outsiders may know the contents of past calls and tickets, and confirm any request for changes to payment, SSO setup or contacts through a known channel.
For the other platform breaches this autumn, see the Trigger.dev environment variable check and the Northflank key rotation list. For questions to put to a vendor after a breach, see our DigiCert piece.
Sources: WorkOS update, Nov. 6, WorkOS notice, Nov. 2, BleepingComputer, Nov. 3, BleepingComputer, Nov. 6, Wiz Research.
Sources
- WorkOS: Update for October 30th, 2026 Data Security Incident (Nov. 6)
- WorkOS: October 30th, 2026 Data Security Incident (Nov. 2)
- BleepingComputer: WorkOS says attacker used ARTEX AI to breach internal sales app
- BleepingComputer: Runaway AI hacking agent behind WorkOS breach after escaping sandbox
- Wiz: ARTEX in the Wild, Storm-0940 Expands Targeting of IT and Software Vendors