TL;DR
A filtering regression in xdg-dbus-proxy let a sandboxed Flatpak app listen in on D-Bus broadcast signals it had no permission to receive.
CVE-2026-93676(Low, CVSS 3.2)- Affected versions 0.1.6 and 0.1.7, fixed in 0.1.8
- The entire bug is one commit that dropped the path/interface/member checks
- Reported by me, credited on the advisory, published by the maintainer
Low severity, but I like this one because the bug is a clean example of how a sandbox proxy fails: the gate is there, it just stops checking tickets.
Background
Flatpak sandboxes apps by cutting them off from the host D-Bus session bus. xdg-dbus-proxy is the doorman: it sits between the sandboxed app and the real bus and only forwards messages the app is allowed to see, based on --talk, --broadcast, and --call rules.
Broadcast signals are the interesting case. Unlike method calls (point to point), broadcasts go to everyone listening, so the proxy has to filter them by matching each signal against the allowed rules: the right path, the right interface, the right member. Skip any of those checks and the app hears things it shouldn’t.
The bug
Commit 0297845 changed the broadcast filtering path and dropped exactly those checks. From the advisory: filtering for broadcast messages bypassed path/interface/member validation, so any version carrying that commit (0.1.6, 0.1.7, plus backports) forwarded broadcast signals without verifying the app was actually allowed to receive them.
Concretely: a malicious or merely compromised Flatpak app could monitor any broadcast signal on the session bus or the AT-SPI (accessibility) bus: traffic from other apps, potentially containing information never meant for it. Same story for any non-Flatpak framework using xdg-dbus-proxy ... --broadcast=… or --call=….
The attacker model is narrow (local, low-privileged, needs a cooperative user interaction, confidentiality-only impact), hence Low, CVSS AV:L/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N. Fair rating. Sandbox escapes that only leak broadcasts are the shallow end of the pool, but the pool is still the sandbox boundary, so it still counts.
The fix (and why it wasn’t a one-liner)
The fix is a revert of 0297845, shipped in 0.1.8. But reverting broke something real, which is the most instructive part of this advisory.
Flatpak 1.15.9+ tried to let sandboxed apps receive two broadcast signals on the AT-SPI bus for accessibility, but the --broadcast rules Flatpak passed to the proxy were themselves incorrect. So the vulnerability had been accidentally papering over a Flatpak bug: fixing the proxy regressed accessibility features for Flatpak apps. That companion bug was fixed separately in Flatpak 1.18.1 (flatpak/flatpak@2afb4cf, “run-dbus: Correct —broadcast rules for the AT-SPI bus”).
Two lessons I keep relearning:
- A security fix that reverts to “correct” behavior can still break things, when other components quietly depended on the broken behavior. The advisory documents three such regressions (Flatpak AT-SPI, apps relying on accidental signal delivery, other frameworks): that level of honesty in an advisory is rare and good.
- Allowlists rot. The
--talk-name/--system-talk-namepermissions exist precisely for this; apps that need signals should declare them instead of inheriting them through a filtering hole.
Timeline
- Reported by me, credited on the advisory
- Aug 11, 2026: Advisory published by the maintainer, fix in 0.1.8
