Wine ships a .desktop file that registers itself as a MIME handler for EXE files and several other Windows executable file types. In some configurations, handling of an EXE file causes that file to be blindly executed with the permissions of the invoker. This allows escaping Flatpak and Snap sandboxes, because MIME handlers are not intended for use by code interpreters and loaders. NOTE: some parties feel that this is not a bug to be addressed in Wine, because there is no known solution that avoids a severe loss of usability (Wine could be a binfmt-misc handler, but binfmt-misc does not exist on all platforms supported by Wine).

On Mon, 18 May 2026 22:01:16 -0400 Aaron Rainbolt <arraybolt3 () riseup net> wrote:

... snip ... If all applications followed the xdg-mime manpage's advice to never execute code when opening a file, this wouldn't be that big of a problem. This is where Wine comes in; it ships a desktop file that registers Wine as a MIME handler for 'application/x-ms-dos-executable', 'application/x-msi', and 'application/x-bat'. [3] These handlers result in the command 'wine start /unix FILE-NAME' being run, which of course loads the executable code from the opened file into memory and starts running it. That means, if you are unlucky enough to have an unsandboxed copy of Wine as your only MIME handler for EXE files, any flatpak on your system can break out of the sandbox by writing an EXE file somewhere, then opening it with org.freedesktop.portal.OpenURI.OpenFile. This issue has been reported to Wine a short while ago [4]; I didn't report the issue privately since I couldn't find a security contact for Wine and was encouraged to make a public bug report when I asked for a security contact on IRC some time back. (I was also given an email where I could privately contact someone, but I no longer have it, and I was somewhat discouraged from using it when I initially asked.) CVE-2026-48831 has been assigned for this. [1]

-- Aaron

[1] https://www.cve.org/CVERecord?id=CVE-2026-48831

Gabriel Corona wrote in <7758b7f4-a71a-48a6-b4a9-516700650a7e () free fr>: |> Sandboxes should only allow allowlist of file types and make everything |> else fall back to a safe default. This could be a simple text editor |> (no IDE support!) for text files, and a hex editor (or an error) for |> binary files. | |That sounds extremely inconvenient. Running an email client in a |sandbox? It can't open a PDF or a JPEG (or worse, you'll get an |hex-editor) ...

Actually, i think what is missing is some intermediate step. This includes more control commands for RFC 1524 Mailcap files, which i am all for, and hope certain new things in the IETF (structured email, SML, to name it) do not loose it. 'Maybe even extend it.

For example, my MUA (but do not look) introduced certain new control commands (x-mailx-async, x-mailx-last-resort, x-mailx-ignore, too name some) , but none that fits here specifically -- however, mailcap (and other supported approaches of starting programs for data formats) are by default only used in "copiousoutput" mode, you need a special mimeview' command to invoke other things. Long story, this results in chains like

application/pdf;\ mupdf %s;\ test = [ -n "$DISPLAY" ] >/dev/null 2>&1;\ nametemplate = %s.pdf; x-mailx-ignore application/pdf;\ infile=%s\;\ trap "rm -f \"$infile\"" EXIT\;\ trap "exit 75" INT QUIT TERM\;\ mupdf "$infile";\ test = [ -n "$DISPLAY" ] >/dev/null 2>&1;\ nametemplate = %s.pdf; x-mailx-async; x-mailx-test-once application/pdf;\ pdfinfo %s\; pdftotext -layout %s -;\ test = command -v pdfinfo >/dev/null 2>&1;\ copiousoutput; nametemplate=%s.pdf; x-mailx-test-once

or

image/;\ display %s;\ test = { [ -n "$DISPLAY" ] && command -v display\; } >/dev/null 2>&1;\ x-mailx-ignore image/;\ infile=%s\;\ trap "rm -f \"$infile\"" EXIT\;\ trap 'exit 75' INT QUIT TERM\;\ display "$infile";\ test = { [ -n "$DISPLAY" ] && command -v display\; } >/dev/null 2>&1;\ x-mailx-async; x-mailx-test-once image/;\ identify %s;\ test = command -v identify >/dev/null 2>&1;\ copiousoutput; x-mailx-noquote; x-mailx-test-once

and the second ones are used for mimeview', the third it is when normally viewing emails. (pdftotext not initially -- but i am lazy, .. like you say.)

Short story: neither, i think, pdfinfo(1) nor pdftotext(1) (nor identify(1)) actually execute integrated Script, at least. But it is still not truly nice.

