QSB-119: Potential attacker-controlled format string in qvm-open-in-vm
https://www.qubes-os.org/news/2026/09/15/qsb-119/

We have published Qubes Security Bulletin (QSB) 119: Potential attacker-controlled format string in qvm-open-in-vm (https://github.com/QubesOS/qubes-secpack/blob/2504a9d8fe7979eadaa933359da0981a3c14a7de/QSBs/qsb-119-2026.txt). The text of this QSB and its accompanying cryptographic signatures are reproduced below, followed by a general explanation of this announcement and authentication instructions.

Qubes Security Bulletin 119


---===[ Qubes Security Bulletin 119 ]===---

2026-09-15

Potential attacker-controlled format string in qvm-open-in-vm

User action
------------

Continue to update normally [1] in order to receive the security updates
described in the "Patching" section below. No other user action is
required in response to this QSB.

Summary
--------

Under certain circumstances (see "Technical details" below), if the user
invokes qvm-open-in-vm (either directly or through the "Edit in
disposable qube" GUI integration) on a file with an attacker-controlled
filename or path, the attacker might be able to execute code in the qube
in which the user invoked qvm-open-in-vm.

Impact
-------

An attacker who successfully exploits this vulnerability can take
control over the qube in which the user invoked qvm-open-in-vm.

Affected systems
-----------------

All supported Qubes OS releases are affected. Among official Qubes OS
templates, only Debian templates are affected.

Technical details
------------------

When qvm-open-in-vm is invoked with a file (not an URI), the source-side
part of the qrexec call is handled by the qopen-in-vm helper program.
After sending the file content to the other side, qopen-in-vm tries to
open a temporary file alongside the original file in order to save the
response in case the user has edited the file in the target qube. If
creating this file fails (e.g., because the directory is read-only),
qopen-in-vm creates a temporary file in /tmp and shows an error message
to the user. When printing this error message, it incorrectly invokes
the gui_nonfatal function, such that the original filename ends up in a
printf format string, which is unsafe.

For this vulnerability to be exploitable, multiple conditions must be
fulfilled:

1. The attacker must trick the user into using qvm-open-in-vm to open a
file that either
a. has a filename (i.e., the last component of the file's path)
longer than 248 bytes or
b. is located in a directory that is not writable.

2. The path (but not necessarily its last component) must
contain printf-style conversion specifiers (such as '%n').

3. qvm-open-in-vm must not have been invoked with the --view-only flag.

4. The target qube must either
a. send back the file content because its mtime changed (which
usually happens because the user saved the file being edited,
even if merely by overwriting it with the same content) or
b. be compromised by the attacker.

5. The build of qvm-open-in-vm must have been compiled without
_FORTIFY_SOURCE hardening enabled (or set to a level below 2). Due
to an unfortunate interaction between our build script and the way
Debian handles this option, this hardening was not enabled for our
Debian packages. (This problem did not affect our Fedora packages,
for which the hardening was correctly enabled.) With enabled
hardening, the program safely aborts with an error, making the bug
unexploitable.

The first person to report this vulnerability tested its exploitability
on his system. He found that it was successfully exploited in less than
3 % of attempts. Moreover, his demonstration required a very long path
with multiple nested directories and that contained many format
specifiers. In the real world, the attacker may control only the last