I wouldn't consider this a problem of Wine itself. I believe It's a problem that arises due to the architecture of XDG MIME itself, and the decisions made by the Flatpak engineers.
Not every single application developer can be expected to keep track of all possible security issues that may arise, due to some edge case related to sandboxed applications. If you truly want your applications to be sandboxed, they should be sandboxed properly. I don't really know what the Flatpak developers are expecting when they allow the usage of MIME through the sandbox ... for hackers and engineers alike to collaborate, and say "please don't abuse this glaring security hole! Thanks, I'll keep that in mind."??!? The Flatpak engineers seem to expect magic to happen, in order to keep their software secure; and when that magic *doesn't* happen, they expect the Wine developers to cover their tracks. There is something to be said about Wine not heeding the security warning on the manpage, however, I cannot seem to find this warning on the manpage. Strange... If you *do* find this warning on an actual manpage, and not on a forum post / comment, please provide a link. Thanks. Sent with Proton Mail secure email. On Tuesday, July 7th, 2026 at 08:36, Sebastian Wick <[email protected]> wrote: > Hello everyone, > > tl;dr: Fedora currently ships at least one package (wine), which when > installed, provides malicious Flatpak applications a trivial way to > escape the sandbox. We should audit all packages for similar issues, > patch them downstream, and report the issue upstream. > > Flatpak applications can use the OpenURI Portal to open files in other > applications. Which application is launched is determined by the XDG > desktop-entry-spec. It also is clear on the security implications of > having handlers which execute arbitrary code (man 1 xdg-mime): > > Security Note: Never set a handler that will blindly execute code > or commands from the file being handled. Such behaviour will sooner > than later lead to unintended code execution i.e. through a curious > user trying to inspect a freshly downloaded file but running it by > accident. > > Keeping opening and executing separate actions helps with people > protecting themselves from malware, the default handler is an > opener, not a runner. > > If there is a handler which executes arbitrary code, a sandboxed > application can create a file to be executed, and use OpenURI to > execute it. This is a complete sandbox escape. > > We at GNOME take those very seriously, and have fixed vulnerabilities > in applications which accidentally do run arbitrary code: > https://blogs.gnome.org/mcatanzaro/2026/05/11/flatpak-sandbox-escape-via-yelp/ > > However, there are other projects out there where those obvious > vulnerabilities are disputed. Wine for example has not taken any > action and repeatedly denied any responsibility for it: > https://bugs.winehq.org/show_bug.cgi?id=59767 > > They argue that this can't be an issue on their side because this > behavior was introduced in 2004. The behavior was never a good idea > (see man 1 xdg-mime above). The handler that wine ships also bypasses > the executable bit. If you download an ELF or sh file in your browser > and open it, it will not run. If you download an exe, it will. > > Fedora has a responsibility to keep their users secure. We have to > patch the desktop file in wine to remove the MIME handler. > > Furthermore, it is not unlikely that there are similar issues hidden > in other packages. Some MIME handler might exist to execute arbitrary > codes, others might accidentally do so. Any one of them can destroy > the security of the overall system. > > Further reading: > https://www.openwall.com/lists/oss-security/2026/05/19/1 > https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/116 > > Cheers, > Sebastian > -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
