DEV Community: 幻灵末士

How I Found an SSR Cache Isolation Failure in a React Data Fetching Library

幻灵末士 — Sat, 29 Aug 2026 16:36:52 +0000

There's a certain kind of bug that only shows up when you stop thinking about what code does and start thinking about when it does it.

Most security researchers spend their time asking "can an attacker make this code do something bad?" That's a fine question. But it misses an entire category of vulnerabilities that have nothing to do with malicious input. Sometimes the code does something bad all on its own, just because of how it's structured.

This is the story of one of those bugs.

The Setup

I was auditing a popular React data fetching library. You've probably used it or at least seen it in a Next.js project. It's the kind of library that handles caching, revalidation, and all the other unglamorous parts of making API calls from React components.

The library has a feature that's pretty common in the React ecosystem: it works differently depending on whether you're running on the client or the server. On the client, you want caching to persist across page navigations. On the server—during server-side rendering—each request should be completely isolated from every other request. That's Security 101 for SSR: if user A and user B both trigger a server render at the same time, neither should be able to see the other's data.

So I started asking a simple question: how does this library manage its cache during server-side rendering?

The Deep Dive

I traced the cache initialization back to its source. What I found was about as simple as it gets:

const [cache, mutate, , , unload] = initCache(new Map())

That's a module-level variable. A single Map object, created once, sitting at the top of a file. Every part of the library that needs a cache references this same object.

On the client, this makes total sense. You want one cache for the entire application. When the user navigates between pages, the cache persists. That's the whole point.

But on the server, module-level variables are dangerous. In a Node.js environment, modules are loaded once and shared across all incoming requests. That means this single cache Map is shared across every user who hits the server. Concurrently.

I looked for a mechanism that would provide request-scoped isolation by default. Some kind of AsyncLocalStorage wrapper, or a factory function that creates a fresh cache per request, or even a check that said "hey, you're in SSR mode, here's an isolated cache instead."

I didn't find one.

The "Oh No" Moment

Here's what the vulnerability looks like in practice. Imagine a Next.js application that uses this library to fetch user-specific data during server-side rendering. The component looks something like this:

function UserProfile() {
  const { data } = useSWR('/api/user-data', fetcher);
  return <div>Hello, {data.name}</div>;
}

The cache key is /api/user-data. It's the same for every user. The library uses this key to look up cached data before making a fetch request.

Now here's what happens when two users hit the server around the same time:

User A's request starts rendering. The library checks the global cache for /api/user-data. It's empty, so it fetches the data from the API and stores it in the cache. The cache now contains User A's data.
User B's request starts rendering a few milliseconds later. The library checks the global cache for /api/user-data. It finds User A's data sitting there. It uses it. No fetch needed.
User B's HTML response contains User A's name, email, or whatever else was in that cached payload.

No attacker needed. No malicious input. Just two users using the application at the same time, and the library's default behavior hands one user's data to another.

Why This Happens

The library does provide a way to isolate caches per request. There's a provider component that you can wrap your app in, and it creates a fresh cache scope. But it's opt-in. The default configuration doesn't do this.

And here's the thing about defaults: they're what most people use. If you're a developer integrating this library into your Next.js app, you'll probably follow the docs, use the default setup, and never realize that you're sharing cache state across all your users. The docs might mention the provider in passing, but unless you're specifically looking for SSR isolation concerns, you're not going to connect the dots.

This is one of those situations where the secure option exists but the insecure option is the default. And in security, defaults matter more than anything.

The Broader Pattern

This isn't unique to this particular library. Module-level mutable state in server-side JavaScript is a pattern that shows up everywhere. Any time a Node.js application shares a mutable variable across request boundaries, there's potential for data leakage.

The difference here is that this library is explicitly designed to work in SSR environments. It knows that server-side rendering means concurrent requests sharing the same module instances. And yet the default cache is still a module-level singleton.

I've seen this same pattern in other libraries too. A utility module that stores configuration in a top-level object. A logger that keeps a buffer in module scope. A session manager that initializes once and keeps state between requests. The details vary, but the underlying mistake is the same: assuming that "loaded once" means "safe to share."

What I Reported

I put together a proof of concept that demonstrated the issue clearly. The setup simulated three concurrent requests from three different users, all using the same cache key. The first user's data ended up being served to the second and third users.

The output was pretty damning:

[VULNERABILITY CONFIRMED]
  User B received User A private data from shared global cache!

[CRITICAL] User C received User A private data from polluted cache!

No elaborate exploit chain. No tricky timing attack. Just three requests happening in the normal course of application usage, and the library's default behavior leaking data between them.

The Fix

