Latest version: 6.7.4

This is not really a vulnerability report for a specific program, there are at least five different programs involved here.

Tucked away in man 1 xdg-mime is the following advice:

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.

tl;dr of the rest of this: Most open-source programs (whether on accident or on purpose) seem to heed this advice. Some of them don't. Those that don't are quite useful for escaping sandboxes.

First, a bit of background:

People have to run arbitrary code (apps). Arbitrary code is scary, so there are a number of ways on Linux to keep that code from doing anything it "shouldn't" do (AppArmor confinement, Flatpak sandboxing, Snap sandboxing, Firejail, etc.). On the other hand, apps often have to talk to other apps in order to do their job right (for instance, a file manager needs to open your office suite when you double-click a document, and many apps may need to open your file manager to show what's in a folder). Sandboxing apps generally breaks them because it prevents them from talking to other apps. The way this has been worked around so far is to:

Make apps do most/all of their non-internal IPC over D-Bus. Standardize a bunch of system service interfaces so that applications have established ways to do things like open documents and file managers. Allow the sandboxed apps access to D-Bus.

Of course, this completely undermines sandboxing since you can use D-Bus to do all sorts of fun things, like tell systemd to LDPRELOAD a malicious library into any user service that is started or restarted. To fix that, there are mechanisms that restrict what sandboxed code can do with D-Bus, allowing them to call particular D-Bus methods but not others. xdg-dbus-proxy and AppArmor D-Bus mediation are two examples. For these mechanisms to work, whatever provides standard system services on D-Bus must do so in a way that doesn't allow arbitrary code exeuction. As you probably have already guessed, not all system service implementations meet this criteria.

There are two particular D-Bus interfaces I researched a few months ago, before writing this. One is org.freedesktop.FileManager1.ShowFolders [1], the other is org.freedesktop.portal.OpenURI.OpenFile [2]. With the help of a couple of file managers, xdg-desktop-portal-gtk, and Wine, I've been able to escape Flatpak sandboxing and AppArmor confinement using both of these interfaces.

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. (I have not verified this by reading code, but I built a flatpak from source that was only given Wayland access, and it was somehow able to access this portal anyway.) The OpenFile call allows applications to open arbitrary files outside of the sandbox that called the method. (This is a relatively sensible thing to do; it's unreasonable to expect a browser flatpak to bundle a video player, so if you download a video and then try to open it, your browser needs to be able to tell your system "find a video player and open this with it." It's then up to the portal implementation to launch the player, either outside of any sandbox or in a different sandbox.) From my experiments, xdg-desktop-portal-gtk seems to pop up an "Open With" dialog if you try to open a file and have two or more handlers for the same MIME type installed. If you don't have at least two handlers, the one handler you do have gets run without prompting.

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.)

org.freedesktop.FileManager1.ShowFolders is less of a problem, but also somewhat interesting. According to the specification, it "assumes that the specified URIs are folders; the file manager is supposed to show a window with the contents of each folder." What I think the spec meant to say is that the call only takes paths to folders as input, but unfortunately the wording is vague here. At least file manager (PCManFM-Qt) assumes that all of the arguments are folders without verifying this. It then passes these arguments through code that does the equivalent of running xdg-open on each argument, since if it's a folder, opening it with its default handler will open the file manager. Of course, there's nothing preventing me from passing a "folder" URI of file:///path/to/malware.exe, which will run the program. A very similar issue existed in KDE's Dolphin file manager, but that was a bug, not a design decision. The issue was assigned CVE-2026-41525 and is fixed in Dolphin >= 25.12.3. [5]

Obviously, I think Wine should probably stop registering itself as an EXE file handler. 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.

I couldn't quickly find a CWE that covered this particular issue except for CWE-441 (confused deputy problem). I don't know if this warrants a new CWE, and my CWE searching skills kind of stink, so maybe there is something for this already. In any event, if you maintain an app (or a package for an app) that interpretes or executes code, please check if it registers MIME handlers that blindly executes code, and remove those handlers if so. There are more ways for those handlers to go wrong than just users double-clicking the wrong thing.

A couple tangential notes about what Kicksecure [6] (a security-hardened Debian derivative I contribute to) has been doing to mitigate this:

We currently ship a D-Bus "shim" that owns the org.freedesktop.FileManager1 name on the D-Bus session bus. [7] [8] This shim checks each directory URI to ensure it points at a real directory, then pops up a window asking the user if they really want to open directories with the default file manager, showing them the path to each directory. This is technically vulnerable to TOCTOU issues (an attacker could swap out a directory with an executable file after it is displayed to the user), but since the directory checks are done both before and after the user clicks "Open", it is impossible (to my awareness) for the attacker to know when to swap out the file. The shim also warns loudly if it detects that something was swapped out before opening it. The chances of success at this attack are small enough and the consequences of failure large enough that an attacker likely won't find it useful. 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.

-- Aaron

[1] https://www.freedesktop.org/wiki/Specifications/file-manager-interface/ [2] https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.OpenURI.html [3] https://gitlab.winehq.org/wine/wine/-/blob/master/loader/wine.desktop?reftype=heads [4] https://bugs.winehq.org/showbug.cgi?id=59767 [5] https://kde.org/info/security/advisory-20260427-2.txt [6] https://www.kicksecure.com/ [7] https://github.com/Kicksecure/security-misc/blob/master/usr/src/security-misc/fm-shim-backend.c%23security-misc-shared [8] https://github.com/Kicksecure/security-misc/blob/master/usr/lib/python3/dist-packages/fmshimfrontend/fmshimfrontend.py%23security-misc-shared [9] https://github.com/ArrayBolt3/sandbox-manager-dist

Kdenlive before 26.04.1 allows dangerous proxy parameters when an attacker-controlled project file is used.

