Description

An incorrect implementation of message filtering in xdg-dbus-proxy versions before 0.1.9 allows an attacker to bypass the intended message filtering on the D-Bus session bus by setting a reply serial number on non-reply messages. A malicious or compromised Flatpak app could use this to achieve arbitrary code execution outside its sandbox. xdg-dbus-proxy was designed to be part of the sandbox boundary for Flatpak, but it is released as a separate project and is sometimes used by other app frameworks such as Firejail.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-10-02T14:17:12.003Z",
  "pubdate": "2026-10-02T14:17:12.003Z",
  "executiveSummary": "A critical security vulnerability exists in xdg-dbus-proxy versions prior to 0.1.9, involving incorrect implementation of message filtering on the D-Bus session bus. This flaw allows a malicious or compromised application within a sandbox—such as a Flatpak container—to circumvent established security boundaries.\nThe vulnerability manifests as an improper handling of message serial numbers, where an attacker can assign a reply serial number to a non-reply D-Bus message. This allows the message to bypass the proxy's filtering logic, which is intended to restrict inter-process communication.\nThe impact is significant, as successful exploitation enables the attacker to send arbitrary D-Bus messages to privileged services outside the sandbox. This facilitates privilege escalation and potential arbitrary code execution on the host system. The vulnerability affects any software utilizing xdg-dbus-proxy as its sandbox boundary mechanism, including Flatpak and Firejail environments. Exploitation does not require prior authentication to the target service, as the attacker leverages the trusted path provided by the proxy to inject unauthorized commands.",
  "technicalDetails": "The root cause of this vulnerability lies in the logic used by xdg-dbus-proxy to track and validate D-Bus message types during transmission. D-Bus protocol messages can be categorized as method calls, signals, errors, or method returns. Method returns are associated with a specific request via the 'reply-serial' header, which correlates the response to the originating call.\nIn the vulnerable versions, the proxy's filter implementation fails to sufficiently validate that messages containing a 'reply-serial' header are indeed legitimate reply messages. An attacker can craft a malicious D-Bus message—which is semantically a method call—and manually insert a 'reply-serial' field into the message header.\nThe attack flow proceeds as follows: First, the compromised application initiates a connection to the D-Bus session bus through the xdg-dbus-proxy. Second, the attacker crafts a non-reply message intended for a sensitive service on the host that is otherwise protected by the proxy's whitelist/blacklist policies. Third, the attacker sets the 'reply-serial' header field to an arbitrary value. When the proxy processes this packet, the flawed logic incorrectly identifies the packet as a continuation of an existing conversation or a permitted reply, bypassing the standard security inspection routine that would normally block an unsolicited method call.\nBy bypassing these filters, the attacker can interact with D-Bus services that possess high privileges on the host system. Since D-Bus is a primary communication mechanism for system and user services, an attacker can invoke arbitrary methods on services like 'org.freedesktop.PolicyKit1' or other session-managed services. This level of interaction allows for the manipulation of system configurations, the triggering of privileged operations, or the injection of data into other applications, ultimately leading to arbitrary code execution outside the isolated sandbox environment.\nThis vulnerability is present in xdg-dbus-proxy versions before 0.1.9. It represents a fundamental failure in the integrity of the sandbox boundary, as the proxy assumes the message headers are honest regarding the message type. No user interaction or specialized authentication is required; the attacker merely needs the ability to communicate with the local D-Bus session bus, which is a standard capability for applications running within a Flatpak or similar sandbox."
}