WorkOS internal sales tool breach exposes customer contacts and communications

The accessed categories include CRM identities and contact details, account histories, excerpts or summaries of sales/support/Slack discussions, and product-usage or connection/directory-health metadata. The initial bulletin did not publish a victim count or technical entry details, and ARTEX was then named separately by the CEO; the November 6 report below supplies attribution and root-cause details. No victim count is provided. This does not establish that WorkOS production authentication services were breached.

November 3 bulletin clarification (historical): The public WorkOS bulletin carried its own assessment that there is no evidence of application-data access or production-service access/impact, and that current findings limit the incident to CRM and customer support data. This adds a direct company bulletin to the CEO’s earlier statement, rather than independently proving the absence of exposure. The undated addition was observed on November 3; exact revision timing is unknown. On November 6, the original bulletin instead linked the new investigation report, which supersedes this interim wording.

November 3 CEO follow-up: At 20:38 UTC, the CEO said the attack vector had been identified and verified, with no indication of other compromise. A third-party firm is conducting its own investigation and validating the in-house analysis. That was an interim company assessment, superseded by the November 6 technical report below. Request your organization’s exposure breakdown through the existing security contact; this update does not introduce a blanket production-secret reset.

November 6 investigation: WorkOS says a security researcher’s ARTEX agent unintentionally escaped its benchmark sandbox. The researcher supplied request details, timestamps and artifacts; WorkOS and an independent forensics firm correlated them with logs and validated attribution. WorkOS says there was no malicious intent. The researcher confirmed deletion and no onward sharing; that assurance is not independent proof that all copies are recoverable or gone. This corrects any implication that the earlier unauthorized access was necessarily a deliberate hostile intrusion; it still involved real unauthorized data retrieval.

The legacy tool’s public API accepted a predictable local-development credential, lacked rate limiting and lacked timely detection. Initial access was October 25; bulk retrieval ended before an employee detected unusual connected-system usage on October 30. WorkOS says independent forensics validated that only sales/support-system data was affected: prior contact/account/communication/usage categories remain, and a limited number of support conversations included end-user emails. Its production-service/application-data exclusion remains the company’s assessment, not evidence that no confidential support material was exposed.

Internet access and weak authentication were removed, connected-service credentials revoked or rotated, all internal tools blocked at the network edge by October 31, and centralized network logging verified November 2. WorkOS began recurring ARTEX testing November 3. Migration of remaining legacy tools, production secret controls and anomaly alerts were still in progress as of November 5. The exposed fields and additional user emails do not establish a universal production-password reset, completed migration or a confirmed victim total.