In KDE KCoreAddons before 6.25, KShell::quoteArgs is intended to safely quote arguments so that they can be passed to a shell command. This parsing does not adequately handle metacharacters, leading to an escape from the shell. All applications relying on this method in a security-critical path to handle user input are affected and could be exploited. In particular, because sendInput() sends a string to a terminal, a control character such as \x01 can be used during injection.

KDE Dolphin before 25.12.3 allows applications in a Flatpak (or with AppArmor confinement) to open folders outside of the application sandbox without additional scrutiny. Dolphin's implementation of the FileManager1 protocol allows the path given to be any type of file, including scripts or executables. (By default, Dolphin will then prompt the user to determine if they want to launch a script or executable; however, the intended behavior is to block the attempted action, not present a consent prompt.)

The new upstream added a privileged D-Bus helper called plasmaloginauthhelper, which suffers from multiple issues, e.g.aA compromised plasmalogin service account can chown() arbitrary files in the system.

Hello list!

Summary: plasma-login-manager, a new display manager component in KDE, contains a privileged D-Bus helper which suffers from defense-in-depth issues allowing the plasmalogin service user to escalate to root in various ways.

We also offer a rendered version of this report on our blog [1].

1) Introduction ===============

In recent releases of the KDE desktop environment a fork of the SDDM display manager [2] called plasma-login-manager [3] has been integrated. As usual this led to a review [4] in our team for the privileged D-Bus components contained in the package. While most of the code remains the same [5], the new upstream added a privileged D-Bus helper [6] called plasmaloginauthhelper, which suffers from defense-in-depth security issues [7]. The full details of the issues will be discussed in the following sections.

For this review we looked into plasma-login-manager version 6.6.2 [8].

2) Helper Overview ==================

plasmaloginauthhelper makes the D-Bus interface "org.kde.kcontrol.kcmplasmalogin" accessible to all users in the system via the D-Bus system bus. It offers three actions sync(), reset() and save() which are all by default protected by Polkit's authadmin setting.

These methods allow to manage configuration data stored in the home directory of the plasmalogin service user, which has a preset of /var/lib/plasmalogin. The helper runs with full root privileges and interprets various client-supplied data. The plasmalogin home directory has the following permissions:

drwxr-x--- 5 plasmalogin plasmalogin 4.0K Mar 24 13:25

Actually this helper is also a kind of fork of a helper found in the sddm-kcm repository, which we covered in a previous report [9]. It seems the codebase has not improved since then, but rather additional attack surface has been added in the meantime.

3) Security Issues ==================

3.a) Arbitrary chown() via Symlink Attack in sync() Method --------------------------------------------------------------

In the sync() method [10] the helper service naively performs chown() calls [11] on files located in the service user's home directory (/var/lib/plasmalogin), allowing a plasmalogin to root exploit.

The chown() is performed for the paths $PLASMALOGINHOME/.config, $PLASMALOGINHOME/.config/fontconfig as well for a list of configuration files like plasmarc placed into $PLASMALOGINHOME/.config.

A compromised plasmalogin service account can place symbolic links here to direct the chown() to arbitrary files in the system. After the chown() the helper writes client-supplied content into these files, which will also end up in arbitrary files in case of a symlink attack.

This method's logic would also allow deletion of certain files like plasmarc in arbitrary directories, would the relevant statement [12] in the service implementation not lack the final filename component in the path construction:

QFile(homeDir + QStringLiteral("/.config/")).remove();

Thus this removal logic doesn't work at all at the moment, since it attempts to remove the .config directory instead of the actual configuration files.

3.b) Arbitrary File Deletion in reset() Method ------------------------------------------------

In the reset() method [13] the paths $PLASMALOGINHOME/.cache and $PLASMALOGINHOME/.config/fontconfig are recursively deleted. For this purpose the Qt API QDir::removeRecursively() is used. The implementation [14] of this function follows symbolic links even in the final path component, which means that a compromised plasmalogin service user can leverage this logic to achieve the deletion of arbitrary directory trees in the system.

3.c) Symlink Attack via /var/lib/plasmalogin/wallpapers in save() Method ----------------------------------------------------------------------------

In the save() method [15] the path /var/lib/plasmalogin/wallpapers is created and opened by root [16], using a system call sequence affected by a race condition. A compromised plasmalogin user can replace the directory by a symbolic link in time for the service to write wallpaper files to arbitrary locations in the system, leading to local Denial-of-Service (DoS) and integrity violation.

In this spot the helper employs a low-level openat2() system call [17] to avoid symbolic link resolution, but this only applies to the actual files placed within the wallpaper directory, not to the directory itself, which is naively opened before that.

3.d) Missing Integrity Check of Configuration Data in save() Method ---------------------------------------------------------------------

In the save() method the contents of the file /etc/plasmalogin.conf can be completely controlled by the caller [18]. Since this method is protected by authadmin Polkit authentication this is basically acceptable, but there is not even an integrity or syntax check of the data, the method blindly forwards whatever the client passes to it into this file, without a maximum size limit or any sanity checks. While this is not directly a security issue it is a lack of robustness, because the D-Bus service is responsible for maintaining a sane structure of the privileged configuration file, preventing a broken system e.g. in case of buggy clients.

3.e) Lack of File Descriptor and File Size Verification in save() Method --------------------------------------------------------------------------

For the actual wallpaper files, file descriptor passing [19] is employed, which is good. There is no upper limit enforced on the amount of data placed into the wallpapers directory, however, which allows to exhaust disk space in /var/lib/plasmalogin.

Even file descriptors passed from clients should be verified to check whether they refer to regular files and have no unexpected file flags set. This verification is missing.

4) Suggested Fixes ==================

We suggested the following fixes to upstream:

- Foremost the helper should drop privileges to the plasmalogin user before performing any file system operations in /var/lib/plasmalogin, thereby eliminating all symlink attack surface. There still remains Denial-of-Service (DoS) attack surface if the service user places e.g. a named FIFO pipe somewhere. Avoiding this requires careful inspection of each path component by the service before opening it. - The helper should verify the structure and size of data written to /etc/plasmalogin.conf. - The helper should place a limit on the maximum amount of space which may be used for wallpapers in the plasmalogin user's home directory. - The helper should verify the type and flags of file descriptors passed by the client. The descriptors should not have special file types and they should not have any unexpected flags like OPATH set.

