XFCE Screensaver Vulnerability: Lock-Screen Bypass via Monitor Switch

Short answer: The xfce4-screensaver has a vulnerability that bypasses the lock screen during a monitor switch or when an HDMI cable is unplugged and plugged back in. The root cause is a timing window between XUngrabServer and the new window grab in which X11 forwards keyboard input to background processes. Our fix enforces an explicit focus reset via XSetInputFocus before the new grab and was submitted upstream on 2026-03-11 as merge request #60 of xfce4-screensaver.

Which systems are affected by the XFCE screensaver bypass?

All Linux systems using xfce4-screensaver as their lock screen are affected, confirmed up to version 4.20.2. In our analysis we reproduced the behavior on Qubes OS and on a fresh Kali Linux installation. Because the root cause lies in the interaction with the X11 window manager, other XFCE-based distributions — Xubuntu, Manjaro XFCE, Linux Mint XFCE — are very likely vulnerable as well.

We first noticed the issue on Qubes OS. Its security model is built on strict isolation: applications run in separate virtual machines, and input events pass through sys-usb or sys-net before reaching the AppVM.

These additional hops widen the timing window in which keyboard input slips past the lock screen. In our case, they made the bug reproducible in the first place. The Qubes OS security design is not the cause — it is the microscope that made the defect visible.

The screensaver is a particularly sensitive component. It decides whether a locked session can be used without a password. If it fails, the other protection mechanisms usually no longer apply.

How does the vulnerability work technically?

The bypass is a race condition between releasing and reacquiring an X11 server grab. X11 processes keyboard and mouse events centrally through the X server; a screen locker claims these events exclusively by installing a server grab. If the grab is released before the new one is established, input lands in whatever window currently holds focus.

When a monitor switches or the HDMI signal disappears, xfce4-screensaver recreates the login window. To do so, it releases the existing grab (XUngrabServer) and requests a new one once the new window is available.

Depending on the system, there is a time window of about a few hundred milliseconds between the two operations, during which keyboard inputs are passed on to background processes. Anyone with a terminal or editor open in the background types directly into it — no authentication required.

This becomes critical when combined with shortcuts. A user who has bound a key to xfce4-screensaver-command --exit or opens a terminal via CTRL+ALT+T can end the screen lock on demand. That is the real attack vector.

How did we discover the bypass?

We found the behavior while setting up a new Qubes OS machine — not by targeted search, but by accident. After a roughly 15-minute break and unlocking the session, we noticed seemingly random characters in a browser text field. They were keystrokes we had used to wake the machine, and they had clearly been handled by the background browser rather than the lock screen.

The cause was easy to isolate. The behavior was reproducible whenever an external monitor lost its HDMI signal while the system was locked and the system reinitialized the monitor after key input. The same effect occurred when we unplugged and replugged the HDMI cable in the locked state.

In our pentest practice we regularly see that screen lockers are the last line of defense when physical access is a threat. A bypass triggered by a trivial hardware action — unplugging a cable — lowers the attack threshold significantly, especially in coworking spaces or conference rooms.

"The moment a keystroke on a locked system ended up in a background browser, it was clear this was not cosmetic. Combining monitor reinitialization with X11 grab release opens a window large enough to consistently type into an unlocked shell using a LilyGo T-Dongle S3."

— Murat Altindis, Offensive Security Consultant, AWARE7 GmbH

How can the exploit be reproduced?

Manual proof of concept

The simplest confirmation is a custom shortcut — F7, for example — that opens a terminal and terminates the screensaver:

xfce4-terminal -x bash -c "xfce4-screensaver-command --exit"

Inside the timing window after the monitor reset, the system does not route the shortcut into the lock screen but into the background application. The terminal starts, the command executes, the lock screen is released without a password.

Automation with the LilyGo T-Dongle S3

On Kali Linux with the current xfce4-screensaver 4.20.2, the timing window was too short for manual input. For reliable reproduction we used a LilyGo T-Dongle S3 — an ESP32-S3 device that the system recognizes as a USB keyboard. We flashed it with the open-source USBArmyKnife project, which runs DuckyScript directly on the ESP32-S3.

The payload is minimal:

KEYBOARD_LAYOUT win_de-DE
CTRL ALT T
DELAY 50
STRING xfce4-screensaver-command --exit
ENTER

Walk-through: the German keyboard layout ensures that special characters are transmitted correctly. CTRL ALT T opens a terminal, a 50-millisecond delay gives the shell time to load, the STRING line types the command character by character, ENTER executes it. Timing was resolved by brute force: we repeated the sequence until it landed inside the window.

Where is the root cause in the source code?

For root-cause analysis we cloned xfce4-screensaver from its official GitLab repository, built it locally, and replaced the installed binary with our debug version. Millisecond-resolution log lines then let us correlate code paths with the observed leak.

The key location is the grab release:

gs_debug ("*** Releasing X server grab");
gdk_x11_display_ungrab (display);
gdk_display_flush (display);

The leak appeared delayed, roughly 500 to 600 milliseconds after this call. An existing comment in the code showed that the maintainers were aware of the general risk — apparently without knowing it amounted to a real bypass:

#ifdef ENABLE_X11
    /*
     * It doesn't prevent all leaks, but it's better than nothing. Preventing all leaks would
     * probably require keeping the grab on the overlay permanently and passing events to the
     * screensaver windows, which seems overly complicated given what's at stake.
     */
    if (manager->priv->grab != NULL) {
        gs_grab_move_to_window (manager->priv->grab,
                                gtk_widget_get_window (manager->priv->overlay),
                                display, FALSE, FALSE);
    }
