CVE-2026-35535

What it actually does

This flaw is a local privilege-escalation issue in Sudo. Before invoking the configured mailer, Sudo attempts to drop privileges using setuid, setgid, or setgroups. In affected versions, failure of one of those privilege-dropping calls is not treated as a fatal error, so the mailer may execute with higher privileges than intended. If an attacker can cause or hit one of these privilege-drop failures and trigger Sudo mail notification behavior, they may be able to execute mailer-related code or influence mailer execution in a privileged context, potentially gaining root-level confidentiality, integrity, and availability impact. The high attack complexity reflects that exploitation depends on local conditions and reliably forcing or encountering the failed privilege transition.

Why it matters to the business

Successful exploitation can turn local access into full administrative control of a Unix-like system, allowing an attacker to read sensitive files, alter system configuration, install persistence, or disrupt services. The exposure is most relevant on systems where Sudo is installed and configured to send mail notifications, including Linux distributions and network/industrial appliances that embed Sudo such as affected Siemens SINEC OS and RUGGEDCOM products. Although EPSS is currently low, there is no known KEV listing, no reported ransomware use, and no public exploit maturity indicated, Sudo is widely deployed and privilege-escalation flaws can become high-value post-compromise tools once exploit details mature.

How an attack unfolds

An attacker first obtains local code execution or an interactive local shell on a system with an affected Sudo version. The attacker then identifies whether Sudo mail notification paths are enabled, such as notifications for authentication failures, unauthorized users, or other sudoers mail options. Next, the attacker triggers a Sudo code path that runs the mailer while also causing, racing, or relying on failure of setuid, setgid, or setgroups during the privilege drop. Because the vulnerable Sudo build does not stop execution when the privilege drop fails, the mailer can be launched with privileges that should have been removed. The attacker then abuses the privileged mailer execution context, configuration, environment, arguments, or adjacent mail handling behavior to gain elevated privileges or perform privileged actions. No named threat actors or active exploitation campaigns are currently associated with the provided data.

How to fix it

Upgrade Sudo to a vendor-fixed release that includes the upstream fix after 1.9.17p2, specifically the fix associated with upstream commit 3e474c2 or a downstream package that backports it. No exact fixed package versions were provided, so use operating-system, appliance, or vendor advisories for the authoritative fixed build for each affected platform. For Siemens SINEC OS and Siemens RUGGEDCOM RST2428P, apply the vendor firmware or OS update that includes the patched Sudo package when available. Where immediate patching is not possible, reduce exploitability by disabling unnecessary Sudo mail notification options, reviewing mailer configuration, limiting local shell access, restricting who can invoke Sudo, monitoring sudoers changes, and hardening local privilege boundaries. Do not rely on EPSS alone to defer remediation because this is a local privilege-escalation flaw in a highly prevalent security-critical utility.

How to confirm the fix worked

Confirm the installed Sudo build is no longer vulnerable by checking `sudo -V` and comparing the package version and vendor changelog against the advisory that includes the 3e474c2 fix or downstream backport. Validate that all images, appliances, containers, golden templates, and recovery media have the patched package, not only running hosts. Review `/etc/sudoers` and files under `/etc/sudoers.d/` for mail-triggering options such as `mail_always`, `mail_badpass`, `mail_no_user`, `mail_no_perms`, and the configured `mailerpath`. If mitigation was used, confirm unnecessary Sudo mail notifications are disabled and that the mailer path is trusted, root-owned, and not writable by non-privileged users. Re-run authenticated vulnerability scans or configuration management checks to verify affected Sudo versions are no longer present.

Typical attack path

1. Gain local access to a Unix-like host or appliance running an affected Sudo version.
2. Check the installed Sudo version and whether mail notification behavior is enabled in sudoers policy.
3. Trigger a Sudo event that invokes the configured mailer, such as a policy violation or failed authentication path that generates mail.
4. Cause or take advantage of a setuid, setgid, or setgroups failure during Sudo's privilege drop before mailer execution.
5. Abuse the mailer process running with unintended privileges to execute privileged actions or establish root-level control.
6. Cover tracks by modifying logs, sudoers/mail configuration, or artifacts created during exploitation.

How to detect it

To assess possible prior exploitation, review authentication and privilege-management logs such as `/var/log/auth.log`, `/var/log/secure`, journald entries for `sudo`, auditd records, EDR process telemetry, and mail subsystem logs. Focus on periods where Sudo generated mail notifications, unauthorized sudo attempts, or repeated failed authentication events, especially if followed by unexpected privileged process creation. Look for Sudo spawning mailer binaries such as `/usr/sbin/sendmail`, `/usr/lib/sendmail`, `mail`, or `mailx` with root privileges, particularly around errors mentioning setuid, setgid, setgroups, group list changes, or failure to drop privileges. Examine `/etc/sudoers` and `/etc/sudoers.d/` for recent changes enabling mail options or changing `mailerpath`. Correlate suspicious Sudo events with new setuid files, modified root-owned scripts, new cron/systemd persistence, unexpected SSH keys, package changes, or log tampering. Because no public exploit maturity or known threat actor activity is provided, detections should focus on behavioral anomalies rather than a single definitive exploit signature.

• /var/log/auth.log
• /var/log/secure
• /etc/sudoers
• /etc/sudoers.d/
• mail_always
• mail_badpass
• mail_no_user
• mail_no_perms
• mailerpath
• /usr/sbin/sendmail
• /usr/lib/sendmail
• /bin/mail
• /usr/bin/mail
• /usr/bin/mailx
• sudo: setuid
• sudo: setgid
• sudo: setgroups
• sudo: unable to setuid
• sudo: unable to setgid
• sudo: unable to set groups
• sudo: unable to run mailer
• COMMAND=/usr/sbin/sendmail
• COMMAND=/usr/lib/sendmail

What your security team should do

• Inventory all Linux, Unix-like, appliance, and embedded platforms using Sudo, including Siemens SINEC OS and RUGGEDCOM assets.
• Prioritize patching internet-managed, shared-user, jump-host, build, CI/CD, administrative, and OT-management systems where local access by many users or services is possible.
• Upgrade to a Sudo package containing the upstream 3e474c2 fix or the vendor-confirmed backport; track vendor-specific fixed versions where package versions differ from upstream.
• Temporarily disable nonessential Sudo mail notifications and verify the configured mailer path is root-owned and not writable by unprivileged users.
• Hunt for suspicious Sudo mailer executions, privilege-drop errors, sudoers changes, and unexpected sendmail/mail processes spawned near failed or unauthorized Sudo attempts.
• Restrict local shell access, remove unnecessary sudo privileges, and audit service accounts that can execute local commands.
• Add detection logic for Sudo invoking mailer binaries in unusual contexts or with unexpected parent/child process relationships.
• Monitor for future exploit publication or KEV status changes because Sudo privilege-escalation vulnerabilities often become useful post-exploitation tools.