How to Fix CVE-2021-3156 Sudo Baron Samedit (Linux Sudo Privilege Escalation)

CVE-2021-3156 (Baron Samedit) is a heap-based buffer overflow in sudo that lets any local user, even one not listed in sudoers, gain root through sudoedit -s. Fix it by upgrading sudo to 1.9.5p2 or later, or to your distribution’s patched package (RHSA-2021:0221 on RHEL 7), then confirm with sudoedit -s / and a credentialed rescan.

What the scanner is actually detecting

Nessus reports this vulnerability under several plugin names depending on the distribution it identifies. All of them are local checks, so they only appear in credentialed (SSH) scans, and all of them point to the same CVE and the same fix.

Plugin 146799 is the generic Linux check. Tenable describes the flaw as affecting “Sudo before 1.9.5p2” and requires local checks to be enabled on a Linux host. Plugins 145497 and 145519 compare the installed sudo package against Red Hat advisory RHSA-2021:0221; Tenable notes that the CentOS plugin relies on the package’s self-reported version rather than testing the flaw directly. Seeing two of these on one host is normal and does not mean two separate problems.

The underlying bug is in how sudo removes escape characters from command-line arguments. When sudo runs as sudoedit with -s and an argument ends in a single backslash, sudo copies past the end of a heap buffer. The sudo project lists affected versions as 1.7.7 through 1.7.10p9, 1.8.2 through 1.8.31p2, and 1.9.0 through 1.9.5p1, with fixes in 1.8.32 and 1.9.5p2.

Real-world risk

This is a local privilege escalation, not a remote exploit. CVSS v3 rates it 7.8 (AV:L/AC:L/PR:L), meaning an attacker already needs to run commands on the host as some user. What makes it serious is how low that bar is:

• The user does not need to be in /etc/sudoers and does not need to know any password. The sudo project states that only the presence of the sudoers file is required.
• Qualys, who found it, reports the bug was introduced in July 2011, affected sudo in its default configuration, and was exploited in their research on Ubuntu 20.04, Debian 10 and Fedora 33.
• Tenable lists public exploit modules for Metasploit, CANVAS and Core Impact.
• CVE-2021-3156 is in the CISA Known Exploited Vulnerabilities catalog, with a federal remediation due date of April 27, 2022. See our guide to the CISA KEV catalog for what that listing means for prioritization.

In practice, the risk is highest on multi-user systems (shell servers, jump hosts, build machines) and on any server running a web application or service account that could be compromised. A web shell running as a low-privileged service user becomes root in one step. On a single-purpose host where only administrators log in, the exposure is lower but the fix is still a routine package update, so there is little reason to defer it.

How to confirm it on the host

Start with the installed package version:

# RHEL, CentOS, Fedora
rpm -q sudo

# Debian, Ubuntu
dpkg-query -W sudo

# Upstream version string reported by sudo itself
sudo -V | head -n 1

Distribution packages carry backported fixes, so the upstream version number alone is not conclusive. Check the package changelog for the CVE:

# RHEL, CentOS, Fedora
rpm -q --changelog sudo | grep CVE-2021-3156

# Debian, Ubuntu (the glob also covers sudo-ldap)
zgrep CVE-2021-3156 /usr/share/doc/sudo*/changelog.Debian.gz

Then run the functional test published by the sudo project. Run it as a non-root user; it does not exploit anything:

sudoedit -s /

• Vulnerable: an error that starts with sudoedit:, such as sudoedit: /: not a regular file, or a password prompt (press Ctrl+C to exit).
• Patched: a usage message that starts with usage: sudoedit [-AknS] ...
• Partially patched: sudoedit: invalid mode flags from sudo front end: 0x20002 means the sudoers plugin was updated but the sudo front end was not. Finish the package update.

How to fix it

There is no configuration setting that closes this bug. The sudo project states that no workaround exists and the only fix is upgrading. The patched versions per platform are:

Any later package from the same repository also contains the fix. RHEL EUS, AUS and ELS streams have their own errata (RHSA-2021:0219, RHSA-2021:0220 and RHSA-2021:0222 through RHSA-2021:0227) with lower version strings, for example sudo-1.8.23-4.el7_7.3 on RHEL 7.7 EUS or sudo-1.8.29-5.el8_2.1 on RHEL 8.2 EUS. On those hosts, check the changelog for CVE-2021-3156 instead of comparing version numbers against this table.

RHEL 7 and CentOS 7

sudo yum update sudo
rpm -q sudo

The CentOS plugin names both sudo and sudo-devel. If sudo-devel is installed, update it in the same transaction: sudo yum update sudo sudo-devel.

CentOS 7 is end of life (June 30, 2024). Its default mirrors are gone, so yum update sudo fails with a mirror resolution error on an unpatched host. The fixed build sudo-1.8.23-10.el7_9.1 and the later el7_9.2 and el7_9.3 builds are still on the CentOS vault at https://vault.centos.org/7.9.2009/updates/. Point the base and updates baseurl entries in /etc/yum.repos.d/CentOS-Base.repo at vault.centos.org/7.9.2009 (and comment out mirrorlist), or download and install the RPM directly, then plan a migration to a supported release.

RHEL 8

sudo dnf update sudo
rpm -q sudo

Debian and Ubuntu

sudo apt update
sudo apt install --only-upgrade sudo
dpkg-query -W sudo

Hosts that use LDAP-backed sudoers run the sudo-ldap package instead. Ubuntu shipped fixes for both at the same versions, so upgrade whichever one dpkg -l 'sudo*' shows as installed.

