Summary
sudo2shell is a logic flaw in sudo, the privilege management utility shipped by default on nearly every Linux distribution, macOS, and most BSDs. It allows a local, authenticated user to execute arbitrary commands with an effective UID of 0.
The vulnerability does not rely on memory corruption, race conditions, or environment variable manipulation. Exploitation is deterministic, works on every architecture we tested, and leaves no crash artifacts. In our testing it succeeded on 4,000 out of 4,000 attempts.
We estimate that over 100 million systems are exposed in their default configuration.
Severity
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H · Base score 8.8. The sudo2shell team assesses real-world severity as Critical due to the vulnerability's prevalence and the ease of exploitation. The vendor has not provided a score.
Technical Details
sudo is installed setuid-root. On invocation, it consults the configured policy plugin (by default, sudoers.so) to decide whether the requesting user may run the requested command as the target user.
When the calling user matches a rule such as:
%sudo ALL=(ALL:ALL) ALL
and successfully authenticates through PAM, the policy plugin returns a command_info list containing runas_uid=0. sudo then sets its real and effective UIDs to 0 and calls execve() on the user-supplied command. The command runs as root.
Because the command is entirely attacker-controlled, any binary may be supplied, including an interactive shell. sudo performs no further validation of the attacker's intent.
The relevant code path has existed in some form since the original 1980 implementation and has been carried forward through every major rewrite.
Am I Affected?
Run the following command as any non-root user:
$ sudo -l
If the output contains a line similar to (ALL : ALL) ALL, the host is vulnerable and the current user can exploit it.
If the output instead reads jsmith is not in the sudoers file. This incident will be reported., you are not affected. Santa has been notified.
| Platform | Default exposure | Fixed version |
|---|---|---|
| Ubuntu / Debian | First user created at install (sudo group) | None |
| Fedora / RHEL / Rocky / Alma | Members of wheel | None |
| Arch Linux | Whoever followed the wiki | None |
| macOS | Members of admin | None |
| FreeBSD / NetBSD | When installed from ports or pkgsrc | None |
| Cloud images (AWS, GCP, Azure) | Default user, typically with NOPASSWD | None |
Cloud images are exposed in a configuration that skips authentication entirely. This variant is tracked separately as sudo2shell-NP.
Proof of Concept
To give organizations time to remediate, we are withholding the full exploit for 90 days. A minimal reproduction is shown below.
jsmith@prod-db-01:~$ id uid=1000(jsmith) gid=1000(jsmith) groups=1000(jsmith),27(sudo) jsmith@prod-db-01:~$ █ [sudo] password for jsmith: root@prod-db-01:~# id uid=0(root) gid=0(root) groups=0(root) root@prod-db-01:~#
Alternate primitives identified during research: sudo -s, sudo su -, sudo bash, sudo vim followed by :!sh, and sudo !!.
Indicators of Compromise
The following indicators have been observed on hosts with confirmed sudo2shell activity. Defenders should hunt for these across their environment.
| Type | Indicator | Notes |
|---|---|---|
| File | /usr/bin/sudo | SUID root binary (mode 4755). Present on most compromised hosts prior to compromise. |
| Log | sudo: <user> : TTY=pts/0 ; PWD=/home/<user> ; USER=root ; COMMAND=/bin/bash | Written to /var/log/auth.log or /var/log/secure. The exploit logs itself. |
| Log | pam_unix(sudo:session): session opened for user root(uid=0) by <user>(uid=1000) | Visible via journalctl _COMM=sudo. |
| File | /run/sudo/ts/<user> | Credential cache. Allows repeat exploitation without re-authentication for 15 minutes (default). |
| File | ~/.sudo_as_admin_successful | Zero-byte marker file dropped on first successful run (Debian/Ubuntu). |
| Process | sudo → bash (euid 0) | Interactive root shell spawned as child of sudo. Parent process is typically the user's own shell. |
| Config | %sudo ALL=(ALL:ALL) ALL | Found in /etc/sudoers. Appears to grant the access. Origin under investigation. |
| Group | sudo, wheel, admin | Membership strongly correlated with exploitation. |
| Network | None observed | No C2 traffic identified. Exploit operates entirely locally. |
| SHA-256 | Varies by distribution | Hash matches vendor-signed package. Threat actor may have compromised the supply chain in 1980. |
FAQ
Is this a real vulnerability?
It has a logo, a domain name, and a CVSS score. What more do you need?
Why does it need a website?
All serious vulnerabilities have websites. That is how you know they are serious.
Isn't this just how sudo works?
That's exactly what an attacker would say.
Does it affect Windows?
Windows users are protected by a defense-in-depth control known as "clicking Yes on the UAC prompt," which is completely different.
Can I use the logo?
Yes. The logo is free to use in slides, risk reports, and vendor marketing.
How was this discovered?
By reading man sudo. Responsible disclosure prevents us from naming the section.
Is this related to Terminal2Shell?
Yes. Terminal2Shell provides initial access; sudo2shell provides privilege escalation. Chained together, they give an attacker full root access starting from nothing but an open terminal. Defenders should treat them as a single campaign.
Should I panic?
Check with your CISO first. They may already have scheduled the panic for Thursday.
Credits
Discovered by Adam Rice, Chief Senior Staff Principal Vulnerability Researcher and sole member of the sudo2shell Research Team, who has typed sudo an estimated 40,000 times before noticing anything was wrong. His previous work includes 3389rocks.com, a campaign for bringing Remote Desktop back to the open internet, where it belongs.
We thank the sudo project for more than four decades of consistent, well-documented behavior.