GHSA-h8vw-ph9r-xpch
CRITICALqui CORS Misconfiguration: Arbitrary Origins Trusted
EPSS Exploitation Probability
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.
Blast Radius
github.com/autobrr/quiReal-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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/autobrr/qui | all versions | 1.15.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/autobrr/qui. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-h8vw-ph9r-xpch is resolved across your whole dependency graph.
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.
How O3 protects you
O3 pinpoints whether GHSA-h8vw-ph9r-xpch is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-h8vw-ph9r-xpch. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-h8vw-ph9r-xpch in your dependencies?
O3 detects GHSA-h8vw-ph9r-xpch across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.