CVE-2026-27971 is a critical unsafe deserialization flaw in the server$ RPC mechanism of the Qwik JavaScript framework. It scores 9.8 and lets an unauthenticated user run code on the server with one HTTP request. Qwik 1.19.0 and earlier are affected. Upgrade @builder.io/qwik to 1.19.1 or later.
What's affected
The GitHub advisory GHSA-p9x5-jp3h-96mm, published on 2 March 2026, lists the npm package @builder.io/qwik with affected versions 1.19.0 and below and patched version 1.19.1.
The advisory adds a condition: the flaw affects any deployment where require() is available at runtime. In practice that describes a typical Node.js server runtime. If you run Qwik purely as a static site with no server$ functions at runtime, your exposure is different, but confirm that against your build output rather than assuming it.
The advisory scores the issue 9.2 under CVSS v4 with network attack vector, low attack complexity, no privileges and no user interaction. NVD's CVSS v3.1 score is 9.8. Both land firmly in the critical range.
Qwik City and other packages in the Qwik family may be pinned separately in your project. The advisory names only @builder.io/qwik, so check the lockfile for that package and read the release notes for any companion packages you use.
How to check if you're exposed
List every place the package appears in your dependency tree.
npm ls @builder.io/qwik
If you use pnpm or yarn, run the equivalent command, for example pnpm why @builder.io/qwik. Look for any version at or below 1.19.0.
Next, search your source for server$ usage to see which routes expose RPC endpoints. A project with server$ calls on a Node runtime is the case the advisory describes.
Paste your package manifest or lockfile into the free in-browser dependency scan at gold.safeguard.sh/scan to see which of your projects pull in the affected package, including indirect dependencies.
What to do now
- Upgrade @builder.io/qwik to 1.19.1 or later and commit the updated lockfile.
- Rebuild and redeploy every environment that runs Qwik on a server, including preview and staging.
- If you cannot deploy today, put the service behind access controls or take it offline until you can. The advisory describes no configuration workaround, so check it for updates.
- Review access logs for unexpected POST requests to server$ endpoints around and after 2 March 2026. The advisory does not describe an indicator, so treat this as general hygiene, not detection.
- Add the package to your dependency monitoring so the next advisory reaches you the day it is published.
Why it matters
The weakness is CWE-502 (Deserialization of Untrusted Data). Serialization turns objects into text or bytes so they can travel between a browser and a server. Deserialization rebuilds the objects. If the rebuilt data can influence what the server executes, then whoever controls the request controls part of the program.
Qwik's server$ feature is built around calling server functions from client code, so deserialization sits on a public network path by design. The advisory says the flaw lets an unauthenticated user execute arbitrary code on the server with a single HTTP request. That combination, no login and one request, is why this scores as critical.
The record does not flag exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog. Even so, a public advisory for a one-request code execution bug in a web framework tends to attract scanning, so the useful posture is to patch before anyone has a reason to look at your servers.
A second lesson is about dependency visibility. A framework package is rarely in only one repository. Knowing which services run which version, and whether the vulnerable code path is actually reachable, is what turns a critical advisory into a short work list instead of an all-hands search. Reachability analysis helps here by showing whether your code calls the affected feature at all.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does a static Qwik site have this problem?
The advisory says the flaw affects deployments where require() is available at runtime and involves the server$ RPC mechanism. A purely static output with no server runtime is a different situation, but verify your own build before relying on that.
Which version fixes it?
1.19.1 of @builder.io/qwik. Versions up to and including 1.19.0 are affected.
Is it being exploited?
The record does not say so and CISA's catalog does not list it. That can change, so patch now.
Sources
Last reviewed: 19 October 2026.
