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

Release and security announcements
1

Security Advisory 2025-12-16-1

Dropbear privilege escalation via Unix domain socket forwarding (CVE-2025-14282)

Description

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.

:warning: This issue is not exploitable without valid SSH credentials.

Requirements

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.

Impact

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 does affect OpenWrt systems where additional local users with SSH access have been created.

Mitigations

1. Runtime mitigation (server-wide): disable local forwarding

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 verification output:

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 requiring a rebuild.

2. Per-key mitigation: no-port-forwarding

To disable forwarding only for specific SSH 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

3. Stronger per-key mitigation: restrict

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

restrict ssh-ed25519 AAAA...

The restrict option automatically implies:

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

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

Affected Versions

To our knowledge:

  • OpenWrt 24.10, 25.12 and Snapshots are technically affected
  • Default installations are not exploitable due to single-user (root-only) setups

Credits

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

References

17 Likes
2

Stubby DNS over TLS uses local forwarding and I suspect by DNS resolution will fail when local forwarding is disabled. I’m comfortable relying on my ssh login credentials from a security standpoint

The commit linked above indicates additional Dropbear CVE’s which were fixed and given the key role Dropbear serves, hopefully there will be a new 24.10 release in the near future. I’m also unclear if the commit will affect Stubby DNS over TLS?

3

Not sure if we are talking about the same “local forwarding” concept here… This CVE is about SSH clients using socket forwarding to gain root privileges; does Stubby connects to the local host using SSH?

1 Like
4

Requests for DNS resolution are forwarded to Stubby. Essentially it enables your LAN to use your router’s IP for DNS resolution. Stubby can be configured to use whatever WAN DNS resolver you want - the default is to use CloudFlare.

5

Thanks for the summary it’s really helpful as this CVE was all over the internet tech news today. Also really appreciate you guys updating 24.10-snapshot with the backport fix so quickly.

6

Not related to the dropbear ssh daemon at all.

1 Like
7

Yes, that is how I understood it; then, it is not affected by the mentioned CVE.

8

Novice comment here, but is this a rare occasion where general good practice, i.e. setting up a non-root user for some operations, has had an unintended consequence of making a system less secure? To exploit it effectively becomes a privilege escalation (maybe not technically exactly that). Still, bottom line for most people like me who aren't completely savvy with this stuff is that if we have just stuck to root user access there's zero impact right? Love it that you guys seem to be on top of this, like the marvel heroes of the networking world! :wink:

Also did you let slip that it’s going to be a Christmas release this year… 25.12? Very exciting. As always, thank you to all the Devs and contributors for your hard work making this stuff work and keeping our networking safe. Merry Christmas all :slightly_smiling_face::santa_claus:t4:

9

It’s not exactly making a system less secure…

On default configurations, you only have a single user account, meaning this CVE has no real practical impact

If you create a new non-sudoer user (and assume both users share a similar level of hardening), you really don’t make your system more vulnerable, since on both scenarios credentials being leaked result in root access.

This is only true of course if both user accounts share the same level of security hardening, and aren’t shared with different people.