Effect TypeScript Framework AsyncLocalStorage Context Contamination Vulnerability in Next.js App Router

A vulnerability exists in the Effect TypeScript framework, specifically in versions through 3.19.15, when used with Next.js App Router. The issue arises in the RPC server handling, where the Node.js AsyncLocalStorage context can be improperly shared between concurrent requests. This flaw allows an Effect fiber to access another request's context or none at all, leading to critical authentication errors. For instance, the auth() function from @clerk/nextjs/server may return a session for a different user under production traffic. The root cause lies in Effect's MixedScheduler, which batches and executes fiber continuations in a way that mismanages the AsyncLocalStorage context, especially during concurrent loads.

Impact

This vulnerability causes the auth() function to return incorrect user session data, creating an authentication bypass. Additionally, it allows Next.js's cookies() and headers() functions to read data from the wrong request, leading to potential data leakage. OpenTelemetry trace contexts can also be incorrectly shared between requests, causing tracing errors. Notably, this issue only appears under concurrent load in production environments, making it difficult to diagnose.

Reproduction

The vulnerability can be reproduced by sending two concurrent requests to a Next.js API route that uses Effect's RPC server handling. The first request will correctly set the AsyncLocalStorage context, but when the second request is processed, it will inherit the first request's context instead of its own. This can be verified by checking the user session data returned by the auth() function, which will incorrectly reflect the first request's user instead of the second's.

Remediation

Users can work around this vulnerability by capturing AsyncLocalStorage-dependent values before entering the Effect runtime and passing them through Effect's context system. For example, extract the user ID from the request headers using the auth() function before processing the request with Effect, and then inject this information into the Effect context or request headers for use within the Effect handlers.