Qwik City présente un contournement de la protection CSRF via la validation de l'en-tête Content-Type

The core of the vulnerability lies in how Qwik City handles HTTP request headers. Specifically, it inconsistently interprets Content-Type headers, allowing attackers to craft malicious requests with malformed or multi-valued headers. Successful exploitation bypasses Origin-based CSRF checks, enabling attackers to submit unauthorized requests on behalf of authenticated users. This could lead to unauthorized data modification, account takeover, or other actions depending on the application's functionality. The attack's success hinges on the application accepting cross-origin requests or being accessed via non-browser clients where CORS preflight succeeds. While requiring a successful CORS preflight, the potential impact remains significant, especially in applications with sensitive data or critical operations.

Applications built with @builder.io/qwik-city that accept user input via forms and permit cross-origin requests are particularly at risk. Shared hosting environments where multiple applications share the same server and resources could also be affected, as a compromised application could potentially impact others.

• nodejs / server:

  ps aux | grep qwik-city
  find / -name "@builder.io/qwik-city*" -type d

• generic web:

  curl -I https://your-app.com/some-form | grep Content-Type

• generic web: Review access logs for requests with unusual or multi-valued Content-Type headers.

1. 2026-02-03Disclosure

   disclosure

1. Réservé2026-01-29
2. Publiée2026-02-03
3. Modifiée2026-02-04
4. EPSS mis à jour2026-03-23

The primary mitigation is to upgrade to @builder.io/qwik-city version 1.19.0 or later, which addresses the header parsing issue. If immediate upgrading is not feasible, consider implementing stricter Content-Type validation on the server-side to reject malformed or multi-valued headers. WAF rules can be configured to block requests with suspicious Content-Type headers. Additionally, ensure that CORS policies are configured to restrict cross-origin requests where possible, limiting the attack surface. Review and strengthen existing CSRF protection mechanisms to provide an additional layer of defense.