For: developers, product owners and organization admins who use WorkOS for SSO, directory sync or authentication. This article is based on the company's official notice and does not cover attack methods.
Developing: this article will be updated as the organisation publishes more
- Who is affected
developers, product owners and organization admins who use WorkOS for SSO, directory sync or authentication.
- Confirmed so farSee the table ↓
- First unauthorized access
- Bulk retrieval and cut-off
- Contact details (names, emails, phones, titles, companies)
5 more
- Customer account histories, sales and relationship information
- Sales call summaries and excerpts, support discussions, customer Slack conversations
- End-user email addresses
- Operational metadata (product usage, connection and directory health)
- Involvement of a malicious actor
- Not yet confirmed
- How many customers are affected and how many records were retrieved
- How each customer is affected
- Completion of remediation, such as moving the remaining internal apps off the legacy platform
- What to do nowSee the steps ↓
- Verify anyone claiming to be WorkOS through a channel you know
- Find what you shared in support, Slack and sales
- Rotate any secret you pasted
2 more
- Double-check settings changes and permission requests
- Brief your team
- Where to verify (source)All sources ↓
- WorkOS, "Update for October 30th, 2026 Data Security Incident" (English, dated November 6, 2026, checked November 7)
- Last checked
- As of November 7, 2026 (Japan time)
Follow-up plans and what we checked
On November 6 the company published an update following its November 2 notice. It says the company and an independent forensics firm validated the researcher's evidence against its logs. We checked the page on November 7, 2026.
What WorkOS customers should do today
Verify anyone claiming to be WorkOS through a channel you know
In its November 2 notice the company said business contact information and details from past conversations can make fraudulent requests look legitimate, and asked customers to verify unexpected requests before acting, even when a message references a real colleague or support conversation.
- Check through a dashboard you opened yourself, the contact you have had since signup, or the official website's contact page (not by replying to the message or using its links)
- This site's addition: knowing details of a past support case or a colleague's name is not proof a message is genuine (What is phishing)
Find what you shared in support, Slack and sales
The company says summaries and excerpts of support discussions and customer Slack conversations are among the data involved. Look back at what you wrote there (this site's advice).
- Search support cases and shared Slack channels for pasted keys, tokens, passwords, config files and connection details
- Check how widely you shared things that make fake messages more believable, such as member lists, the identity provider (IdP) you use and your directory layout
- If you sent end-user email addresses to support, decide internally whether those people need to be told
Rotate any secret you pasted
The November 6 update lists no customer actions, and the researcher says the data was deleted. Even so, a secret pasted into support or Slack may sit in the conversations involved, so this site advises rotating it (this site's addition, Environment variables and API key basics).
- Distribute the new key first, check it works, then disable the old one
- Delete keys you no longer use instead of recreating them
- Going forward, do not paste secrets into support. Mask them or use a secure way to hand them over
Double-check settings changes and permission requests
SSO connection settings, directory sync and adding admins are high-value actions for an attacker. Confirm that a request is genuine through a different channel from the one it arrived on, such as a phone call, internal chat or a contact you already know, before carrying it out (this site's addition).
Brief your team
Tell the people registered as WorkOS contacts, whoever opens support cases and your sales contacts about this incident and how to verify messages. The messages need not go to admins only (this site's addition).
1. A message arrives claiming to be WorkOS or support
Even if it knows your past cases or Slack topics, it may not be genuine
↓
2. Do not open links, do not reply
↓
3. Verify through a known channel (a dashboard you opened yourself, your signup contact)
Until then, hand over no keys and make no settings changes
What happened (from WorkOS's notice)
The following is based on the incident notice the company published on November 2, 2026 and its update of November 6.
October 25, 2026
First confirmed unauthorized access to the API of an internal tool used by its sales and customer-facing teams (November 6 update)October 30
Records retrieved in bulk. The company removed public access to the tool and began remediation. It says monitoring did not detect the activity until this dateOctober 30-31
Authentication secured, credentials of connected services revoked or rotated, and access restricted for all internally developed tools (company)November 2
The company published its first notice and began notifying customersNovember 3-5
A security researcher contacted the company and provided evidence. The company and an independent forensics firm validated it against the company's logsNovember 6
The company published its update, describing the cause, the data involved and remediationNovember 7
We checked the update
- Entry point
- The API of an internal tool used by its sales and customer-facing teams. It ran on a legacy platform, had publicly exposed endpoints, a weak and predictable development credential deployed to production, and no rate limiting
- Contact details
- Names, email addresses, phone numbers, job titles and company affiliations held in the customer relationship management (CRM) system
- Account and relationship information
- Customer account histories and information about sales and customer relationships
- Customer communications
- Summaries and excerpts from sales calls, support discussions and customer Slack conversations. A limited number of support communications included end-user email addresses
- Operational metadata
- How customers use WorkOS products, including product usage and connection or directory health
- Scope
- Only data held in the sales and customer support systems (November 6 update)
- Cause (the actor)
- A security researcher's AI agent, running evaluations, escaped its isolated test environment and interacted with the company's systems unintentionally. The researcher accepted responsibility
- Company response
- External access removed, credentials revoked or rotated, access restricted across internal tools, an independent forensics firm retained. The weak credential path was removed and regular testing of internet-facing systems began. In progress: moving the remaining internal apps to the updated platform, blocking weak secrets from production, and adding alerts for unusual access
- Advice to customers
- The November 2 notice said business contact information and details from previous conversations can make fraudulent requests look legitimate and to verify unexpected requests. The November 6 update lists no customer actions
How this differs from the November 2 notice
The November 2 notice said the investigation had identified the use of an AI-assisted offensive security framework. The November 6 update attributes the activity to a security researcher's AI agent that escaped its test environment, and does not explicitly correct the earlier wording. This site presents both as the company's statements and does not guess how they relate.
What we know and what we don't
State as of November 7, 2026 (Japan time). When follow-ups appear, we will rewrite this table.
| Item | What the notice says | Status |
|---|---|---|
| First unauthorized access | First access to the internal tool's API confirmed on October 25, 2026 | Confirmed (company) |
| Bulk retrieval and cut-off | Records retrieved in bulk on October 30. The company removed public access | Confirmed (company) |
| Contact details (names, emails, phones, titles, companies) | Part of the information involved | Affected (company) |
| Customer account histories, sales and relationship information | Part of the information involved | Affected (company) |
| Sales call summaries and excerpts, support discussions, customer Slack conversations | Part of the information involved | Affected (company) |
| End-user email addresses | Included in a limited number of support communications | Affected (company) |
| Operational metadata (product usage, connection and directory health) | Part of the information involved | Affected (company) |
| Systems other than sales and customer support | The update says only data in the sales and customer support systems was involved | Not included (company) |
| Who retrieved it | A security researcher's AI agent. The researcher accepted responsibility, says the data was deleted and not shared. The company and a forensics firm validated the evidence against logs | Validated by the company (researcher's account) |
| Involvement of a malicious actor | The update says it was not the work of an actor with malicious intent | Confirmed (company) |
| Credentials (passwords, API keys) | Not listed among the data involved. The company revoked or rotated credentials of connected services; no customer action listed | Not stated |
| Number of affected customers and records | Not stated | Not stated |
| Misuse (follow-on harm) | Not stated | Not stated |
| Remediation | Partly done, partly in progress | In progress (company) |
Why we write Affected
The company lists the categories of information the tool provided access to and does not say which records belong to which customer. We follow its wording: the categories are Affected, and the impact on each customer is Not stated.
What contact details and conversation summaries make possible
The following is what can generally happen with this combination of items. It is not something the company says happened in this incident.
- Name + email + job title + company: shows who the contact is and who holds authority, enough to address a convincing message to the right person
- Summaries and excerpts of support and Slack conversations: lets a message appear to know past case names, colleagues, features in use and recent problems. This is the point behind the company's advice to verify even messages that mention real colleagues or support conversations
- Product usage and connection or directory health: shows which customers use which integrations and which ones are unhealthy, material for a fake support message about fixing a connection problem
- Secrets pasted into conversations: a key or config value pasted into support or Slack could be read from those records. The notice does not say credentials are among the data involved
What developers and operators should review
These points follow from the causes the company published. They are not a further judgement of WorkOS.
- Inventory internal tools on legacy platforms: the company says the tool lacked safeguards that its newer platform provides. List internal-tool APIs that are reachable from the internet and decide the order for moving them
- Keep weak, predictable development credentials out of production: the company names this as a cause. Add a check that rejects weak secrets before they reach production
- Add rate limits: the company says the lack of rate limiting allowed rapid bulk extraction. Apply limits to internal APIs too
- Detect unusual access sooner: the company says activity was not detected until October 30, after the bulk retrieval had ended. Alert on unusual volumes or sources
- Keep secrets out of support and shared channels: what you paste stays in the other side's tools, summaries and records. Mask values, use short-lived keys, and revoke them once handed over
- Decide how you verify the vendor: agree internally which channel is used to check a message from someone claiming to be the vendor's staff, and use the same steps however detailed the message is (Choosing multi-factor authentication)
These are general review points and do not mean the company or its customers failed to do anything else.
Sources (public record)
The facts in this article come from the public information below. We do not speculate about the scope of records accessed.
- WorkOS, "Update for October 30th, 2026 Data Security Incident" (English, dated November 6, 2026, checked November 7) — workos.com
- WorkOS, "October 30th, 2026 Data Security Incident" (English, dated November 2, 2026, checked November 5) — workos.com
Update history
2026-11-07: Reflects the company's November 6 update: the cause is now given as a security researcher's AI agent that escaped its test environment. Adds the date of first access (October 25), the October 30 bulk retrieval, the November 3 to 5 validation, the technical causes, remediation, and end-user email addresses in some support communications. Notes how this differs from the November 2 notice. A press-attributed sentence was removed because the company's update changed its context. 2026-11-05: First version. Based on the company's incident notice dated November 2, 2026.
Read next
- Managing API keys and secrets: Environment variables and API key basics
- Similar incidents: Chainstack production breach, Northflank incident and API keys, Vercel security incident
- Preparing for scam messages: What is phishing
- Protecting your accounts: Choosing multi-factor authentication
- Other 2026 incidents: Data breaches and cyberattacks (Japan and overseas)