CVE-2026-82474: 
Wolfi vulnerability analysis and mitigation

CVE-2026-82474 is a policy bypass vulnerability in Sudo through version 1.9.17p2 that allows local users with limited sudo privileges to execute arbitrary denied programs by invoking the execveat(2) system call directly or through fexecve(3), bypassing both policy enforcement and audit logging. The vulnerability was disclosed on August 29, 2026, and affects all Sudo releases up to and including 1.9.17p2. It carries a CVSS v3.1 base score of 7.8 (High) and a CVSS v4.0 base score of 8.5 (High) (Github Advisory, VulnCheck). The vulnerability was discovered by the XlabAI Team of Tencent Xuanwu Lab and also independently reported by Nofil Qasim and Quentin Chalabi (Sudo Commit).

The root cause is classified as CWE-693 (Protection Mechanism Failure): Sudo's ptrace-based intercept mode in src/exec_ptrace.c handled execve(2) calls but did not apply the same intercept policy checks to the execveat(2) system call. This omission existed because Sudo itself uses fexecve(3) (which internally calls execveat) for its own fdexec setting, and the code was written to always allow execveat in intercept mode to support this use case. An attacker with a sudoers entry permitting specific commands can write a small program that calls execveat(2) directly (or uses fexecve(3)) with a file descriptor pointing to a denied binary, causing the kernel to execute it without Sudo's policy engine ever inspecting or logging the action. The fix resolves the path of the file descriptor via /proc to perform proper path-based policy checks on execveat calls (Sudo Commit, Github Advisory).

A local user who has been granted any sudo privilege (even a narrowly scoped one) can exploit this vulnerability to execute arbitrary programs that are explicitly denied by the sudoers policy, with no audit trail generated in sudo logs. This constitutes a full privilege escalation path: the attacker can run any binary — including shells or setuid utilities — as the target user (typically root), achieving complete confidentiality, integrity, and availability compromise of the affected system. Because the bypass also suppresses logging, defenders may have no record of the unauthorized execution, complicating incident response and forensic analysis (Github Advisory, VulnCheck).

As of the disclosure date (August 29, 2026), there is no confirmed public proof-of-concept exploit and no evidence of in-the-wild exploitation (Feedly). The EPSS score is reported as 0.0, reflecting the early stage of the vulnerability's public lifecycle. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires local access and at least one sudo privilege entry, limiting the attack surface compared to unauthenticated vulnerabilities, but the low complexity and high impact make it a significant privilege escalation risk on multi-user Linux systems.

1. Identify a target: Confirm the target system runs Sudo ≤ 1.9.17p2 with ptrace-based intercept mode enabled (i.e., intercept or log_subcmds options active in sudoers) and that the attacker has at least one sudo privilege entry.
2. Obtain a file descriptor to the denied binary: Open the target executable (e.g., /bin/bash) using open(2) to obtain a file descriptor. This does not require execute permission on the path itself — only read access or an already-open fd.
3. Craft the exploit program: Write a small C program (or use a scripting language with syscall access) that calls execveat(fd, "", argv, envp, AT_EMPTY_PATH) or uses fexecve(fd, argv, envp) to execute the denied binary via the file descriptor rather than a path.
4. Execute via sudo: Run the crafted program under sudo using the permitted command entry (e.g., sudo /path/to/exploit_binary). Sudo's ptrace intercept mode monitors execve but does not intercept the subsequent execveat call, so the denied binary executes without policy checks.
5. Achieve privilege escalation: The denied binary (e.g., a root shell) runs with the privileges granted by the sudo rule, bypassing all sudoers restrictions and generating no sudo audit log entry (Sudo Commit, Github Advisory).

• Logs: Absence of expected sudo log entries for commands executed by a user known to have sudo access; gaps in /var/log/auth.log or /var/log/sudo.log around times of suspicious activity.
• Process: Unexpected privileged processes (e.g., root shells, interpreters) spawned by a user account that should only have limited sudo access; processes with elevated UIDs that do not correspond to logged sudo invocations.
• File System: Presence of small compiled binaries or scripts in user-writable directories that make direct execveat or fexecve syscalls; unusual files in /tmp, /dev/shm, or home directories with execute permissions.
• System Calls: Audit framework (auditd) records showing execveat syscalls from non-root users that are not preceded by a corresponding sudo policy check event; AT_EMPTY_PATH flag usage in execveat calls from user processes.

The sudo project has issued a patch (commit 71fbe42) that adds proper intercept and log_subcmds support for execveat(2) by resolving file descriptors to paths via /proc before applying policy checks. Administrators should upgrade Sudo to a version incorporating this fix as soon as it is available in their distribution's package repositories (Sudo Commit). As an interim workaround, consider disabling the intercept and log_subcmds sudoers options if they are not strictly required, which removes the ptrace-based intercept mode entirely and eliminates the attack surface. Additionally, review and minimize sudo privilege grants to reduce the number of users who could exploit this bypass, and enable Linux auditd rules to log execveat syscalls for anomaly detection (Github Advisory).

The vulnerability was assigned by VulnCheck and received initial coverage from automated vulnerability tracking feeds and social media accounts shortly after disclosure on August 29, 2026. Posts appeared on Mastodon (via @RedPacketSecurity and @thehackerwire) and Bluesky, reflecting routine community monitoring of new sudo CVEs. No major vendor statements or in-depth researcher blog posts had been published at the time of this report.