The fix has two parts. First, the library should use something like AsyncLocalStorage to provide request-scoped cache isolation on the server by default. Second, the documentation needs to be much more explicit about the risks of using the default configuration in SSR environments.

The first part is a code change. The second part is arguably harder—you can't fix a documentation gap with a patch, and you can't force developers to read the docs you've already written. The real fix is making the secure option the default, so developers don't have to opt in to safety.

What I Learned

Server-side module state is a liability. Every time you create a module-level mutable variable in a Node.js application, ask yourself: what happens when two requests access this at the same time? If the answer involves one request seeing another request's data, you have a problem.

Defaults define security posture. An opt-in security feature is not a security feature. If the safe configuration requires the developer to know about the danger and take action, most developers won't do it. Not because they don't care, but because they don't know.

Concurrency bugs are often invisible in development. If you're testing your app locally, you're probably making one request at a time. The cache never collides because there's nothing to collide with. The bug only shows up in production, under load, when multiple users happen to hit the same cache key at the same time. That's what makes this class of vulnerability so insidious—it's invisible until it's catastrophic.

Final Thoughts

I can't share the library name or the vendor's response yet—standard responsible disclosure practice. But the pattern is worth understanding regardless of which library it happened to be.

If you're building React applications with server-side rendering, go check your data fetching libraries. Look at how they manage cache state. If the cache is a module-level singleton and there's no obvious per-request isolation, you might be one concurrent request away from leaking user data.

And if you're on the security research side, don't just look for code that can be exploited. Look for code that behaves differently under concurrency than it does in isolation. Those bugs are harder to find, harder to trigger in development, and often far more damaging in production.

The best bugs aren't the ones that require a sophisticated attacker. They're the ones that happen all by themselves, in the normal course of things, while everyone assumes the code is working correctly.

How I Found an SSRF in an AI SDK's OAuth Metadata Discovery

幻灵末士 — Sat, 29 Aug 2026 07:14:55 +0000

Some bugs announce themselves. You're reading through a codebase and the vulnerability practically waves at you from the screen. This was not one of those bugs.

This one required me to ask a question that I almost didn't ask. And that question led down a rabbit hole that ended with a server-side request forgery in a fairly popular AI SDK.

The Context

I've been doing security reviews of AI-related tooling lately. Partly because it's obviously where the industry is heading, and partly because the pace of development in that space means security often takes a back seat. New features ship fast. Validation logic gets copy-pasted. Corners get cut.

The target this time was an SDK that handles authentication for something called MCP servers. If you're not familiar, MCP is a protocol that lets AI applications connect to external tools and data sources. Think of it as a standardized way for an AI assistant to talk to your calendar, your database, or your internal APIs.

The auth flow I was looking at involves OAuth. The SDK needs to discover where the OAuth endpoints live, so it makes a request to a well-known URL on the server and parses the metadata from the response. Pretty standard.

Here's where my curiosity kicked in.

The Question

I was reading through the OAuth implementation when I noticed something that seemed off. There was a function that validated URLs before fetching them. It was doing the right thing:

function assertSafeOAuthEndpoint(endpointUrl: URL): void {
  // ... some checks ...
  validateDownloadUrl(endpointUrl.href);
}

Good. That's the pattern I want to see. Someone thought about SSRF here and added a guard.

But then I kept scrolling. And I found another function that fetches URLs during the OAuth flow. It was responsible for discovering OAuth metadata—the part where the SDK asks the server "hey, where are your OAuth endpoints?"

That function did not call validateDownloadUrl.

I stared at it for a minute. Was that intentional? Did the metadata discovery path not need validation for some reason I wasn't seeing?

I pulled up the call chain. The public auth() API eventually calls discoverOAuthProtectedResourceMetadata(), which calls discoverMetadataWithFallback(), which calls tryMetadataDiscovery(), which calls fetch().

No validation anywhere in that chain.

And here's the thing: the URL being fetched comes from the user. When a developer sets up their MCP connection, they provide a serverUrl. The SDK takes that URL and starts making HTTP requests to it to discover OAuth metadata.

If an attacker can control that serverUrl—which is the entire threat model of "connecting to an untrusted MCP server"—then the SDK will happily fetch whatever URL you give it. Including internal addresses.

The "Wait, Really?" Moment

I didn't trust my initial read. So I built a test.

I wrote a small mock server that would listen on localhost and log any incoming requests. Then I pointed the SDK at it using its public API, passing in a serverUrl that should have been rejected if any validation existed.

The result: my mock server received the requests. The SDK connected to 127.0.0.1 without hesitation. It sent the standard OAuth discovery requests to my local service, complete with headers identifying itself.

That's when I realized this was actually a problem.

