CVE-2026-30924

The application implements an HTML5 cross-origin resource sharing (CORS) policy that allows access from any domain.

While the application is typically deployed within a trusted local network, successful exploitation of this weakness does not require any direct access to the instance by the attacker. Exploitation of this vulnerability uses the victim's browser as a conduit for interaction with the application.

The mechanism used is a malicious webpage that requests from or posts to sensitive application paths upon load. This may be made transparent to the user, and harvested data may be sent back to the attacker upon success.

Cause and Remedy

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://example.com

The above response headers are responsible for the vulnerability. Access-Control-Allow-Origin was found to reflect arbitrary origins, implementing an effective blanket whitelist. Additionally, Access-Control-Allow-Credentials was returned as true, indicating to the browser that the loaded resource was permitted to leverage saved session information.

Correction of these values remediate the vulnerability. Defaulting to deny, with the configuration option to revert, should have no impact on the typical downstream user.

Conditions

AT:P is set due to the prerequisite that the application not be accessed via localhost or 127.0.0.1, as many modern browsers now have additional layers of protection for external->internal cross-origin requests. Some browsers may be impacted, but the likelihood is reduced. Users that access via any other domain or IP address are impacted.

UI:P is set due to the requirement that a malicious webpage be loaded by the browser, whether that be by way of a typo-squatted domain, malicious application, social engineering, or otherwise. Some services may automatically load webpages upon receipt in order to render a preview (i.e. certain IRC clients or other web apps used for communications), leading to an edge case where exploitation may sometimes occur without any intentional interaction by the user.

Knowledge of the target hostname is required, which may be obtained through various forms of enumeration or social engineering.

Mitigation in lieu of update

Users who use a unique hostname, do not provide that hostname to untrusted persons or services, run a containerized instance, do not click on or automatically load untrusted webpages, and do not expose their instance to the greater internet for simplified discovery and attribution, have already reduced their exposure significantly. These mitigating factors already apply to most users. Simply signing out after use can reduce this exposure even further.

Due to the conditions under which successful exploitation can occur, we do not expect to see regular exploitation of this item in the wild outside of highly targeted attacks reliant on the use of social engineering.

Any action that can taken by a user can be carried out by an attacker via a malicious webpage. The scope of this vulnerability varies from sensitive data exfiltration (account credentials) to a complete takeover of the underlying system (deployment dependent).

The application connects to and authenticates with several outside websites and related services. Successful exploitation of this vulnerability may lead to the exposure of certain credentials saved by the application to the attacker (such as passkeys or API keys). This exposure may lead to possible compromise of user accounts on connected websites and services. Some accounts are once-per-lifetime and compromise or abuse may lead to permanent loss of access.

Additionally, due to the built-in External Programs manager, successful exploitation of this vulnerability may lead to a compromise of the underlying system, including possible callbacks to an attacker-controlled server or established c2. Successful exploitation of this mechanism leads to a compromise of the host or container, depending on if the installation is native or containerized, in the user-context of the application (often root/privileged).

This exposure can occur without alerting the user. Certain actions may be logged by the qui log service, but removal of these log entries may be possible following a compromise of the host or container.

CVE-2026-30924 has a CVSS score of 9.6 (Critical). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.15.0); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-30924? CVE-2026-30924 is a critical-severity security vulnerability in github.com/autobrr/qui (go), affecting versions < 1.15.0. It is fixed in 1.15.0.
2. How severe is CVE-2026-30924? CVE-2026-30924 has a CVSS score of 9.6 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/autobrr/qui are affected by CVE-2026-30924? github.com/autobrr/qui (go) versions < 1.15.0 is affected.
4. Is there a fix for CVE-2026-30924? Yes. CVE-2026-30924 is fixed in 1.15.0. Upgrade to this version or later.
5. Is CVE-2026-30924 exploitable, and should I be worried? Whether CVE-2026-30924 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-30924 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-30924? Upgrade github.com/autobrr/qui to 1.15.0 or later.