5) Severity ===========

None of the issues in this report is exploitable in a default installation of plasma-login-manager. Most of the problems affect the situation when the plasmalogin service user is compromised and thus affect defense-in-depth.

It is conceivable, however, that some actions in the helper, like the wallpaper management, could be reduced to lesser authentication requirements like a Polkit yes setting for locally logged-in users in the future, be it due to upstream changes or due to choices made by system integrators. Then further problems like disk space exhaustion by other unprivileged users could sneak in as well.

Based on the high severity of the defense-in-depth issues shown in this report, our assessment is that there is effectively no separation between root and the plasmalogin service user account.

6) Upstream Bugfix ==================

At this time there is no bugfix available by upstream, but a security fix is planned for the next Plasma release on May 12. We have not been involved in upstream's bugfix process so far and have no knowledge about the approach that will be taken to address the issues from this report.

7) CVE Assignment =================

We suggested a single CVE assignment relating to the lack of privilege drop of the D-Bus service, which is the root cause of most of the issues described in this report. In coordination with upstream we assigned CVE-2026-25710 and shared it with them to track these defects.

8) Timeline ===========

2026-03-30: We reached out to security () kde org with a report of the problems, offering coordinated disclosure. We stated that in our eyes, due to the issues being restricted to defense-in-depth, an embargo would not be strictly necessary. 2026-03-30: Upstream provided a short reply, asking for a CVE assignment. 2026-03-31: We assigned CVE-2026-25710 and shared it with upstream. 2026-04-13: Lacking a more detailed response from upstream we asked once more whether they would like to perform coordinated disclosure and what the desired coordinated release date (CRD) would be in that case. 2026-04-13: We received a reply from upstream stating that no coordinated disclosure would be necessary and bugfixes would be published via public pull requests soon in expectation of a security release on May 12. 2026-04-13: To be sure we asked upstream once more whether they agreed to us publishing the report right away. 2026-04-20: Lacking a response and with no visible publication on upstream's end we asked once more if publication on our end would be acceptable for them. 2026-04-21: We received a response confirming that we were allowed to publish right away.

9) References =============

[1]: https://security.opensuse.org/2026/04/27/plasma-login-manager.html [2]: https://www.github.com/sddm/sddm [3]: https://invent.kde.org/plasma/plasma-login-manager [4]: https://bugzilla.suse.com/showbug.cgi?id=1260039 [5]: https://bugzilla.suse.com/showbug.cgi?id=1260402 [6]: https://invent.kde.org/plasma/plasma-login-manager/-/blob/v6.6.2/src/frontend/kcm/auth/plasmaloginauthhelper.cpp?reftype=tags [7]: https://bugzilla.suse.com/showbug.cgi?id=1260930 [8]: https://invent.kde.org/plasma/plasma-login-manager/-/tree/v6.6.2?reftype=tags [9]: https://security.opensuse.org/2024/04/02/kde6-dbus-polkit.html#problematic-file-system-operations-in-sddm-kcm6 [10]: https://invent.kde.org/plasma/plasma-login-manager/-/blob/v6.6.2/src/frontend/kcm/auth/plasmaloginauthhelper.cpp?reftype=tags#L61 [11]: https://invent.kde.org/plasma/plasma-login-manager/-/blob/v6.6.2/src/frontend/kcm/auth/plasmaloginauthhelper.cpp?reftype=tags#L85 [12]: https://invent.kde.org/plasma/plasma-login-manager/-/blob/v6.6.2/src/frontend/kcm/auth/plasmaloginauthhelper.cpp?reftype=tags#L99 [13]: https://invent.kde.org/plasma/plasma-login-manager/-/blob/v6.6.2/src/frontend/kcm/auth/plasmaloginauthhelper.cpp?reftype=tags#L125 [14]: https://github.com/qt/qtbase/blob/90b845d15ffb97693dba527385db83510ebd121a/src/corelib/io/qdir.cpp#L1666 [15]: https://invent.kde.org/plasma/plasma-login-manager/-/blob/v6.6.2/src/frontend/kcm/auth/plasmaloginauthhelper.cpp?reftype=tags#L161 [16]: https://invent.kde.org/plasma/plasma-login-manager/-/blob/v6.6.2/src/frontend/kcm/auth/plasmaloginauthhelper.cpp?reftype=tags#L195 [17]: https://invent.kde.org/plasma/plasma-login-manager/-/blob/v6.6.2/src/frontend/kcm/auth/plasmaloginauthhelper.cpp?reftype=tags#L225 [18]: https://invent.kde.org/plasma/plasma-login-manager/-/blob/v6.6.2/src/frontend/kcm/auth/plasmaloginauthhelper.cpp?reftype=tags#L169 [19]: https://security.opensuse.org/2024/08/13/summer-spotlight.html#kde6-release-final-touches-and-improvements

Best Regards

Matthias

-- Matthias Gerstner <matthias.gerstner () suse de> Security Engineer https://www.suse.com/security GPG Key ID: 0x14C405C971923553 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Jochen Jaser, Andrew McDonald, Werner Knoblich

bookserver in KDE Arianna before 26.04.1 allows attackers to read files over a socket connection by guessing a URL.

KDE Kleopatra before 26.08.0 on Windows allows local users to obtain the privileges of a Kleopatra user, because there is an error in the mechanism (KUniqueService) for ensuring that only one instance is running.

End of life: 6/16/2026, End of support: 6/16/2026, Latest version: 6.6.6

KDE messagelib before 25.11.90 ignores SSL errors for threatMatches:find in the Google Safe Browsing Lookup API (aka phishing API), which might allow spoofing of threat data. NOTE: this Lookup API is not contacted in the messagelib default configuration.