The validateDownloadUrl function existed in the codebase. The developers clearly knew they needed URL validation for OAuth endpoints. But they'd only applied it to one part of the flow—the part where credentials are submitted—and missed the metadata discovery path entirely.

What Could Go Wrong

Let me paint the picture.

A developer builds an application using this AI SDK. They configure it to connect to an MCP server. Maybe that server URL comes from a configuration file, a database, or even from a user-supplied value in their app. It doesn't really matter how. What matters is that the SDK trusts that URL completely.

An attacker who can influence that serverUrl can point it at:

169.254.169.254 — the AWS metadata service, which can leak IAM credentials
127.0.0.1:6379 — a local Redis instance
127.0.0.1:9200 — Elasticsearch
Any other internal service on the network

The SDK will send HTTP requests to those addresses from within whatever environment it's running in. If the application is deployed in a cloud environment with an attached IAM role, that's credential theft. If it's on a corporate network, that's internal reconnaissance.

And the attacker doesn't need any special privileges. They don't need to authenticate. They just need to convince a developer to connect to a malicious MCP server, which is exactly the scenario the OAuth flow is supposed to handle safely.

The Second Layer

While I was digging into this, I found something else that made it worse.

The fetch function used in the metadata discovery path had redirect: 'follow' enabled by default. That means even if someone added URL validation to the initial request, an attacker could potentially bypass it by having the initial URL redirect to an internal address.

The SDK would follow the redirect and end up at the internal service anyway.

This is a classic SSRF pattern: validate the first URL, forget that redirects can take you anywhere. The presence of redirect: 'follow' meant that fixing the missing validation on the initial URL wouldn't even be sufficient—the redirect behavior needed attention too.

The Fix

I reported the issue through the proper channels. The fix involved two parts: adding URL validation to the metadata discovery path, and addressing the redirect-follow behavior.

Simple in concept. But the fact that both layers existed—missing validation on one path, and redirect-follow on another—meant that a naive fix would have left the vulnerability half-open.

That's actually a lesson I keep learning in security research: the first bug you find is rarely the whole story. There's usually a second layer if you keep digging.

What I Learned

Consistency in security controls is hard. The developers had a validation function. They used it in one place. They didn't use it in another place that needed it just as much. This happens all the time, especially in codebases that are growing quickly. The security control wasn't missing—it was just incomplete.

Redirects are SSRF's best friend. If your URL validation doesn't account for redirects, it's not real validation. Fetch APIs follow redirects silently. An attacker who can control the response from a validated URL can redirect you anywhere.

Untrusted server URLs are an SSRF waiting to happen. If your application fetches URLs that a user or external party can influence, you need to think carefully about where those requests might end up. This is especially true in cloud environments where internal addresses can expose sensitive credentials.

Test your assumptions. I didn't just read the code and assume the missing validation was exploitable. I built a quick proof of concept that demonstrated the SDK making requests to a local service. If you're reporting a security issue, concrete evidence is worth a lot more than "I noticed something in the code."

Final Thoughts

I can't share specifics about the SDK or the vendor's response—that's between me and them for now. But the pattern here is worth understanding because it's everywhere.

SSRF via missing URL validation in OAuth flows. SSRF via redirect-follow. These aren't exotic bugs. They're the result of a simple oversight in a complex flow, hidden in the gap between two functions that were supposed to do the same thing but only one of them did.

If you're building anything that involves fetching URLs based on user input, go look at every fetch() call in your codebase right now. Not just the obvious ones. Every single one. Ask yourself: could this URL ever be influenced by someone other than the developer?

If the answer is yes, you might have an SSRF.

And if you're on the security research side, the next time you're reading through a codebase and something feels slightly off—a validation function used in one place but not another—don't just note it and move on. Dig in. That inconsistency might be the thread that unravels the whole thing.

How I Found a postMessage Origin Bypass in an OAuth SDK

幻灵末士 — Fri, 28 Aug 2026 14:33:30 +0000

I spend a lot of time reading other people's code. Not because I enjoy it—though honestly, I kind of do—but because that's where the interesting bugs live. Not the flashy ones that get all the attention on Twitter. The quiet ones. The ones hiding in plain sight, inside a single missing if statement.

This is the story of one of those bugs.

The Backstory

A few weeks ago I was doing a security review of a web3 project. You know the drill: connect wallet, sign in with Google, maybe an NFT drop if you're lucky. The usual.

The project used an OAuth SDK for their "Sign in with Google" flow. Pretty standard stuff. You click a button, a popup opens, you authenticate with Google, the popup closes, and you're logged in. Smooth UX, works great.

Under the hood, this flow relies on postMessage to communicate between the popup window and the main application window. And if you've done any web security work, you know where this is going.