Debian 10 (buster) has been removed from the regular mirrors. apt update reports a missing Release file and --only-upgrade sudo installs nothing. The buster security archive now lives at http://archive.debian.org/debian-security and carries sudo 1.8.27-1+deb10u6, which includes the deb10u3 fix. Comment out the dead buster entries in /etc/apt/sources.list, add the archive as a source and upgrade:

echo 'deb http://archive.debian.org/debian-security buster/updates main' | sudo tee /etc/apt/sources.list.d/buster-security-archive.list
sudo apt update
sudo apt install --only-upgrade sudo

Treat this as a stopgap and plan an upgrade to a supported Debian release.

Source-built or vendor-bundled sudo

If sudo was compiled from source (often under /usr/local/bin), the package manager will not touch it. Rebuild from sudo 1.9.5p2 or later. Run which -a sudo sudoedit to make sure no older copy sits earlier in the PATH.

If you cannot patch today

Red Hat’s systemtap mitigation (RHSB-2021-002) disables the vulnerable sudoedit path while normal sudo keeps working. It needs the systemtap and yum-utils packages plus debuginfo packages (kernel debuginfo on RHEL 7, sudo debuginfo on RHEL 6 and 8), and it must be reloaded after each reboot unless you set it up as a service. Do not remove the sudoedit symlink instead; Red Hat states this is not a sufficient mitigation. Treat the script as a stopgap for a specific maintenance delay, not a remediation. End-of-life releases often still have a fixed package in the vendor archive (see the CentOS 7 and Debian 10 notes above). Only releases for which a fixed package was never published have no vendor fix and need an upgrade path.

How to verify the fix and rescan

1. As a non-root user, run sudoedit -s / again. You should now see the usage: message.
2. Confirm the package: rpm -q --changelog sudo | grep CVE-2021-3156 on RPM systems, or dpkg-query -W sudo compared against the table above on Debian and Ubuntu.
3. Rerun the credentialed Nessus scan against the host. The RHEL and CentOS advisory plugins (145497, 145519) should no longer report. Tenable does not document how the generic plugin 146799 handles backported builds, so if it still reports on a host whose changelog lists CVE-2021-3156 and whose sudoedit -s / prints usage:, handle it as a backport false positive and document it. In the Nessus Scan Information output (plugin 19506), check that credentialed checks show as yes; if the SSH login failed, local plugins simply do not run and the finding disappears for the wrong reason. Our Linux authenticated scan setup guide covers the SSH and privilege settings.

sudo is not a daemon, so there is no service to restart and no reboot is needed. Each new sudo invocation loads the updated binary.

What can break and how to roll back

The sudo update is usually uneventful, but a few things are worth planning for:

• Locally edited /etc/sudoers. Package managers keep a modified sudoers file. RPM may write the packaged version alongside it (for example /etc/sudoers.rpmnew), and dpkg may prompt about the changed configuration file during an interactive upgrade. Validate the result with sudo visudo -c.
• Locking yourself out. Keep a root shell or console session open while updating sudo on remote hosts, so a broken sudoers file or package does not leave you without privileged access.

If sudo itself is what broke, you cannot use it to roll back. Run these commands as root from the root shell or console session you kept open. On RHEL or CentOS, find the transaction and undo it:

yum history list sudo
yum history undo <transaction-id>

On Debian or Ubuntu, reinstall a specific earlier version: apt install sudo=<previous-version>. Both methods need the previous RPM or .deb to be available locally (in the package cache or a saved copy) or in an enabled repository. The Debian and Ubuntu security pockets usually keep only the latest build, so save the old package before upgrading if you may need it. Rolling back reintroduces CVE-2021-3156, so do it only long enough to fix whatever broke.

Common false positive reasons

• Backported fixes and version comparison. RHEL 7’s fixed package is still labelled 1.8.23, well below 1.9.5p2. If a check compares only the upstream version, a patched host can still be flagged. When the changelog lists CVE-2021-3156 and sudoedit -s / prints a usage message, the host is fixed. See why backported patches trigger false positives for how to document this.
• Stale results. The report predates the update, or the rescan used a scan policy without credentials.

Some findings look false but are real: a second, older sudo binary elsewhere in the PATH, an updated sudo package while sudo-ldap or sudo-devel was left behind, or a front end and sudoers plugin at different versions (the 0x20002 message above).

FAQ

Can CVE-2021-3156 be exploited remotely?

No. The attacker needs local code execution as some user first. It is typically chained after a web application compromise, stolen SSH credentials or a malicious local account.

Does the user need sudo rights to exploit it?

No. The sudo project states that the user does not need to be listed in sudoers or authenticate. Any local account is enough.

Do I need to reboot after updating sudo?

No. sudo runs fresh on each invocation, so the patched binary is used immediately after the package update.

Is it safe to run sudoedit -s / on production?

Yes. It is the vendor’s detection test and only prints an error or usage message. It does not trigger the overflow.

Tracking this finding across many hosts

On a large Linux fleet, the hard part is proving every host is closed rather than patching one. SITEY, a self-hosted vulnerability management platform, imports Nessus results from an uploaded .nessus export and supports per-finding retest for Nessus, so each host can be rechecked after the fix. Its AI can draft host-specific remediation scripts that run only after human approval, deployed by its agents on Linux endpoints, followed by a retest to verify closure.

Sources

• sudo project: security advisory for CVE-2021-3156
• Tenable: Nessus plugin 146799, Linux Sudo Privilege Escalation (Out-of-bounds Write)
• Tenable: CVE-2021-3156
• Red Hat: RHSA-2021:0221 sudo security update
• Ubuntu: USN-4705-1 sudo security notice
• Red Hat: RHSB-2021-002 bulletin with systemtap mitigation and per-stream errata
• Debian: DSA-4839-1 sudo security update