Hello list,

please find below a detailed report of vulnerabilities found in smb4k [1]. These issues have been pre-disclosed to the distros mailing list on 2025-12-01, and today is the general publication date. We also offer a rendered HTML version of this report on our blog [2].

Summary: smb4k is a KDE desktop related utility which allows unprivileged mounts of Samba/CIFS network shares. The utility was already rejected from entering openSUSE in 2017 due to severe security issues. A revisit of the tool showed that it still suffered from major vulnerabilities leading to local Denial-of-Service or even a local root exploit. After a long coordinated disclosure, upstream arrived at a working bugfix in version 4.0.5.

1) Introduction ===============

smb4k [1] is a KDE desktop related utility which allows unprivileged mounting of Samba/CIFS network shares. The SUSE security team reviewed its privileged KAuth helper component already in 2017 [3] which led to the discovery of CVE-2017-8422 [4] (general KAuth authentication bypass) and CVE-2017-8849 [5] (local root exploit via smb4k mount helper).

This September we were asked to reconsider [6] smb4k for inclusion in openSUSE Tumbleweed. The resulting review showed that the mount helper still lacks input validation, is affected by race conditions and has a bug in its existing verification logic. This leads to local attack vectors which allow Denial-of-Service or even a local root exploit.

Many Linux distributions and also some BSDs are potentially affected by the issues described in this report. We offered coordinated disclosure to upstream and the maximum 90 days non-disclosure period was fully spent to arrive at a patch which addresses all the issues. This patch is found in commit 0dea60194a [7], which is part of the 4.0.5 bugfix release [8] of smb4k.

The following section provides a short overview of the privileged mount helper. Section 3) looks into the problems found in the helper's mount method. Section 4) in turn looks into the issues found in the helper's unmount method. Section 5) contains further remarks on the helper's code quality and security concerns. Section 6) discusses the fixes we suggested to upstream to address the issues. Section 7) gives details about the bugfix which was finally implemented by upstream. Section 8) suggests possible workarounds that can be applied to avoid the issues found in this report. Section 9) provides reproducers for the issues.

This report is based on smb4k release 4.0.4 [9].

2) Overview of the Privileged Mount Helper ==========================================

The problematic privileged mount helper component of smb4k is relatively small and can be found in the file smb4kmounthelper.cpp [10]. The helper runs with full root privileges and implements two KAuth actions accessible via D-Bus: mounting and unmounting a network share. Both actions are allowed for local users in active sessions without authentication, based on the Polkit yes setting.

3) Problems in Smb4KMountHelper::mount() ==========================================

3.1) Arbitrary Target Directories can be used for Mounting Network Shares -------------------------------------------------------------------------

The helper does not impose any restrictions on the target directory where the desired Samba share will be mounted. This means the share can also be mounted over /bin, for example. Should the client have control over the contents of the network share, then this allows for a local root exploit by placing crafted binaries e.g. for /bin/bash on the share, which are bound to be executed by privileged processes at some point.

If the share's content cannot be controlled by the attacker, then this serves as a local Denial-of-Service attack vector, as vital system programs will become inaccessible.

To fix this, we suggest to only allow mounting of network shares in a pre-defined location which is not controlled by unprivileged users.

3.2) Arbitrary Command Line Arguments can be Passed to mount.cifs -------------------------------------------------------------------

The client can specify arbitrary additional command line arguments in the mhoptions parameter, which will be passed to the mount.cifs program [11]. The command line constructed by the mount helper looks like this:

/sbin/mount.cifs <URL> <mountpoint> <options>...

All of these arguments, except for the path to the mount.cifs program itself, are actually controlled by the client. It is not the generic mount program which is invoked here, otherwise the client could already perform arbitrary mounts in the system. Instead the attacker is restricted to what the special-purpose mount.cifs binary provides.

The mount.cifs program supports a plethora of mount options [12]. Investigating the effect of each one would go beyond the scope of this report. There is one simple privilege escalation vector, however: passing filemode=04777,uid=0 to the command line results in every file on the network share mount receiving setuid-root permissions. If the content of the network share is controlled by the attacker, then this can easily be used to introduce an attacker-controlled setuid-root program into the system. This would then allow for a local root exploit even if issue 3.1) would be fixed.

Other mount.cifs options like port=<port> could be used to direct the kernel to a CIFS server controlled by the attacker itself, listening on an unprivileged port on localhost. This way a local attacker could provide the necessary crafted network share for executing the exploits described in this report on its own, without relying on external network resources.

To fix this, we suggest to restrict the mhoptions to a whitelist of allowed parameters, and also verify the options' values in case they can contain problematic settings.

3.3) Clients can Control the KRB5CCNAME Environment Variable Passed To mount.cifs -------------------------------------------------------------------------------------

The client can provide an arbitrary path in the mhkrb5ticket parameter; the mount helper will place this path into the KRB5CCNAME environment variable [13] for the mount.cifs child process. This is to allow use of the client's Kerberos credentials for mounting the network share.

The client can pass a path pointing to file system locations normally not accessible to it. In a multi-user scenario this would allow, for example, to hijack another user's Kerberos credentials, by passing a path to the credentials cache of the other user. It might also lead to information leaks of files like /etc/shadow, should mount.cifs output file content to the system logs or on stderr (the output of which is returned to the client via D-Bus).

Furthermore, this path could be used for file existence tests or for a local Denial-of-Service attack (by pointing to special files like /dev/zero or a named FIFO pipe).

To fix this, we recommend not to pass a path, but an already open file descriptor from the client to the helper, to avoid the opening of arbitrary files with root privileges.

4) Problems in Smb4KMountHelper::unmount() ============================================

4.1) Missing return Statement on Mount Path Verification Failure ------------------------------------------------------------------

This is similar to issue 3.1) above regarding mounting. In smb4kmounthelper.cpp line 177 [14] there is an if block that acts on the situation when the mhmountpoint path supplied by the client does not match any of the available Samba mounts returned from KMountPoint::currentMountPoints().

