QSB-111: xfce4-screensaver login bypass
QSB-111: xfce4-screensaver login bypass
We have published Qubes Security Bulletin (QSB) 111: xfce4-screensaver login bypass. 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 111
---===[ Qubes Security Bulletin 111 ]===---
2026-04-14
xfce4-screensaver login bypass
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
--------
When connecting or disconnecting a display or, in some cases, when simply
activating the xfce4-screensaver login prompt on a locked screen, there
is a very short window of time during which keyboard input is not
intercepted by xfce4-screensaver and is instead sent to the application
that was active before locking.
The issue has been fixed upstream in [2].
Impact
-------
The time window is normally too short for any real harm to occur when
physically typing on a keyboard. However, if an attacker is able to
generate input events in an automated way, the attacker can attempt to
deactivate the screensaver by sending a command quickly enough.
Affected systems
-----------------
The default Qubes OS 4.3 configuration, which uses xfce4-screensaver and
the Xfce desktop environment, is affected. Other Qubes OS releases and
other screensavers are not affected.
Systems that permit an attacker physical access to a keyboard interface
are affected. Most systems permit such access in some way, since the
user's legitimate keyboard must connect to the system through such an
interface, but the degree of difficulty for the attacker varies
significantly depending on the nature of the interface.
- The easiest method for an attacker is unrestricted USB keyboard input
without a confirmation prompt, but this is disabled in Qubes OS by
default. However, users can override this default configuration to
allow unrestricted USB keyboard input, and many users do so because
they have no other way to connect a legitimate keyboard to their
systems. If the user has allowed unrestricted USB keyboard input,
then an attacker can easily and quickly generate keyboard input
events by connecting a USB device that emulates a keyboard.
- An attacker could also use a non-USB keyboard input interface, such
as a PS/2 port. However, such interfaces are less common nowadays.
Nonetheless, if the system has such an interface, and if the attacker
has physical access to it, then the system is affected, even if USB
keyboard input is restricted.
- Even when there is no keyboard input interface exposed on the outside
of the machine as a convenient port, as in the case of a laptop with
disabled USB keyboard input and no PS/2 port, it may still be
possible for the attacker to physically modify the machine in order
to gain access to such an interface. For example, built-in laptop
keyboards must still be internally connected to the laptop's
motherboard through such an interface in order to function properly.
An attacker who can gain access to the internal components of the
machine could disconnect the legitimate keyboard and attach their own
malicious device to the same interface. However, this form of attack
is significantly more complex than the foregoing attack vectors and
requires extensive physical access, making it much more difficult to
execute successfully.
Discussion
-----------
In general, we consider most attacks that require physical access to the
system to fall outside the scope of the Qubes security model. Aside from
the general challenges of protecting against physical attacks, this is
primarily because physical protections depend heavily on the hardware
and firmware details of the system. Since Qubes OS is designed to run on
any x86 system that meets its system requirements [3], these hardware
and firmware details can vary significantly between systems and are
typically outside of Qubes' control. Nonetheless, we consider this
screensaver login bypass vulnerability to fall within the scope of the
Qubes security model, since Qubes OS does have control over keyboard
input interception on the lock screen.
Patching
---------
The following packages contain security updates that address the
vulnerabilities described in this bulletin:
For Qubes 4.3, in dom0 (no GUI domain):
- xfce4-screensaver 4.18.4-5
For systems with a GUI domain, a similar update will be provided by the
distribution of the template on which the GUI domain is based (e.g.,
Fedora or Debian).
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [4] Once available, the packages should be installed
via the Qubes Update tool or its command-line equivalents. [1]
Dom0's user session must be restarted afterward in order for the updates
to take effect. This can be accomplished by logging out of Xfce4, then
logging back in again, or by simply restarting the system.
Credits
--------
The issue was reported by Murat Altindis and Maria Kessler of AWARE7
GmbH.
Qubes issue #10720 [5] is likely a report of the same problem. This
issue was incorrectly identified as a duplicate of another issue that
sounds similar but that is not relevant to the security of Qubes OS.
References
-----------
[1] https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-update.html
[2] https://gitlab.xfce.org/apps/xfce4-screensaver/-/commit/4436087c6af5e915a2438d7c1dd0fdc282f547f8
[3] https://doc.qubes-os.org/en/latest/user/hardware/system-requirements.html
[4] https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/testing.html
[5] https://github.com/QubesOS/qubes-issues/issues/10720
The Qubes Security Team
https://www.qubes-os.org/security/
Source: qsb-111-2026.txt
Marek Marczykowski-Górecki’s PGP signature
