Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

CVE-2026-30924 qui

Fix: autobrr/qui@424f7a0

CVE-2026-30924 is a CWE-942 vulnerability in github.com/autobrr/qui. A fix is available for github.com/autobrr/qui — see the affected versions and patch details below.

qui CORS Misconfiguration: Arbitrary Origins Trusted

Also known asGHSA-h8vw-ph9r-xpchGO-2026-4774
Published
Mar 19, 2026
Updated
Aug 12, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-30924.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs18th percentile — riskier than 18% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Real-World Exposure

1 pkg affected
🐹github.com/autobrr/qui

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

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.

Impact

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.

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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/autobrr/quiall versions1.15.0go get github.com/autobrr/qui@v1.15.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/autobrr/qui, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/autobrr/qui to 1.15.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-30924 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-30924 can be triaged on real exposure rather than presence alone.

Tailored to CVE-2026-30924. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary 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
O3 Security · Impact-Aware SCA

Is CVE-2026-30924 in your dependencies?

O3 Security finds CVE-2026-30924 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

CVE-2026-30924: qui | O3 Security