Where
-Infinity
0
Severity
8.8
Command Injection
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Impact Starting with qutebrowser v1.7.0, the Windows installer for qutebrowser registers it as a handler for certain URL schemes. With some applications such as Outlook Desktop, opening a specially crafted URL can lead to argument injection, allowing execution of qutebrowser commands, which in turn allows arbitrary code execution via commands such as :spawn or :debug-pyeval.

Only Windows installs where qutebrowser is registered as URL handler are affected. It does not have to be set as default browser for the exploit to work.

Patches The issue has been fixed in qutebrowser v2.4.0 in commit 8f46ba3f6dc7b18375f7aa63c48a1fe461190430.

The fix also adds additional hardening for potential similar issues on Linux (by adding the new --untrusted-args flag to the .desktop file), though no such vulnerabilities are known.

Backported patches for older versions are available, but no further releases are planned:

- v1.7.x: d1ceaab - v1.8.x: ca7155d - v1.9.x: 157d871 - v1.10.x: 94a6125 - v1.11.x: 10acfbb - v1.12.x: 363a18f - v1.13.x: 410f262 - v1.14.x: e4f4d93 - v2.0.x: 15a1654 - v2.1.x: 509ddf2 - v2.2.x: 03dcba5 - v2.3.x: 00a694c

(commits are referring to qutebrowser/qutebrowser on GitHub)

Workarounds Remove qutebrowser from the default browser settings entirely, so that it does not handle any kind of URLs. Make sure to remove all handlers, including an (accidental) qutebrowserURL handler, e.g. using NirSoft URLProtocolView.

Timeline 2021-10-15: Issue reported via security@qutebrowser.org by Ping Fan (Zetta) Ke of Valkyrie-X Security Research Group (VXRL) 2021-10-15: Issue confirmed by @The-Compiler (lead developer), author of installer (@bitraid) contacted for help/review 2021-10-15: CVE assigned by GitHub 2021-10-15 to 2021-10-17: Fix developed 2021-10-17: Additional core developer (@toofar) contacted for help/review 2021-10-21: v2.4.0 released containing the fix 2021-10-21: Advisory and fix published

References See the commit message for additional information and references to various similar issues in other projects.

Acknowledgements Thanks to Ping Fan (Zetta) Ke of Valkyrie-X Security Research Group (VXRL/@vxresearch) for finding and responsibly disclosing this issue.

Contact If you have any questions or comments about this advisory, please email security@qutebrowser.org.

1 / 2
Source: GitHub
First published (updated )
Severity
6.1
XSS
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

qutebrowser version introduced in v0.11.0 (1179ee7a937fb31414d77d9970bac21095358449) contains a Cross Site Scripting (XSS) vulnerability in history command, qute://history page that can result in Via injected JavaScript code, a website can steal the user's browsing history. This attack appear to be exploitable via the victim must open a page with a specially crafted <title> attribute, and then open the qute://history site via the :history command. This vulnerability appears to have been fixed in fixed in v1.3.3 (4c9360237f186681b1e3f2a0f30c45161cf405c7, to be released today) and v1.4.0 (5a7869f2feaa346853d2a85413d6527c87ef0d9f, released later this week).

1 / 2
First published (updated )
Severity
4.3
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N

Description

After a certificate error was overridden by the user, qutebrowser displays the URL as yellow (colors.statusbar.url.warn.fg). However, when the affected website was subsequently loaded again, the URL was mistakenly displayed as green (colors.statusbar.url.successhttps). While the user already has seen a certificate error prompt at this point (or set content.sslstrict to false which is not recommended), this could still provide a false sense of security.

Affected versions and patches

All versions of qutebrowser are believed to be affected, though versions before v0.11.x couldn't be tested.

The issue is fixed in qutebrowser v1.11.1 (pending release) and v1.12.0 (unreleased). Backported patches for older versions are available, but no further releases are planned.

Mitigation

If you are unable to upgrade:

- Treat any host with a certificate exception as insecure, ignoring the URL color - Or set content.sslstrict to True (instead of 'ask'), preventing certificate exceptions

References

- qutebrowser issue: https://github.com/qutebrowser/qutebrowser/issues/5403 - Fix (master branch): https://github.com/qutebrowser/qutebrowser/commit/021ab572a319ca3db5907a33a59774f502b3b975 - Related issue for KDE Falkon: https://bugs.kde.org/showbug.cgi?id=420902 - Related issue for eric6 Web Browser: https://tracker.die-offenbachs.homelinux.org/eric/issue328 (fixed in eric6 20.6)

1 / 2
Source: GitHub
First published (updated )
Severity
9.3
CSRF
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

qutebrowser before version 1.4.1 is vulnerable to a cross-site request forgery flaw that allows websites to access 'qute://' URLs. A malicious website could exploit this to load a 'qute://settings/set' URL, which then sets 'editor.command' to a bash script, resulting in arbitrary code execution.

1 / 2
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203