Blog

The NetworkManager project reported an issue in NetworkManager and most VPN plugins, including the one provided by the strongSwan project, which potentially allows using the credentials of other local users.

Accessing Other User's Credentials

A VPN connection in NetworkManager may contain paths to local credentials such as certificates and private keys. Because strongSwan's NetworkManager plugin charon-nm runs as root, it will generally be able access these paths even if they don't belong to the user who created or initiated the connection. So user A might be able to authenticate with the credentials that belong to user B if they are accessible locally. Affected are all strongSwan versions.

Note that patches to NetworkManager and libnm are necessary to prevent some of these attacks.

CVE-2025-9615 has been assigned for this vulnerability.

Filesystem Access as Root

Because the daemon charon-nm, that is invoked by NetworkManager via D-Bus, generally runs as root, filesystem permissions are not taken into account when it accesses local files. This allows a user to configure the path to a credential owned by a different local user in order to potentially authenticate as that user.

There are two types of connections in NetworkManager, system-wide and private (those with connection.permissions set to a specific user), which both are affected differently and require different fixes.

System-wide connections, by definition, should be able to use files non-privileged users might not have access to. However, with the mentioned patch to NetworkManager, only admin users (those in e.g. the wheel or sudo group) will be able to create system-wide connections. This was previously allowed for non-privileged users as well if NetworkManager was configured that way at build time. See below for strongSwan-specific changes if such connections use authentication via ssh-agent.

To prevent exploiting this issue with private connections, charon-nm and the NetworkManager-strongswan GUI change the following things, depending on how the private key is stored:

• If the private key is stored in a file, a new function (nm_utils_copy_cert_as_user), provided by patched versions of libnm, is called to ensure that the file is accessible by the user set in the config. The function is also used to access certificates configured in the config. The service file that's shipped with the GUI announces this ability via supports-safe-private-file-access property, which is required so patched versions of NetworkManager won't reject loading the plugin.
• If the private key is stored in ssh-agent, the agent plugin connects to the socket that's determined via SSH_AUTH_SOCK as user that provided that path via auth-dialog (which is part of the GUI). This approach is also used for system-wide connections. charon-nm additionally prevents that cached socket paths from previous connection attempts are reused (NetworkManager stores the last path that was provided).

Remote code execution is not possible due to this issue.

As mentioned in the introduction, thanks to the NetworkManager team for reporting this vulnerability responsibly.

Mitigation

There is no issue on systems that are only used by a single user.

Storing the private key on a smart card/token is the safest mitigation for this issue if multiple users share the system. Because even if it's currently plugged in, the private key is usually protected by a PIN.

Similarly, if the private key is stored in a file that's protected with a strong password, other users won't be able to just use it unless they know the password.

If the private key is stored in ssh-agent, it can only be accessed by other users if the key is currently unlocked, which usually means multiple users have to be logged in concurrently.

The just released strongSwan 6.0.4 and NetworkManager-strongswan 1.6.4 fix this vulnerability. For older releases, we provide  patches that fix the vulnerability and should apply with appropriate hunk offsets (patches for versions before 5.8.3 and 1.5.0, respectively, are currently not provided). As mentioned, NetworkManager and libnm require patches as well.