The problem is that this if block only sets an error message, but does not actually terminate the function execution with return. This means the verification is ineffective and local users can unmount arbitrary file systems despite the check.

This is a major local Denial-of-Service attack vector, which can lead to a complete system outage. In some special contexts it might even allow information leaks or privilege escalation, when file system locations have been made inaccessible by mounting other file systems on top (we can imagine something like this e.g. in the context of container setups).

4.2) Arbitrary Command Line Parameters can be Passed to umount ----------------------------------------------------------------

Similar to issue 3.2) above, the privileged helper forwards arbitrary command line parameters provided by the client in mhoptions to the command line of the umount program. This happens in smb4kmounthelper.cpp line 187 [15]. Basically the umount program will be invoked like this:

/sbin/umount <options>... <mount-point>

Assuming issue 4.1) would be fixed, the <mount-point> parameter cannot be chosen arbitrarily by the client, but must match an existing "cifs", "smbfs" or "smb3" type mount path. As long as such a mount path exists, the client can pass arbitrary additional mount points as "options", which will then be unmounted as well. This is a lighter variant of issue 4.1), leading to local Denial-of-Service if the described pre-condition is fulfilled.

Apart from this, umount offers various options [16] that can influence the way it operates. One option that sticks out is -N --namespace ns, which causes the program to unmount the file system in an arbitrary mount namespace. This could impact privileged processes, other users' containers or jailed processes.

To fix this, we suggest to restrict the mhoptions to a whitelist of allowed parameters.

4.3) Race Conditions Affecting KMountPoint::currentMountPoints() ------------------------------------------------------------------

This is not directly an issue in smb4k itself, but an issue in the KIO library [17] which implements the KMountPoint API. During our tests we used version v6.17.0 [18] of this library.

The mount helper's umount() function attempts to verify [19] the input path provided by the client by comparing it against current mounts in the system as reported by the kernel. Only active "cifs", "smbfs" and "smb3" file system mounts are supposed to be unmounted. To this end the current list of mounted file systems is obtained from

KMountPoint::currentMountPoints(KMountPoint::BasicInfoNeeded | KMountPoint::NeedMountOptions);

The implementation of currentMountPoints() relies on the libmount library to retrieve a list of mount points [20]. The libmount library provides a proven implementation for safely parsing files like /proc/self/mountinfo, which we reviewed ourselves a few years ago and deemed robust. After safely obtaining the information from libmount, the KIO library performs some actions on top, however, which can lead to security relevant issues.

One minor issue is found in kmountpoint.cpp line 365 [21], where stat() is called on the target mount directory of each mount entry. This potentially accesses untrusted paths, also from FUSE file systems, which could in some cases cause a local Denial-of-Service if stat() blocks. Also, the supposed mount point could be unmounted by the time the stat() call is performed, allowing the path to point to an arbitrary file (also following symbolic links), which would lead to incorrect information in the mdeviceID field of the information returned by currentMountPoints().

Later on the code tries to "resolve GVFS mount points" in line 382 [22]. The resolveGvfsMountPoints() function [23] that implements this logic looks for mount entries with "gvfsd-fuse" as source device name. For each of these mount points the function will list the mount's directory contents and look for directory entries of the form <type>:<label>, where type refers to the file system type that is expected to be found there. The function then synthesizes additional mount entries from this information which will be returned to the caller, appearing as fully-fledged regular mounts.

There are two problems with this. For one, these operations are all subject to race conditions; the mount table entries can change at any time. Secondly, there exists a common way for unprivileged users in Linux systems to create mount points with arbitrary source device names. This is the fusermount setuid-root utility, which is used for mounting FUSE file systems. Local users can create a fake gvfsd-fuse mount point like this:

$ export FUSECOMMFD=0 $ mkdir $HOME/mnt $ fusermount $HOME/mnt -ononempty,fsname=gvfsd-fuse $ mount | tail -n1 gvfsd-fuse on /home/$USER/mnt type fuse (rw,nosuid,nodev,relatime,userid=1000,groupid=100)

The default FUSE configuration prevents the root user from accessing non-root controlled FUSE file systems. To overcome this limitation, an attacker can perform the following steps:

- create a fake gvfsd-fuse mount like shown above. - trigger the unmount() logic in smb4k's mount helper. - attempt to unmount $HOME/mnt after currentMountPoints() obtained the mount information from libmount, but before it calls resolveGvfsMountPoints(). - place directories in this location that match the expected format e.g. something like cifs:mymount. These directories can already be placed there in advance, of course. - on success, the currentMountPoints() function will return a synthesized entry to the mount helper which lists a CIFS mount in the unprivileged user's $HOME/mnt/cifs:mymount.

Using this approach, the verification step in the mount helper's unmount() function can be bypassed even if issues 4.1) and 4.2) would be fixed.

There are further potential issues in the KMountPoint logic, e.g. in finalizeCurrentMountPoint() the source device name is resolved if the KMountPoint::NeedRealDeviceName flag is passed by the caller. This provides another opportunity for unprivileged FUSE mounts with fake source device names to influence the outcome, e.g. to perform file existence tests or otherwise trick the caller of the KIO library.

Due to these problems, the information obtained from currentMountPoints() currently cannot be used to base security related decisions on. Generally root should not perform these additional queries at all. The library could check for geteuid() == 0 to prevent the execution of this dangerous logic in privileged contexts.

For unprivileged applications we could imagine the addition of a flag like KMountPoint::AllowUnsafe, which opts in to the problematic behaviour. Only applications that are aware of the potential problems would then pass this flag.

When we reported this, KDE security at first stated that the problems described in this section would only affect smb4k and no other users of the KMountPoint API. We found it questionable to consider a library's API secure only based on its supposed current users. Beyond that, even unprivileged processes using this API might fall victim to other users in the system crafting gvfsd mount information. One could argue that there is an issue in the fusermount utility to begin with. The KMountPoint API is explicitly processing a FUSE-based file system, however, and thus it should be prepared to deal with the peculiarities this entails.