Best would surely be some viewer who has a "stepped approach", showing only some infos first, asking for confirmation or the action to be applied, before displaying an image or whatever. And then going into some safe mode when truly going "in full" on the data as such. Of course implementing such a thing in that very way is an extensive effort, and not always doable.

But maybe it is time -- instead of simply rewriting the same mess in Rust (gdk-pixbuf) -- to create "priviledge-separated" media viewers, where the image/data format specific stuff is in a completely separated "process", and only readily prepared data in a common type (X11 bitmap or what) is then send via IPC / made available in some shared mapping for some display/player. (It could be such things already exist, i live only in dwm / st / tmux, and have only fewest graphical things beside that.)

|If the sandboxed application is badly integrated and can't open files |and URIs, the user (me included) will prefer using the non-sandboxed |version in order to get things done (or will prefer using a more |user-friendly OS). This would defeat the purpose of having sandboxed |applications.

Over a decade ago an Irish forwarded a message from Trinity College Dublin; it is astounding "how rich" emails can get in real life. One does not want to use the above approach (what was, actually, shown). But priviledge-separated multimedia viewer, which maybe "goes in full" (video, audio .. play) only on explicit request, instead of simply linking/loading in more and more formats through shallow ad-hoc format converters that use format dedicated libraries, i think that is a problem.

--steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

(Hmm, seems the address I sent the original email from got dropped. Adding it back via CC...)

On Tue, 19 May 2026 11:03:12 +0100 Simon McVittie <smcv () debian org> wrote: On Mon, 18 May 2026 at 22:01:16 -0400, Aaron Rainbolt wrote: Of these two, org.freedesktop.portal.OpenURI.OpenFile is probably more problematic. This is because access to the OpenURI portal seems to be implicitly allowed by Flatpak. Expanding on what Flatpak intends to allow here:

The general design in Flatpak is that communicating with D-Bus peers that own a name of the form org.freedesktop.portal.(anything) is always allowed, and nearly everything else is not allowed by default. The idea is that when services like xdg-desktop-portal own a org.freedesktop.portal. name, that's an opt-in to taking responsibility for doing whatever mediation and prompting is necessary, whereas for other arbitrary services (like for example org.freedesktop.PackageKit) the assumption is that the service is not suitable for use by arbitrary sandboxed apps unless explicitly allowed.

