Security Advisory 2025-12-16-1 - Dropbear privilege escalation via Unix domain socket forwarding (CVE-2025-14282)

A privilege escalation vulnerability has been discovered in the Dropbear SSH server affecting configurations where multiple local users are allowed to authenticate via SSH.

When processing TCP or Unix domain socket forwardings requested by an authenticated SSH client, Dropbear executes the forwarding operations as root, only switching to the logged-in user’s UID/GID after establishing the session shell. With the recently added support for Unix domain socket forwarding, this behavior allows any authenticated non-root SSH user to connect to arbitrary local root-owned Unix sockets as if they were the root user.

This bypasses file system permission checks as well as credential-based checks such as SO_PEERCRED / SO_PASSCRED, enabling the user to impersonate root to privileged daemons. On systems exposing privileged system sockets (e.g. OpenWrt's ubus), this can lead to full root compromise.

This issue is not exploitable without valid SSH credentials.

An attacker must meet all of the following conditions:

• Have valid SSH login credentials on the target OpenWrt system.
• Be permitted to use SSH forwarding features (enabled by default).
• The system must expose at least one privileged Unix domain socket whose peer authenticates based on effective UID/GID (e.g., SO_PEERCRED).

If these conditions are met, a malicious user can trigger Dropbear to connect to such sockets as root and issue privileged commands.

Typical OpenWrt deployments operate with only the root user account and do not create additional non-privileged SSH users. In such default configurations, this vulnerability has no practical impact, because the only available SSH user already has full privileges.

However, the vulnerability affects OpenWrt systems where additional local users with SSH access have been created.

Dropbear can disable all local (including Unix-socket) forwardings globally by adding the -j option to the server invocation.

Patch /etc/init.d/dropbear at runtime:

# Add -j to the dropbear invocation
sed -i 's#procd_set_param command "$PROG"#procd_set_param command "$PROG" -j#' /etc/init.d/dropbear
 
# Restart service
service dropbear restart
 
# Verify
ps w | grep dropbear

Expected output of the verification step:

root@OpenWrt:~# ps w | grep dropbear

 3620 root      1036 S    /usr/sbin/dropbear -j -F -P /var/run/dropbear.main.pid -p 22 -K 300 -T 3

This disables all local TCP forwardings (including Unix-domain socket forwarding) for all users, without needing a rebuild.

To disable forwarding only for specific keys, add the OpenSSH-style restriction in authorized_keys:

no-port-forwarding ssh-ed25519 AAAA...

This blocks:

• Local forwarding (-L)
• Remote forwarding (-R)
• Unix-socket forwarding

For keys that should not have any interactive capability, use:

restrict ssh-ed25519 AAAA...

`restrict` automatically implies:

• no-port-forwarding
• no-agent-forwarding
• no-X11-forwarding
• no-pty

This is the most restrictive option, suitable for automation keys or locked-down accounts.

To our knowledge:

• OpenWrt 24.10, 25.12 and Snapshots are technically affected, but not exploitable in default configuration (single root user).

Thanks to Turistu for the report, analysis, and proof-of-concept exploitation. Thanks to Matt Johnston, the maintainer of Dropbear, for his quick response and fixes.

• Original report and discussion: https://www.openwall.com/lists/oss-security/2025/12/16/4
• Dropbear commit introducing Unix domain socket forwarding: https://github.com/mkj/dropbear/commit/1d5f63c