When we pointed out our continued concern to KDE security, it was suggested that we create an upstream issue, or ideally provide a bugfix ourselves. While we are happy to help where we can, the issue at hand is a larger API design topic, and we believe it should be dealt with carefully by the responsible upstream developers, allowing them also to learn from this experience. For this reason we only created the upstream issue [24], as was suggested to us.

4.4) Arbitrary Network Share Mounts can be Unmounted ----------------------------------------------------

Even if all the other issues discussed in this section would be fixed, the current mount helper code allows to unmount arbitrary Samba shares, no matter if they have been originally mounted by smb4k itself (for the same user or a different one), or by other components in the system (e.g. via a fixed entry in /etc/fstab).

Similarly to issue 3.1) above, we suggest to restrict smb4k mounts to a pre-defined location not controlled by unprivileged users to address this issue.

5) Other Remarks ================

5.1) Superfluous mhcommand Client Parameter ----------------------------------------------

Both helper actions compare an arbitrary path supplied by the client in mhcommand to the trusted "mount" or "unmount" program path returned from findMountExecutable() or findUmountExecutable(), respectively. This is odd. It seems this comparison is a remnant from the attempted fix of CVE-2017-8849. This is superfluous logic that increases the complexity of both client and helper unnecessarily and can cause confusion, at best.

The helper should choose the trusted mount program on its own and stop considering the mhcommand parameter at all.

5.2) Redundant "online check" Code ----------------------------------

There is a redundant check for online network interfaces in smb4kmounthelper.cpp line 38 [25] and line 205 [26]. This code should be placed into a separate function instead, to avoid code duplication and to increase readability.

This online check is also highly heuristic, and it might be possible for unprivileged users to influence its outcome e.g. by creating unprivileged pseudo network devices that appear to be online.

5.3) mount.cifs and umount Follow Symbolic Links ----------------------------------------------------

Both mount.cifs and umount follow symbolic links in path arguments. This means that even if the mount helper would try to verify a path pointing to a client-controlled location, this could be replaced with a symbolic link by the time the actual mount.cifs or umount utility runs, and the mount logic would then operate on a completely different location than expected by the helper.

6) Suggested Fixes ==================

Apart from the individual suggestions mentioned in the context of the issues above, we believe the range and severity of the issues uncovered shows that a major redesign of the mount helper utility is necessary to address all the problems in a robust way.

Here are some suggestions regarding a larger redesign:

- the helper should not allow mounting or unmounting of user provided paths at all. A dedicated directory like /mounts/smb4k, only controlled by root, should be used for these purposes. Some form of tracking which mount belongs to which user would be needed (e.g. giving ownership of the mount to the client that requested it). This is more like udisks [27] solves the problem of mounting devices on user request. - passing through arbitrary parameters from unprivileged clients to mount.cifs or umount won't work securely. A more abstract interface with well-defined settings for mounting or unmounting would help to restrict the degrees of freedom that a client has. This would also improve the decoupling of the helper's interface from the concrete implementation, this way the helper could e.g. change the implementation to call the mount() and umount() system calls directly, instead of going through the mount utilities.

7) Upstream Bugfix ==================

During the course of a month we discussed various versions of patches with the smb4k upstream developer, until we arrived at a workable patch [7] just in time for publication of this report after the 90 days maximum embargo period we offered. The main aspects of the bugfix are as follows:

- For mount and unmount the options passed by the client are now more closely scrutinized, and only settings present in a whitelist of options are allowed anymore. - The filemode mount option, which is still basically supported, is now checked to make sure no special file bits are present. - The uid and gid mount options can only be set to the UID/GID of the caller, not to arbitrary IDs anymore. - Network share mounts are now restricted to a directory hierarchy rooted in /run/smb4k. This way, unprivileged users can no longer place symlinks in the mount destination paths. Mounts are placed in per-UID subdirectories such that different clients cannot influence each other's mounts anymore. - For passing Kerberos credentials, clients now pass already open file descriptors to the mount helper, thereby avoiding any issues with regards to operating on untrusted paths. - The problematic KMountPoint API is no longer used and has been replaced by Qt's QStorageInfo API. Formally the investigation of existing mount points would no longer be necessary at all with the trusted mount tree location, but the upstream developer preferred to keep this extra verification step for the time being.

We want to express our thanks to Alexander Reinholdt, the smb4k upstream developer, for cooperating with us and finishing the patch in time for publication. This way a series of long-standing issues in smb4k could finally be addressed.

8) Possible Workarounds =======================

If the upstream bugfix cannot be used right away, the following suggestions can be considered to remove the attack surface described in this report:

- Raise the Polkit authentication requirements for the mount and unmount helper actions to authadmin. This way the problematic logic can only be reached by already privileged users. This contradicts the original purpose of smb4k, however, to allow unprivileged mounts and unmounts of network shares. - Restrict D-Bus access to the mount helper utility to members of an opt-in group like smb4k. Coupled with a security disclaimer, this would allow users that really want to use this feature to opt-in.

9) Reproducers ==============

The KAuth D-Bus interface cannot easily be invoked via utilities like gdbus, because it expects a serialized QVariantMap as input. We offer two C++ programs which can be used to perform standalone tests of smb4k's mount helper API for the purposes of reproducing the attack vectors described in this report, smb4kmount.cpp and smb4kunmount.cpp. There are comments in the source code of the reproducers that explain how to compile and use them. You can find them attached to this email.

10) CVE Assignment ==================

Formally the findings in this report could justify a large count of CVEs, but we decided to condense them into the two main aspects that result from the issues:

- CVE-2025-66002: local users can perform arbitrary unmounts via the smb4k mount helper due to lack of input validation. - CVE-2025-66003: local users can perform a local root exploit via the smb4k mount helper if they can access and control the contents of a Samba network share.