(There are a few other hard-coded exceptions for things like the special org.freedesktop.DBus interface implemented by the message bus itself, which is allowed or denied at a much finer granularity because it's so fundamental to how D-Bus is used.)

The org.freedesktop.portal. special case is about the bus names that are owned, not a specific interface/method. The fact that the method call is org.freedesktop.portal.OpenURI.OpenFile is actually irrelevant to whether Flatpak allows it, even though it happens to follow the same naming convention as bus names; what matters is that it's implemented by the xdg-desktop-portal process, and that process owns the bus name org.freedesktop.portal.Desktop, so the parameters that Flatpak passes to xdg-dbus-proxy result in communication being allowed.

Other org.freedesktop.portal. names can be seen in the NAME column in systemd's busctl --user, for example. On a GNOME system, examples of other portal services include org.freedesktop.portal.IBus and org.freedesktop.portal.Tracker, which are narrower, more-restricted versions of the ibus and localsearch (formerly Tracker) interfaces. The authors of those services are responsible for making them safe.

For xdg-desktop-portal specifically, I believe there is work being done on an "entitlements" mechanism so that in future, some (all?) xdg-desktop-portal interfaces will refuse to process requests from sandboxed apps that do not have the appropriate "entitlement", similar to the way Android permissions work - for example apps that don't have the "screenshot" entitlement might not be allowed to take screenshots, even with user consent. I don't know the finer details of that work, though. It will presumably need a backward-compatibility mechanism where older apps are assumed to have entitlements for most of the functionality that was traditionally always available, otherwise that would be a major functional regression.

As far as I know, the entitlements mechanism is being done at the portal level rather than the D-Bus level: the D-Bus message gets delivered to the portal either way, but the portal chooses whether to take the requested action (possibly after prompting the user) or reject the request. This is analogous to the way modern D-Bus system bus services are usually designed, with the D-Bus message delivered to the service unconditionally, and the service deciding whether to obey or reject it (normally by querying polkit). Thanks for the extra info, this is good to know. If all applications followed the xdg-mime manpage's advice to never execute code when opening a file, this wouldn't be that big of a problem. This is where Wine comes in; it ships a desktop file that registers Wine as a MIME handler for 'application/x-ms-dos-executable', 'application/x-msi', and 'application/x-bat'. Note that not all packaged versions of Wine do this: for example in Debian, this MIME handler was disabled in 2013 in response to <https://bugs.debian.org/327262>. Good. Unfortunately, convincing upstream to follow suit is proving to be a challenge... Unfortunately, I was able to find another program with an unsafe handler registered just while writing this email (which I intend on reporting privately once I've sent this). So while it seems like these kind of handlers aren't super common, they aren't that hard to find if you dig around for a while. CVE-2023-26314 (<https://bugs.debian.org/972146>) in Debian's packaging of the Mono runtime is another example that was already public with a CVE ID issued. I believe that specific vulnerability was specific to Debian (and Debian derivatives that inherited it, like Ubuntu), but the general "shape" of the problem could affect any distro, and it was discussed (briefly) in the thread starting at <https://www.openwall.com/lists/oss-security/2023/01/05/1>. Thanks for the pointer. That's pretty similar to the "other program" I found. We're working on a sandboxing system (really a glorified systemd-nspawn frontend) that allows each sandbox to be self-sufficient enough to not need access to the host's D-Bus daemon. [9] That should prevent any possible way to leverage D-Bus as a sandbox escape mechanism. This is definitely a trade-off: the more barriers a sandboxing system puts up between host and sandbox, the safer it will be, but the less well-integrated with the host system it will feel. At one extreme, each app could be in its own VM (very safe, very poorly integrated unless heroic efforts are undertaken to provide communication between them), and at the other extreme, the apps could be effectively un-sandboxed (very well integrated, but very much not safe if an app is compromised or malicious). Sure, this isn't meant to replace Flatpak, I just thought it might be useful to mention here. (Funny enough, one of the end goals of the project is to allow using VMs rather than namespace containers.) Each app/sandboxing framework needs to choose its own security posture, which will determine the extent to which that framework is safe to use with a potentially malicious or compromised app. More-secure/less-integrated is not necessarily always better for the overall security of the ecosystem: if an app framework is inconvenient to use, the likely result is that most people will use completely un-sandboxed apps instead, which could ironically lead to more security exposure than if they had been using imperfectly-sandboxed apps.

Any container-based sandboxing mechanism, however well-designed, is also going to be susceptible to whatever vulnerabilities are available at the Linux syscall interface (which feels especially topical this month!), although this can be mitigated by mechanisms like seccomp (as used in Flatpak and systemd-nspawn) or AppArmor (as used in Snap). Indeed, that is a risk that is on our radar.

I wonder if it would be worth proposing a change to whatever system component handles opening files (probably something in Glib, or xdg-utils, haven't researched that deeply yet), so that handlers cannot be registered for certain "dangerous" file types (i.e. ELF/PE/Mach-O executables, scripts in various languages, etc.)? The only real downside I can see to that is the inability to text editors to register themselves as handlers for script MIME types, and in those instances, the editor can register itself as the handler for another applicable, more generic MIME type (i.e. text/plain), then change its behavior based on the more detailed MIME type of the file after it opens it.

-- Aaron

On Mon, 18 May 2026 at 22:01:16 -0400, Aaron Rainbolt wrote: Of these two, org.freedesktop.portal.OpenURI.OpenFile is probably more problematic. This is because access to the OpenURI portal seems to be implicitly allowed by Flatpak. Expanding on what Flatpak intends to allow here:

If all applications followed the xdg-mime manpage's advice to never execute code when opening a file, this wouldn't be that big of a problem. This is where Wine comes in; it ships a desktop file that registers Wine as a MIME handler for 'application/x-ms-dos-executable', 'application/x-msi', and 'application/x-bat'.

Unfortunately, I was able to find another program with an unsafe handler registered just while writing this email (which I intend on reporting privately once I've sent this). So while it seems like these kind of handlers aren't super common, they aren't that hard to find if you dig around for a while.

We're working on a sandboxing system (really a glorified systemd-nspawn frontend) that allows each sandbox to be self-sufficient enough to not need access to the host's D-Bus daemon. [9] That should prevent any possible way to leverage D-Bus as a sandbox escape mechanism.

smcv

Wine 20050211 and earlier creates temp files with world readable permissions and predictable file names, which allows local users to obtain sensitive information, such as passwords.

gdi/driver.c and gdi/printdrv.c in Wine 20050930, and other versions, implement the SETABORTPROC GDI Escape function call for Windows Metafile (WMF) files, which allows attackers to execute arbitrary code, the same vulnerability as CVE-2005-4560 but in a different codebase.