CVE-2026-106101 in Quasar
Summary
by MITRE • 10/06/2026
Quasar Framework is a framework for building high-performance Vue.js user interfaces. Prior to 2.32.2, the openURL() utility in ui/src/utils/open-url/open-url.js trusted window.SafariViewController whenever that global existed in an iOS environment. Attacker-controlled HTML rendered by components such as QEditor can create a named SafariViewController element, causing browser named-property resolution to replace the expected native bridge object. A later openURL() call then invokes isAvailable() on the element, throws a TypeError, and disrupts external navigation, login redirects, payment redirects, and other URL-opening workflows. QSelect and QChatMessage HTML-rendering configurations can expose the same trigger when they render attacker-controlled HTML. This issue is fixed in version 2.32.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Quasar Framework serves as a robust tool for developing high-performance user interfaces using Vue.js, but prior to version 2.32.2, it contained a significant security flaw within its openURL utility located in ui/src/utils/open-url/open-url.js. This vulnerability stems from an insecure trust relationship with the window.SafariViewController global object when operating within iOS environments. The core technical issue arises because the framework relied on named-property resolution to access this specific browser bridge object without sufficient validation of its type or origin. In modern web browsers, particularly those adhering to HTML5 standards, accessing a property by name can resolve to an element with that ID if no direct global variable exists or is overridden. This behavior creates a potential attack vector where attacker-controlled content can manipulate the execution context of legitimate framework functions.
The operational impact of this vulnerability becomes apparent when components capable of rendering arbitrary HTML are utilized in conjunction with untrusted input sources. Specifically, components such as QEditor and configurations for QSelect and QChatMessage that allow HTML rendering can be exploited to inject a malicious element named SafariViewController into the DOM. When an attacker controls the content rendered by these components, they can insert this specific element which shadows or replaces the expected native bridge object provided by the iOS browser environment. Consequently, when the openURL function is subsequently invoked for legitimate purposes such as external navigation, login redirects, or payment processing workflows, it attempts to interact with the injected DOM element rather than the intended SafariViewController API.
This substitution leads to a critical runtime failure where the framework calls methods like isAvailable on the wrong object type. Since the injected element does not possess the expected properties of the native bridge, the application throws a TypeError exception. This crash effectively disrupts all URL-opening workflows that depend on this utility function. For applications handling sensitive operations such as authentication flows or financial transactions via redirects, this disruption can lead to service denial for legitimate users and potentially expose the application state during error handling phases. The vulnerability is classified under CWE-94 Improper Control of Generation of Code (Code Injection) due to the injection of DOM elements that alter script execution context, and it aligns with ATT&CK techniques related to client-side code injection and browser-based attacks such as T1059 Command and Scripting Interpretation via JavaScript.
The resolution for this issue was implemented in version 2.32.2 by hardening the openURL utility to strictly validate the type of object being accessed before invoking methods on it. Developers upgrading from earlier versions should ensure they apply this patch immediately if their applications utilize QEditor, QSelect with HTML rendering enabled, or QChatMessage components that process user-supplied content. Additionally, implementing Content Security Policy headers can provide an additional layer of defense by restricting the sources from which scripts and DOM elements are loaded, thereby mitigating similar injection-based attacks in other parts of the application stack.