When the end of the 90 days maximum non-disclosure period we offered upstream approached, due to lack of feedback from KDE Security, we assigned these CVEs as we originally suggested them to upstream.

11) Coordinated Disclosure ==========================

We reached out to KDE security on September 11 and shared the full details about the issues described in this report, offering coordinated disclosure. For nearly the first two months of the maximum 90 days non-disclosure period, we had difficulties getting clear answers from KDE security about the expected publication date, whether they acknowledged the findings or even whether they wanted to practice coordinated disclosure at all.

We only saw some visible progress at the beginning of November, when the smb4k upstream developer joined the discussion and started developing bugfixes. The progress remained slow, however, due to limited resources on the end of the developer. Still, from this point onwards the discussion turned out helpful and cooperative, and we could finally see that the non-disclosure time was actually being put to use. We managed to agree on a bugfix that addresses all the issues only less than a week before the 90 days maximum embargo period would be reached.

In summary, we are not completely happy about how the coordinated disclosure developed in this case. We perceived an unwillingness on the end of KDE security to communicate and to help in coordinating the disclosure. We believe the issue could have been fixed faster by suggesting a workaround to users and by developing a bugfix in the open, with the help of the rest of the community.

12) Timeline ============

2025-09-11: We forwarded our report to security () kde org, offering coordinated disclosure. 2025-09-17: We received acknowledgement of receipt from KDE security. 2025-09-29: Not having heard anything else from upstream, we asked at least for a confirmation of the issues described in the report and a formal decision whether coordinated disclosure was desired. We asked to get feedback until October 2, lest we would publish the information on our end. 2025-10-01: We got a reply from KDE security that they were working on the issue, without answering our questions. We replied again and tried to clarify that we did not intend to put time pressure on upstream, but would like to clearly setup the coordinated disclosure process. 2025-10-02: We got a short reply that they could not give us an expected publication date, repeating again that they were working on the issue. Our questions pertaining the process still remained unanswered. We once more explained that we would like to be involved in reviewing potential bugfixes where we could offer our help, and that we would like to avoid non-disclosure time passing without any visible progress. 2025-10-07: KDE security informed us that the fix was moving forward without giving further details. 2025-11-07: The smb4k developer, Alexander Reinholdt, contacted us directly sharing a first batch of suggested bugfixes. 2025-11-12: We provided detailed feedback on the security relevant part of the patch, pointing out various problems that remained, and new problems that got introduced. 2025-11-12: KDE security chimed in about the KMountPoint topic, stating that smb4k would be the only privileged component using this API. 2025-11-13: We replied to KDE security explaining in more detail the remaining concerns we had regarding the KMountPoint API. 2025-11-16: The smb4k developer thanked us for the review of the patch, and sent back detailed comments on our input. He told us he would be working on a follow-up patch set. 2025-11-26: The smb4k developer informed us that it would take still more time for him to provide the improved version of the patch. 2025-11-26: We thanked the developer for his continued effort, but also reminded all participants that the end of the 90 days maximum non-disclosure period we offered was approaching in two weeks. We suggested the alternative of publishing a temporary workaround instead (like increasing authentication requirements), should a full bugfix be out of reach within the remaining time. We also suggested to involve the distros mailing list [28] at this time, to give other Linux and BSD distributions a chance to prepare before general publication of the report. 2025-11-27: On the topic of the KMountPoint API, KDE security clarified that they ideally would like a merge request from us addressing our concerns. 2025-11-28: We assigned the CVEs the way we initially suggested them to upstream, to provide them as additional information to the distros mailing list. We also shared the CVEs with upstream. 2025-11-30: The upstream developer shared an improved patch set with us. 2025-12-01: We sent another round of comments back to the upstream developer. The new patch was still lacking in a number of areas. 2025-12-01: We forwarded a draft of this report to the distros mailing list, announcing publication of the issues on 2025-12-10. We pointed out that no proper bugfix was available for sharing at this time. 2025-12-03: We received yet another version of the suggested patch from the upstream developer. 2025-12-04: This time we found no remaining security issues, agreed on the patch, but still commented on a couple of quality and style aspects. 2025-12-04: We forwarded the bugfix from the upstream developer to the distros mailing list. 2025-12-05: We asked the upstream developer to publish a bugfix release on 2025-12-10, which he agreed upon. 2025-12-10: Upstream published the bugfix release 4.0.5 [8] as planned. 2025-12-10: Publication of this report.

13) References ==============

- smb4k KDE Project [1] - smb4k 4.05 bugfix release [8] - upstream bugfix for the issues in this report [7] - SUSE Bugzilla review bug for smb4k [6] - Bug report against the KIO library regarding KMountPoint API issues [24]

