Server Actions blur the client-server line and juniors are paying for it

Nowadays, a 'use server' directive is one of the most dangerous lines in a Next.js app you could possibly write. The frontend dev who wrote it didn't realize they'd just published a public API endpoint, one that skips every check the rest of the app relies on. But no worries, that kind of miscommunication happens all the time in software development!

The line we all quietly stopped drawing. A wall stood in the past separating Frontend from Backend, with all the scary security work done on the Backend side. Authentication checks, input validation, rate limiting - while the wall may have been unsightly, it made it clear where the threat model lived. Server Actions deleted the wall.

The official Next.js docs now caution that "when a Server Action is created and exported, it is reachable via a direct POST request, not just through your application's UI." I suggest you read that one more time. Your cute little form handler becomes an open endpoint as soon as it is created.

"Some frontend framework code is backend code." Security researcher Sascha B. was blunt in his May 2026 analysis. If the RSC parser is slack on payload shape, "every component author who ever wrote a Server Action wrote, by accident, an unauthenticated RPC endpoint with no input validation." The abstraction served as a cover for the endpoint, yet the endpoint was always there.

Sascha went on to explain that previously, the frontend/backend split between trusted and untrusted code was based on different threat models. The code was separated into clients and servers. With Server Actions, the threat model was not on either side of the network but layered into the client component graph. In July 2026, Penligent, an AI security company, rephrased the sentence as: "It's not a frontend-calling backend security model; it's some frontend framework code that is backend code."

Now, the employee who was brought in to design beautiful buttons has to protect and maintain an RPC layer. But no one expected that when they joined the team.

The CVEs aren't hypothetical

This is not just a general feeling.

• CVE-2025-55182 (CVSS 10.0) let attackers get unauthenticated remote code execution by exploiting how React decoded payloads sent to Server Function endpoints. A perfect 10, disclosed December 2025 by Lachlan Davidson.
• CVE-2025-66478 was prototype pollution.
• On July 21, 2026 (originally scheduled for July 20), Next.js shipped scheduled security patches (v16.2.11 and v15.5.21) for more of them.
  • CVE-2026-64641 was a DoS via crafted requests burning CPU.
  • CVE-2026-64645 was straight-up server-side request forgery.

The pattern yells at you. A serialization protocol so permissive you didn't realize you were using it, hidden behind code that resembles UI glue.

Recorded Future essentially pointed out a harsh reality by mentioning that: "some percentage of Next.js developers using Server Actions are unaware that they're invoking a custom serialization protocol... The risk is invisible until it's exploited."

This is a design flaw, not a skill issue

It is a common and simple reaction to blame the less experienced person for the mistake. We might say "Well, they should have double-checked and validated all the inputs before shipping it." No, the responsibility lies with the abstraction if it is so easy that you may inadvertently expose an unauthenticated endpoint. Well-thought-out design should lead users to the safest options by default. In the case of Server Actions, unfortunately, it made risky choices appear unexciting.

Penligent's recommendation is the following: Do not pass database objects, ORM entities, session objects, or raw API responses directly to Client Components. That's real, useful guidance. It's also backend threat-modeling knowledge that most frontend devs were never trained on, now mandatory to avoid leaking secrets.

What I actually do about it

At my startup, we use a Next.js monorepo, and I am not getting rid of Server Actions because they are actually enjoyable to work on. However, we approach each action as if it were a public endpoint.

• Do an auth check right at the beginning.
• Validate the payload before doing anything else.
• Expect a direct POST, because it is.

The mental model that made everything clear: the frontend doesn't exist. There are UI code and endpoint code, and Server Actions are endpoints in a pretty frock.

Convenience is fantastic, except when it becomes the vulnerability.

🔥 Are we expecting individuals without the necessary backend training to take over backend responsibilities and show surprise when things don't turn out well?