CVE-2025-64762 affects the WorkOS AuthKit library for Next.js, version 2.11.0 and below. Authenticated responses did not carry anti-caching headers, so a CDN could cache session tokens and serve them to other users. The record scores it 9.1 critical, the advisory says high. Upgrade to 2.11.1.
What's affected
The npm package @workos-inc/authkit-nextjs is affected in versions 2.11.0 and below. Version 2.11.1 is the patched release, and it applies anti-caching headers to all responses behind authentication.
The risk depends on how the app is deployed. The advisory says Next.js applications deployed on Vercel are unaffected unless the team manually enables CDN caching by setting cache headers on authenticated paths. In other environments where a CDN caches responses, session tokens could end up in cached responses and be served to several users.
On severity, the record gives a CVSS 3.1 score of 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), which is Critical. The GitHub advisory labels the same issue High and notes the severity depends on deployment configuration, caching policy and whether authenticated routes are inadvertently cached. Both are fair readings of the same flaw.
How to check if you're exposed
First check which version your project uses:
npm ls @workos-inc/authkit-nextjs
Then check what your CDN does with authenticated pages. Request a protected path with a valid session and inspect the response headers, then compare with what your CDN reports:
curl -sI https://your-app.example/protected-path -H "Cookie: <your session cookie>" | grep -i -E "cache-control|age|x-cache"
An authenticated response should tell shared caches not to store it. If you see a public cache directive, or a header that shows the CDN served a stored copy, treat it as a problem even after you upgrade. Also review any custom cache rules you wrote for authenticated routes, since the advisory warns that headers can be overwritten elsewhere in an application.
What to do now
- Upgrade @workos-inc/authkit-nextjs to 2.11.1 or later and redeploy.
- Review middleware, application code and CDN configuration so that Cache-Control on authenticated paths prevents shared caching.
- Purge CDN caches for any authenticated paths that may have been stored.
- If an affected version ran behind a caching CDN, consider ending active sessions so that tokens that might have been cached are no longer valid.
- Do not let user-specific data appear in responses for paths that you do want cached.
Why it matters
This is a use of a cache containing sensitive information (CWE-524). Nothing here is a bug in cryptography or in the login flow itself. It is a missing header. A response that carries a session token must never be stored by a shared cache, and the library is the best place to guarantee that, because app authors rarely think about it.
The advisory is candid that headers set by middleware are defense in depth and cannot be guaranteed if other code overwrites them. That is useful advice for every team. Test the behavior at the edge, not only in code. The record does not say this flaw was exploited in the wild, and the KEV flag is false. The free Safeguard dependency scan can list the packages in a project and flag known CVEs, and the Gold directory keeps a page for each one.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
I deploy on Vercel. Am I affected?
The advisory says Vercel deployments are unaffected unless you manually enabled CDN caching with cache headers on authenticated paths. Upgrading is still the right move.
Does upgrading remove the need to check my CDN?
No. The patch adds anti-caching headers, but your own configuration can still override them. Verify the headers your CDN actually sends.
Sources
Last reviewed: 18 October 2026.