[1]: https://invent.kde.org/network/smb4k.git [2]: https://security.opensuse.org/2025/12/10/smb4k-major-issues-in-kauth-helper.html [3]: https://bugzilla.suse.com/showbug.cgi?id=1033300 [4]: https://bugzilla.suse.com/showbug.cgi?id=1036244 [5]: https://bugzilla.suse.com/showbug.cgi?id=1036245 [6]: https://bugzilla.suse.com/showbug.cgi?id=1249004 [7]: https://invent.kde.org/network/smb4k/-/commit/0dea60194ab6eb8f6e34ca2e6cb0f97b90c46f1e [8]: https://sourceforge.net/p/smb4k/blog/2025/12/smb4k-405-security-bug-fix-release [9]: https://invent.kde.org/network/smb4k/-/tags/4.0.4 [10]: https://invent.kde.org/network/smb4k/-/blob/4.0.4/helpers/smb4kmounthelper.cpp?reftype=tags [11]: https://invent.kde.org/network/smb4k/-/blob/4.0.4/helpers/smb4kmounthelper.cpp?reftype=tags#L73 [12]: https://man7.org/linux//man-pages/man8/mount.cifs.8.html [13]: https://invent.kde.org/network/smb4k/-/blob/4.0.4/helpers/smb4kmounthelper.cpp?reftype=tags#L97 [14]: https://invent.kde.org/network/smb4k/-/blob/4.0.4/helpers/smb4kmounthelper.cpp?reftype=tags#L177 [15]: https://invent.kde.org/network/smb4k/-/blob/4.0.4/helpers/smb4kmounthelper.cpp?reftype=tags#L187 [16]: https://man7.org/linux/man-pages/man8/umount.8.html [17]: https://invent.kde.org/frameworks/kio [18]: https://invent.kde.org/frameworks/kio/-/tree/v6.17.0?reftype=tags [19]: https://invent.kde.org/network/smb4k/-/blob/4.0.4/helpers/smb4kmounthelper.cpp?reftype=tags#L163 [20]: https://invent.kde.org/frameworks/kio/-/blob/v6.17.0/src/core/kmountpoint.cpp?reftype=tags#L341 [21]: https://invent.kde.org/frameworks/kio/-/blob/v6.17.0/src/core/kmountpoint.cpp?reftype=tags#L365 [22]: https://invent.kde.org/frameworks/kio/-/blob/v6.17.0/src/core/kmountpoint.cpp?reftype=tags#L382 [23]: https://invent.kde.org/frameworks/kio/-/blob/v6.17.0/src/core/kmountpoint.cpp?reftype=tags#L267 [24]: https://bugs.kde.org/showbug.cgi?id=513176 [25]: https://invent.kde.org/network/smb4k/-/blob/4.0.4/helpers/smb4kmounthelper.cpp?reftype=tags#L205 [26]: https://invent.kde.org/network/smb4k/-/blob/4.0.4/helpers/smb4kmounthelper.cpp?reftype=tags#L38 [27]: https://github.com/storaged-project/udisks [28]: https://oss-security.openwall.org/wiki/mailing-lists/distros

-- Matthias Gerstner <matthias.gerstner () suse de> Security Engineer https://www.suse.com/security GPG Key ID: 0x14C405C971923553 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Jochen Jaser, Andrew McDonald, Werner Knoblich

The KDE Connect verification-code protocol before 2025-04-18 uses only 8 characters and therefore allows brute-force attacks. This affects KDE Connect before 1.33.0 on Android, KDE Connect before 25.04 on desktop, KDE Connect before 0.5 on iOS, Valent before 1.0.0.alpha.47, and GSConnect before 59.

In KDE Connect before 1.33.0 on Android, a packet can be crafted that causes two paired devices to unpair. Specifically, it is an invalid discovery packet sent over broadcast UDP.

In KDE Connect before 1.33.0 on Android, malicious device IDs (sent via broadcast UDP) could cause an application crash.

The KDE Connect protocol 8 before 2025-11-28 does not correlate device IDs across two packets. This affects KDE Connect before 25.12 on desktop, KDE Connect before 0.5.4 on iOS, KDE Connect before 1.34.4 on Android, GSConnect before 68, and Valent before 1.0.0.alpha.49.

In the KDE Connect information-exchange protocol before 2025-04-18, a packet can be crafted to temporarily change the displayed information about a device, because broadcast UDP is used. This affects KDE Connect before 1.33.0 on Android, KDE Connect before 25.04 on desktop, KDE Connect before 0.5 on iOS, Valent before 1.0.0.alpha.47, and GSConnect before 59.

In KDE Skanpage before 25.08.0, an attempt at file overwrite can result in the contents of the new file at the beginning followed by the partial contents of the old file at the end, because of use of QIODevice::ReadWrite instead of QODevice::WriteOnly.

In KDE Krita before 5.2.13, loading a manipulated TGA file could result in a heap-based buffer overflow in plugins/impex/tga/kistgaimport.cpp (aka KisTgaImport). Control flow proceeds even when a number of pixels becomes negative.

This vulnerability allows remote attackers to execute arbitrary code on affected installations of Krita. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2025-59820.

This vulnerability allows remote attackers to execute arbitrary code on affected installations of Krita. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2025-59820.

End of life: 2/17/2026, End of support: 2/17/2026, Latest version: 6.5.6

End of life: 10/21/2025, End of support: 10/21/2025, Latest version: 6.4.6

KDE Konsole before 25.04.2 allows remote code execution in a certain scenario. It supports loading URLs from the scheme handlers such as a ssh:// or telnet:// or rlogin:// URL. This can be executed regardless of whether the ssh, telnet, or rlogin binary is available. In this mode, there is a code path where if that binary is not available, Konsole falls back to using /bin/bash for the given arguments (i.e., the URL) provided. This allows an attacker to execute arbitrary code.

KDE Konsole before 25.04.2 allows remote code execution in a certain scenario. It supports loading URLs from the scheme handlers such as a ssh:// or telnet:// or rlogin:// URL. This can be executed regardless of whether the ssh, telnet, or rlogin binary is available. In this mode, there is a code path where if that binary is not available, Konsole falls back to using /bin/bash for the given arguments (i.e., the URL) provided. This allows an attacker to execute arbitrary code.

This issue affects systems where KTelnetService and a vulnerable version of Konsole are installed but at least one of the programs telnet, rlogin or ssh is not installed. The vulnerability is in KDE's terminal emulator Konsole. As stated in the advisory by KDE, Konsole versions &lt; 25.04.2 are vulnerable.

On vulnerable systems remote code execution from a visited website is possible if the user allows loading of certain URL schemes (telnet://, rlogin:// or ssh://) in their web browser. Depending on the web browser and configuration this, e.g., means accepting a prompt in the browser.

End of life: 6/17/2025, End of support: 6/17/2025, Latest version: 6.3.6

libarchiveplugin.cpp in KDE ark before 24.12.0 can extract to an absolute path from an archive.

End of life: 2/11/2025, End of support: 2/11/2025, Latest version: 6.2.5