postMessage is one of those APIs that's incredibly useful and incredibly easy to get wrong. The browser happily delivers messages between windows regardless of where they come from. It's up to you, the developer, to check event.origin and make sure you're only accepting messages from places you actually trust.

Spoiler alert: sometimes people forget.

The Hunt

I started by looking at how the SDK handled messages coming back from the OAuth popup. Here's roughly what I found:

const redirectEvent = (event: MessageEvent) => {
  this.createIntermediaryEvent(
    OAuthPopupEventEmit.PopupEvent,
    requestPayload.id
  )(event.data);
};

window.addEventListener('message', redirectEvent);

Take a good look at that. What's missing?

There's no event.origin check. No validation of where the message is coming from. The listener receives a message, grabs event.data, and forwards it along to be processed. It doesn't care if the message came from the legitimate OAuth popup, a malicious page, or the void.

This is the equivalent of answering your front door without looking through the peephole. Sure, it's probably your friend, but you're not even checking.

The Interesting Part

Now, a missing origin check is bad on its own. But I wanted to know: how bad? What can an attacker actually do with this?

The answer depended on how the SDK matches incoming messages to pending OAuth requests. And here's where it got interesting.

The SDK uses a payloadId to correlate popup messages with the original login request. When you initiate an OAuth flow, the SDK generates an ID, sends it along with the popup URL, and waits for a message that references that same ID.

I traced this ID generation back to its source, expecting to find a cryptographically secure random generator. Something with crypto.getRandomValues() or at least a timestamp mixed in. Instead, I found something much simpler:

let id = 0;
export const getPayloadId = () => ++id;

That's it. A module-level counter that increments by one every time it's called. On the web platform, every OAuth request gets the next integer in sequence. If you see request #7 go out, you know the next one will be #8.

Let me walk through how an attacker could chain this together. As soon as the victim's OAuth popup opens, the SDK registers its message listener. At that exact moment, the attacker's page—which the victim has open in another tab—can send a message via window.opener.postMessage(). That message includes a payloadId that the attacker predicted by simply counting the current request number. The listener, with no origin check, passes the message to the SDK's internal logic, which processes it as if it came from the legitimate Google popup. The attacker doesn't need to guess anything else.

That's what turned this from "interesting oddity" into "real exploit."

The Cherry on Top

While digging through this SDK's codebase, I noticed something that made me chuckle. The same company maintained another package in the same SDK family. That package did do the right thing:

if (event.origin !== this.endpoint) return;

They knew about origin validation. They'd done it correctly elsewhere. But in the OAuth extension, it was just... absent. A lapse in consistency between two codebases that should have followed the same pattern.

This is actually pretty common in larger codebases. Different teams, different timelines, different levels of review. Knowledge gets siloed. What one maintainer knows, another doesn't. And sometimes a critical check that exists in iframe-controller.ts never makes it to oauth2/src/index.ts.

The Fix

I reported the issue, and the fix was about as simple as you'd expect. Add the origin check, mirror the pattern that already existed elsewhere in their own codebase:

const redirectEvent = (event: MessageEvent) => {
  if (event.origin !== this.sdk.endpoint) return;
  this.createIntermediaryEvent(
    OAuthPopupEventEmit.PopupEvent,
    requestPayload.id
  )(event.data);
};

One line. That's it. One line separates "vulnerable" from "not vulnerable."

What I Learned (And You Should Too)

Always validate event.origin. I know, you've heard this a thousand times. But I just found a production SDK that forgot, so apparently we need to keep saying it. Never assume a message event comes from where you expect. Always check.

Predictable IDs are dangerous. Sequential IDs aren't just bad for enumeration attacks—they can enable cross-window attacks like this one. Use cryptographically random IDs when correlating async operations.

Consistency matters in security. If one part of your codebase does security right and another doesn't, that's not just an inconsistency. It's a roadmap for attackers. They'll find the weakest link.

Read code. I didn't find this with a scanner. I just opened the source code, traced the message flow, and followed it until something didn't add up. Sometimes the best tool is just a text editor and a willingness to ask "what if?"

Final Thoughts

I can't share specifics about the SDK or the exact details of my report—responsible disclosure means giving the vendor time to patch and publish their own advisory. But the pattern is what matters here. Missing origin validation is one of those bugs that shows up everywhere: SDKs, wallets, analytics tools, chat widgets. If your app uses postMessage anywhere, go check your listeners right now. I'll wait.

Seriously, go check.

The best bugs aren't always the ones with the most complex attack chains. Sometimes they're the ones hiding in the gap between what the code assumes and what the browser actually delivers.

Thanks for reading! If you enjoyed this, I write about web security, code review, and the occasional "how did that even work" bug. Follow along for more.