xdg-dbus-proxy CVE-2026-93676

Exploitation requires the attacker to control a Flatpak application already running inside the xdg-dbus-proxy sandbox on the target system, with a D-Bus policy that restricts access by path, interface, or member - the bug is that these restrictions are not applied to broadcast (signal) messages. It only affects broadcast signals on the D-Bus session bus and the AT-SPI accessibility bus, not method calls. Limiting factors: local access only (AV:L), the attacker must already have low-privileged sandboxed code execution on the host (PR:L), user interaction is involved (UI:R), and impact is confined to reading information (C:L; no integrity or availability impact). It is not remotely reachable and provides no code execution.

This is a genuinely low-priority issue, and the signals are consistent. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N, base 3.2) reflects a locally-scoped, confidentiality-only information exposure: an attacker needs code already running as a low-privileged sandboxed Flatpak application on the target machine, and impact is limited to reading broadcast D-Bus signals that policy intended to filter out. The scope change (S:C) is legitimate because the flaw lets a sandboxed process cross the sandbox/proxy boundary to observe traffic on the session and AT-SPI buses. No EPSS score, KEV entry, POC, or SSVC decision data is provided in the input, so there is no evidence of active exploitation or automatable mass abuse - this is a defense-in-depth sandbox filtering weakness rather than a directly weaponizable flaw. There is no public exploit identified at time of analysis. Bottom line: real defect worth patching in Flatpak/RHEL fleets, but not an urgent, remotely-exploitable priority; it presupposes an attacker has already achieved sandboxed code execution on the host.

A user installs a malicious or compromised Flatpak application whose D-Bus access is supposed to be tightly restricted by xdg-dbus-proxy policy. Because broadcast (signal) messages are not properly filtered, the sandboxed app silently subscribes to and intercepts broadcast signals on the session bus and AT-SPI accessibility bus, harvesting sensitive data (e.g., accessibility text, notifications, or other application state) that the policy was meant to withhold. No public exploit code is identified at time of analysis, and exploitation requires the attacker's code to already be running inside the sandbox with user interaction.