A user allowed one command through sudo intercept can run denied programs through execveat.
Affects
sudo, the command-delegation and privilege-control utility used on Unix and Linux systems.
sudo's ptrace-based interceptor checked the execve family but not execveat, so a denied executable invoked through execveat — or through fexecve, which is implemented on top of it — runs without a policy check and without the subcommand logging that would have recorded it. It runs with the authorized command's runas identity, which in most real sudoers rules is root.
Detail and 4 sources
The upstream commit is explicit that sudo had deliberately allowed execveat through, and adds path resolution and intercept handling for it. The affected enforcement modes, intercept and log_subcmds, are optional — this only bites where someone chose them, which is to say where someone was specifically trying to contain a command they had to allow.
Chain to watch
Local account is permitted one specific command through sudo→↓That command starts under ptrace-based intercept or log_subcmds enforcement→↓A denied executable is invoked with execveat directly, or with fexecve→↓The interceptor performs no policy check and writes no subcommand log entry→↓The denied program runs with the sudo rule's runas identity→↓Whether the major distributions have shipped the execveat interceptor fix, and how long the window stays open for hosts that rely on intercept as their containment boundary.
Unverified chainTrack the distribution tracker entry for CVE-2026-82474 on your platform, and in the meantime test your own build by calling a denied binary through fexecve from inside an intercepted command.
The same brief, every morning. One email a day, nothing else.
Every finding here carries a source that was checked before it published. If something is wrong, write to admin@fullchain.sh — corrections are published on the day they affect.