WORKOS · Vendor
NO FIX YET · SEE WHAT TO DO
A configuration cleanup at WorkOS disabled an edge header rule, so server-action form POSTs on a small set of legacy AuthKit custom domains returned HTTP 500 for about 80 minutes on September 9, 2026. The sources report no unauthorized access, data exposure, or data corruption.
first public Sep 9, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Only AuthKit custom domains still carrying the legacy per-domain header configuration were affected, about 0.17% of custom-domain traffic and roughly sixteen hostnames with material volume. Default authkit.app domains, the WorkOS API, the Dashboard and GET requests continued to work. The incident is resolved; the sources say the affected cohort is a subset of domains from an earlier provisioning path.
Not affected if default-authkit-domain, managed-hosting, no-custom-domain
Who cares authkit, custom-domains, security, sign-in, workos
We're sorry for the disruption this incident caused for you and your users. Authentication is a critical path, and during this window we did not meet the reliability standard you expect from WorkOS. We take responsibility for the impact. Service was restored the same day, and we have already shipped several lasting fixes while continuing broader cleanup and detection work.
Date: September 9, 2026
Duration: 21:09 – 22:30 UTC (~80 minutes of customer impact)
Status: Resolved
On September 9, 2026, from approximately 21:09 to 22:30 UTC, a small subset of customers using AuthKit custom domains experienced failures when submitting authentication forms (sign-in, sign-up, MFA verification, device authorization, and email verification). Users on affected domains saw HTTP 500 errors on those form submissions, which blocked interactive login for the duration of the incident.
This was a partial outage. It affected a small cohort of AuthKit custom domains provisioned through an earlier self-serve configuration path—about 0.17% of AuthKit custom-domain traffic was actually affected by the failure. Default AuthKit domains (*.authkit.app), the WorkOS API, the Dashboard, and GET requests (page loads and most OAuth callback traffic) on custom domains continued to work. The failure mode was specific to server-action POST requests used by AuthKit hosted UI forms.
We first learned of the issue from a customer report at approximately 22:04 UTC (~55 minutes after impact began). Engineering restored service by 22:30 UTC. No evidence of unauthorized access, data exposure, or data corruption was found.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
AuthKit can be hosted on a customer’s own hostname (a custom domain). Traffic for those hostnames is terminated at our edge and forwarded to the AuthKit application with HTTP headers that identify the original host and browser origin. The AuthKit application relies on those headers so that browser security checks for interactive form submissions (Next.js server actions) succeed.
Over time, WorkOS evolved how custom-domain traffic is routed at the edge—from earlier per-domain configuration toward shared, list-based edge rules and a newer application hosting path. During that migration, a set of legacy per-domain header rules remained in place for domains created in an earlier era. A later zone-wide edge rule normally overwrote those headers so the application always saw a consistent, CSRF-safe origin. While that zone-wide rule was enabled, the older per-domain rules appeared inert.
As part of decommissioning older edge configuration no longer needed for the current hosting path, the zone-wide header transform rule was disabled in production. That change unmasked the leftover per-domain rules for the older custom-domain cohort.
For those domains, the edge continued to rewrite the browser Origin header to the tenant’s default AuthKit hostname, while the application still received the customer’s custom hostname as the forwarded host. AuthKit’s application layer correctly rejected the mismatched server-action POSTs as invalid (CSRF / same-origin protection), returning HTTP 500 before application business logic ran.
Scope
Symptoms
What went wrong
The proximate trigger was disabling a shared edge header rule that had been silently correcting residual per-domain header rewrites left over from an earlier custom-domain design. The durable underlying condition was incomplete cleanup of that legacy configuration after the supported path moved to list-based rules—and the absence of automated detection for this failure shape.
Why it wasn’t caught sooner
Several detection gaps stacked:
As a result, detection depended on customer reports rather than an automated page.
We treat restoring the shared transform as necessary containment, not the durable end state. The combination of residue removal, better probes, and better detection is intended to prevent both recurrence of this exact mechanism and silent customer-total failures on a small hostname set.
A configuration cleanup on the AuthKit custom-domain edge path exposed leftover rules from an earlier design and blocked interactive sign-in for a limited set of custom domains for about eighty minutes. We restored service quickly once the issue was identified, and we are following through so legacy edge residue cannot remain load-bearing, so validation covers the domains and request types that actually break, and so concentrated authentication failures are visible to us before they are visible only to your users.
We regret the impact on affected customers and their end users, and we appreciate the reports that helped us engage. If you have questions about whether your integration was in the affected cohort, please contact WorkOS support (support@workos.com).