CVE-2026-49456 in Waku
Summary
by MITRE • 09/03/2026
Waku is the minimal React framework. Prior to version 1.0.0-beta.1, the unstable_redirect() helper exported from waku/router/server (packages/waku/src/router/define-router.tsx:156–161) accepts an arbitrary string and reflects it unchanged into the HTTP Location response header with no URL validation, scheme restriction, or path-only enforcement. Any application that passes user-controlled input to this helper — the natural pattern documented in the JSDoc and official fixtures — is vulnerable to open redirect attacks. An attacker who convinces a victim to click a crafted link can silently redirect the browser to an arbitrary external domain, enabling phishing, credential harvesting, and OAuth token theft. Additionally, scheme-relative URLs (//evil.example/) bypass naive https?://-only allow-list filters that developers might add as ad-hoc mitigations. This issue has been patched in version 1.0.0-beta.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified within the Waku framework prior to version 1.0.0-beta.1 represents a critical open redirect flaw rooted in insufficient input validation and sanitization mechanisms. Specifically, the unstable_redirect helper function exported from the waku/router/server module fails to enforce any constraints on the URL string provided by developers or end-users. Instead of validating that the input constitutes a safe, relative path within the application's own domain, the implementation accepts an arbitrary string and reflects it directly into the HTTP Location response header without modification. This design choice creates a direct pathway for attackers to manipulate browser navigation behavior, as the server blindly trusts the provided value regardless of its origin or structure. The lack of scheme restriction means that absolute URLs pointing to external domains are treated with the same validity as internal relative paths, fundamentally breaking the assumption that redirect targets remain within the trusted application context.
From a technical perspective, this flaw aligns closely with CWE-601, which describes URL Redirection to Untrusted Site or Domain. The vulnerability is exacerbated by the framework's documentation and official fixtures, which encourage passing user-controlled input directly into this helper function as part of standard development patterns. Consequently, any application built on Waku versions preceding 1.0.0-beta.1 that utilizes this pattern for handling navigation logic becomes inherently vulnerable. An attacker can exploit this by crafting a malicious link containing a URL with an external domain or a scheme-relative address such as //evil.example/. When a victim clicks this link, the browser receives the HTTP Location header pointing to the attacker-controlled destination and automatically redirects the user away from the legitimate application site. This mechanism allows for seamless navigation that appears authentic until the final page load occurs on the malicious server.
The operational impact of this vulnerability extends beyond simple misdirection, facilitating sophisticated social engineering attacks such as phishing and credential harvesting. By redirecting users to a visually similar but malicious replica of the login page or service interface, attackers can trick victims into submitting sensitive information like usernames, passwords, or multi-factor authentication codes. Furthermore, in applications utilizing OAuth flows for authentication, an open redirect vulnerability can be leveraged to steal authorization tokens. If the attacker controls the redirect URI parameter during the OAuth callback process, they may intercept access tokens that grant unauthorized entry to user accounts and associated data resources. The use of scheme-relative URLs further complicates mitigation efforts because many naive security filters rely on simple string matching for http or https prefixes; these filters fail to detect //evil.example/ as a malicious absolute URL, allowing the attack to bypass basic defensive coding practices implemented by developers attempting to secure their applications ad-hoc.
To mitigate this risk and prevent future occurrences of similar vulnerabilities, it is imperative that all redirect targets be validated against an allow-list of trusted domains or strictly enforced as relative paths starting with /. Developers should avoid passing user-controlled input directly into redirection functions without rigorous sanitization. The vulnerability has been addressed in Waku version 1.0.0-beta.1 through the implementation of proper URL validation logic that restricts redirects to safe, internal destinations only. Security practitioners and application developers are advised to upgrade immediately if they are running pre-1.0.0-beta.1 versions and to audit existing codebases for any instances where unstable_redirect is used with dynamic input. Additionally, implementing Content Security Policy headers can provide an additional layer of defense by restricting the domains from which content can be loaded or navigated to, thereby reducing the effectiveness of open redirect attacks even if other controls fail. This incident underscores the importance of treating all user-supplied data as untrusted and applying strict validation rules at every point where external influence enters the application logic.