Server Functions as Unintended API Endpoints
In RedwoodSDK — a server-first React framework built on Cloudflare Workers — server functions exported from 'use server' files could be invoked via HTTP GET requests. This is a design flaw, not a code bug. Functions intended for POST-only state changes were accessible through any GET request: link clicks, browser prefetch, search engine crawlers, bookmark syncs. A function that deletes a record or modifies user state could be triggered by a browser's speculative prefetch without any user intent.
The CISA Vulnerability Summary for the week of June 2, 2026 included this issue in its bulletin. RedwoodSDK has since patched the flaw. But the architectural lesson extends beyond one framework: when server functions are exposed as URL endpoints — which is the fundamental mechanism of React Server Components — every exported function is an API endpoint whether the developer intended it or not.
The React Server Components Architecture
React Server Components introduced a new programming model: developers write functions in files marked 'use server,' and the framework handles serialization, transport, and invocation. The developer writes what appears to be a local function call. The framework converts it into an HTTP request. This abstraction is the value proposition of RSC — it eliminates the boilerplate of building API endpoints manually.
The abstraction is also the vulnerability surface. When the framework converts a function into an HTTP endpoint, it must enforce the constraints that the developer assumed but did not explicitly specify. Which HTTP methods are allowed? What authentication is required? Can the endpoint be invoked by a browser's navigation prefetch? In RedwoodSDK's case, the framework did not enforce method restrictions. The function was an endpoint. The endpoint accepted GET. The developer never saw an endpoint — they saw a function.
The Pattern Extends Beyond RedwoodSDK
RedwoodSDK is not the only framework implementing React Server Components. Next.js 13 and later versions use the same 'use server' directive. Vercel separately patched CVE-2026-23869 — a denial-of-service vulnerability in Next.js's RSC deserialization layer — in the same timeframe. Two RSC frameworks, two distinct vulnerability classes, in the same month. The common thread is the architectural pattern: converting developer-authored functions into HTTP endpoints creates an attack surface that the developer does not directly control.
What the Developer Sees vs. What the Attacker Sees
The developer sees a function with 'use server' at the top of the file. They call it from a client component. The mental model is a function call — input goes in, output comes back. The attacker sees an HTTP endpoint. They send a GET request. They send malformed input. They send requests without authentication. They send requests from automated tools. The gap between the developer's mental model and the attacker's operational model is the vulnerability surface that RSC frameworks must close.
For organizations building on React Server Components — whether through Next.js, RedwoodSDK, or emerging RSC frameworks — the RedwoodSDK flaw is a concrete audit item. Review every 'use server' export. Verify that the framework enforces POST-only access for state-changing functions. Verify that authentication is applied at the framework level, not assumed by the developer. The abstraction that makes RSC productive is the same abstraction that, when implemented incorrectly, makes every server function a public API endpoint accessible via browser navigation.
