Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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:…
Recommended action: Upgrade to 2.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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).
Recommended action: Upgrade to 1.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.