Unauthenticated Request Can Crash Qwik Servers Before 1.20.0
A high-severity flaw in Qwik allows attackers to crash servers with one request. Fixes are available for specific npm packages.
Key points
- CVE-2026-84994 allows unauthenticated server crashes via HTTP request
- Qwik versions before 1.20.0 and beta versions before 37 are vulnerable
- Patches are available for both @builder.io/qwik and @qwik.dev/core
Managed service providers must update Qwik environments immediately. GitHub advisory GHSA-x586-xvc8-g7q6 details a high-severity vulnerability. The flaw affects server-side rendering components in default configurations. Attackers need no credentials to exploit this issue. A single HTTP request can terminate the Node.js process. This creates immediate availability risks for production web applications.
How it unfolded
- GitHub published advisory GHSA-x586-xvc8-g7q6 regarding the Qwik framework
- The advisory assigned CVE-2026-84994 to the unhandled rejection flaw
- Developers released patched versions 1.20.0 and 2.0.0-beta37 for npm
Who is affected
Organizations using npm package @builder.io/qwik below version 1.20.0 are vulnerable. Those using @qwik.dev/core below version 2.0.0-beta37 face the same risk. The issue occurs during qwik-json body parsing. The ResourceSerializer.$fill$ method calls Promise.resolve on a specific property. If that property is an object with a specific QRL structure, the system fails. The async QRL rejects because the symbol is unregistered. This rejection becomes orphaned within the application logic. Node.js then terminates the process using its default policy.
Our take on the response
The vendor provided clear version boundaries for the fix. Patching 1.20.0 resolves the issue for stable users. Beta users must update to at least 2.0.0-beta37. The advisory explains the technical mechanism clearly. It highlights how default configurations increase exposure. That suggests teams should audit their deployment settings. The rapid release of patches indicates a swift response. However, the ease of exploitation demands immediate action.
Who needs to act first
Teams should prioritize public-facing web servers running Qwik. Check which instances use default configurations first. These systems are most exposed to unauthenticated attacks. Roll out updates to edge nodes before internal services. Test the patch in a staging environment to ensure stability. Back up current deployments before applying changes. Monitor server logs for unexpected restarts during the update. Reduce exposure by restricting access if possible. Verify that all replicas receive the update simultaneously to prevent loops.
What to do and how to stay safe: Qwik
- Identify all servers running @builder.io/qwik below 1.20.0
- Update @qwik.dev/core to version 2.0.0-beta37 or later
- Monitor Node.js processes for unhandled rejection crashes
- Verify that default configurations are not exposing parsing endpoints
Step-by-step guide: Vulnerability Prioritization: How to Rank Risks Without Wasting Time
General security guidance from the Patch Observer newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
What is the CVE ID for this Qwik vulnerability?
The vulnerability is tracked as CVE-2026-84994.
Which specific npm packages are affected by this flaw?
The packages @builder.io/qwik and @qwik.dev/core are affected.
Is there a fix available for this issue?
Yes, patches are available in version 1.20.0 and 2.0.0-beta37.