#endif

The actual culprit is gdk_x11_display_ungrab, which ends up calling XUngrabServer from the X11 library via the GDK library:

void
gdk_x11_display_ungrab (GdkDisplay *display)
{
  GdkX11Display *display_x11;

  g_return_if_fail (GDK_IS_DISPLAY (display));

  display_x11 = GDK_X11_DISPLAY (display);
  g_return_if_fail (display_x11->grab_count > 0);

  display_x11->grab_count--;
  if (display_x11->grab_count == 0)
    {
      XUngrabServer (display_x11->xdisplay);
      XFlush (display_x11->xdisplay);
    }
}

Between XUngrabServer and the new grab, X11 has no active lock-screen window registered. Input goes to whichever window last held focus. We confirmed this by patching the screensaver to intercept every keystroke and then discard it: keystrokes during the bypass window were never even observed by the screensaver — X11 had routed them straight to background processes.

Which fix closes the gap?

The fix acts on focus, not on grab behavior. Before the new grab, we strip focus from all windows and then set it explicitly on the new login window:

GdkDisplay *display = gs_window_get_display (window);
GdkWindow *gdk_win = gs_window_get_gdk_window (window);

gdk_x11_display_error_trap_push (display);
XSetInputFocus (GDK_DISPLAY_XDISPLAY (display), GDK_WINDOW_XID (gdk_win), RevertToParent, CurrentTime);
gdk_x11_display_error_trap_pop_ignored (display);

We placed this immediately before the existing call:

manager_maybe_grab_window (manager, window);

inside window_map_event_cb, which fires when a new window is created. Architecturally, setting focus after the new grab would be cleaner — but in our tests that path reliably broke subsequent logins. The pre-grab focus reset is therefore a deliberate compromise.

The fix was submitted on 2026-03-11 as merge request #60 in the xfce4-screensaver project and is awaiting upstream integration.

How high is the residual risk after the fix?

The fix reliably prevents keystrokes from ending up in background text fields, because the focus they would need is gone. It does not catch hotkeys, which do not require window focus. Users who bind xfce4-screensaver-command --exit or comparable sensitive actions to global shortcuts remain exposed.

In a default configuration without security-critical custom shortcuts, residual risk is low. The structurally clean path would be to drop grabs entirely and move the existing login window on monitor switches rather than recreating it. That would require a fundamental redesign of xfce4-screensaver and is not currently on the table.

Practical recommendation: Audit your XFCE keybindings for commands that end the screen lock, spawn shells, or launch privileged scripts. Such shortcuts remain an attack vector even with the fix in place.

Conclusion: Is xfce4-screensaver still usable?

Our first reflex was to advise against using xfce4-screensaver. After the exchange with the xfce4-screensaver and Qubes OS maintainers we see it more pragmatically. No X11 screen locker is immune to this class of timing issue — comparable gaps have appeared in other lockers in the past.

What matters is how quickly maintainers respond. Our fix was reviewed constructively on the merge request; the exchange with the maintainers was fast and substantive. That is a positive signal for the project.

Users who need maximum isolation should still evaluate whether a move to Wayland is feasible in the medium term. Wayland replaces grab-based logic with a compositor-centric model in which the screen lock is part of the compositor and focus transitions do not run inside this window. On X11 the pragmatic advice remains: stay on the current version, audit hotkeys, do not trade security for convenience.

FAQ: Common questions about the XFCE screensaver bypass

Which xfce4-screensaver versions are affected?

The vulnerability is confirmed up to and including xfce4-screensaver 4.20.2, the current release at the time of our analysis. Older 4.x versions share the underlying grab logic and are very likely affected as well. For the current status of the fix in a stable release, check the xfce4-screensaver repository directly.

Does the vulnerability apply to other X11 screen lockers?

The specific code location is XFCE-specific, but the underlying pattern — a race condition between XUngrabServer and the new grab — is a generic X11 concern. Historically, xscreensaver, slock, and i3lock have shown different variants of similar problems. A reliable statement about any specific locker requires its own code analysis.

How can I check whether my system is vulnerable?

Bind a shortcut such as F7 to xfce4-terminal -x bash -c "xfce4-screensaver-command --exit", lock the screen, unplug and replug the HDMI cable briefly, and press the shortcut key. If the lock screen releases without a password, the system is exploitable. Run this test only on a device you control.

Has a CVE ID been assigned?

At the time of publication no CVE ID has been issued to us. We coordinated the fix directly with the xfce4-screensaver and Qubes OS maintainers and did not run it through a formal CVE disclosure chain because the patch was already available. If a CVE ID is later assigned by MITRE or by a CNA such as Canonical or Red Hat, we will update this post and record it here.

What are the alternatives to xfce4-screensaver?

On X11, xscreensaver, slock, and physlock are established alternatives, each with its own trade-off between integration, feature set, and attack surface. The structurally safer option is moving to Wayland-based environments such as GNOME on Wayland or KDE Plasma on Wayland, where screen lockers are part of the compositor.

Next steps

Do you suspect a similar vulnerability in your infrastructure? Our penetration tests evaluate endpoint hardening, including screen-lock behavior, physical-access scenarios, and HID-based attacks.

• Request a free initial consultation
• Service: Penetration Testing
• Service: Red Teaming

Further reading: Linux server hardening · Race condition / TOCTOU · Vulnerability disclosure.

---

Hero image created with AI assistance (Black Forest Labs Flux 1.1 Pro). Disclosure per EU AI Act Art. 50.