Sudo CVE-2026-96512 Explained: TZ Variable Time Bypass

Q: How do I check if my sudoers file is affected?

Run grep -rE 'NOT(BEFORE|AFTER)=' /etc/sudoers /etc/sudoers.d/ on any system where you administer sudo. If nothing comes back, this bug has nothing to bite on, since your rules don't use time restrictions at all. If something does come back, check whether those timestamps end in a Z.

Most sudo vulnerabilities I have read about involve memory corruption, a chroot edge case, or a parsing bug deep in a file few people ever look at. CVE-2026-96512 is a different kind of bug. It does not corrupt anything or parse anything wrong. It just asks sudo what time it is, and it turns out sudo will believe whatever you tell it, because it is reading the answer from an environment variable the local user controls in the first place.

What sudo actually checked, and what it trusted instead

Since version 1.8.20, sudo has supported time-bound access: a sudoers rule can carry a NOTBEFORE or NOTAFTER timestamp, so a contractor's elevated access expires on a specific date, or a maintenance window only opens during a scheduled change. It is a genuinely useful feature for exactly the kind of least-privilege, time-boxed access that shows up in every hardening checklist.

The function that reads those timestamps, parse_gentime(), hands the work of computing the current time to the C library's mktime(), and mktime() reads the process's TZ environment variable to know which timezone it is working in. Sudo is a setuid-root binary, which means it starts out running with elevated privilege while still holding onto the environment variables the invoking user handed it. Nothing strips TZ before that time check runs. A user who already has an account and a sudo rule with a time restriction can set TZ to an extreme value, something like TZ=XXX24, before running their sudo command, and shift sudo's internal notion of the current time by roughly 25 hours in either direction. An access grant that expired yesterday can look like it is still valid. A grant that does not start until tomorrow can look like it already started.

The part that keeps this from being worse than it sounds

It is worth being precise about what this bug is not, because the CVE number alone makes it sound scarier than the mechanics support. It does not bypass the sudo password prompt, and it does not touch PAM. There is no path here for an outside attacker to get onto a box, and no path for a logged-in user with zero sudo access to suddenly gain any. The person exploiting this needs two things already in place: a valid login, and an existing sudoers entry for them that happens to use NOTBEFORE or NOTAFTER. Take either one away and the bug has nothing to work with.

That is a narrower blast radius than most 7.8-scored bugs carry, and it is probably why this one has not shown up on CISA's Known Exploited Vulnerabilities list the way the Cisco ISE flaw I covered last week did. But narrow is not the same as unimportant. Time-boxed sudo access exists specifically for situations where an organization wants to be strict about exactly when elevation is allowed, contractor offboarding dates, change-window enforcement, break-glass accounts that should only work during an incident. Those are precisely the controls a security team would notice failing last, since nobody is watching a sudo timestamp the way they watch a login attempt.

Why this scored a 7.8, not higher or lower

The published CVSS 3.1 vector is AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Broken down, that is a local attack vector, low complexity to pull off, low privileges required to start, no user interaction beyond the attacker's own command, and a full compromise of confidentiality, integrity, and availability once it lands, because the reward is arbitrary command execution as root. The two things holding it below a 9 or 10 are the attack vector being local rather than network-reachable, and privileges required being low rather than none. Compare that to the Cisco ISE bug's perfect 10.0, which needed no authentication and no local access at all. Same general category, root-level compromise, very different starting line.

Who needs to act, and what the fix actually is

Sudo versions 1.8.20 through 1.9.17p2 carry the bug, which is most Linux distributions currently in support, since that range covers roughly a decade of releases. The check that matters more than your version number, though, is whether you use time-bound sudoers rules at all. If nothing in your sudoers file uses NOTBEFORE or NOTAFTER, this bug has no rule to manipulate, version number aside.

Situation	What to do
No NOTBEFORE/NOTAFTER in sudoers	Nothing urgent; the bug has no rule to exploit
Timestamps already end in Z	Already safe; UTC is explicit, TZ manipulation does nothing
Timestamps without a Z suffix	Add the Z to every NOTBEFORE/NOTAFTER entry now
Any of the above	Apply the upstream sudo update once your distro ships it

Sudo's maintainer, Todd Miller, committed a proper fix on August 29, 2026, one day after researcher Ermenson Junior reported the issue, which is about as fast as an upstream turnaround gets. The commit strips TZ out of sudo's own working environment before it computes any time value, so a future mktime() call has nothing attacker-controlled left to read. That fix will land in your distribution's next sudo package update, whenever that ships.

Until then, the workaround does not need a package update at all. Run this on anything you administer:

grep -rE 'NOT(BEFORE|AFTER)=' /etc/sudoers /etc/sudoers.d/

If a result comes back without a trailing Z on the timestamp, add one, so NOTAFTER=20261231235959 becomes NOTAFTER=20261231235959Z. That forces an explicit UTC interpretation, which removes the ambiguity the entire bug depends on. It costs one character and a visudo edit, and it closes the hole before the patched package ever arrives.

The habit this bug is really pointing at

I don't run production sudoers policies with time restrictions in my own home lab, so this one doesn't touch anything I've built directly. But it is a good reminder of a pattern that shows up constantly in security work: a control that looks airtight on paper, an access grant that expires on a schedule, can still be undone by a completely unrelated piece of the system that nobody thought to scope down, in this case an environment variable that has nothing to do with authorization on its face. When I was working through the Lynis and rkhunter audit on my own Ubuntu box, the recurring lesson was the same shape: the risky gap is rarely the thing you were explicitly checking, it's the assumption sitting quietly underneath it. Here, the assumption was that a setuid-root process's notion of "now" could be trusted. It couldn't, not without stripping the one variable a local user was always free to set.

Frequently asked questions

What is CVE-2026-96512?

It is a vulnerability in sudo, versions 1.8.20 through 1.9.17p2, where a local user who already has some sudo access can manipulate the TZ environment variable to trick sudo's time-based authorization checks. It carries a CVSS score of 7.8 and is tracked under CWE-863, incorrect authorization.

Does CVE-2026-96512 let an attacker skip the sudo password?

No. It does not touch password authentication or PAM at all. The attacker needs to already be a logged-in, authenticated user who has been granted some sudo privilege that happens to carry a NOTBEFORE or NOTAFTER time restriction. What it breaks is the time window around an access grant that already exists, not the grant itself.

Is CVE-2026-96512 being actively exploited?

There is no report of it being used in the wild as of this writing, and it has not been added to CISA's Known Exploited Vulnerabilities catalog. It was responsibly reported to the sudo maintainer, who committed a fix within a day. That said, a working technique and a CVE number being public is usually enough reason to check your own sudoers file rather than wait.

How do I check if my sudoers file is affected?

Run grep -rE 'NOT(BEFORE|AFTER)=' /etc/sudoers /etc/sudoers.d/ on any system where you administer sudo. If nothing comes back, this bug has nothing to bite on, since your rules don't use time restrictions at all. If something does come back, check whether those timestamps end in a Z.

What is the fix for CVE-2026-96512?

Two separate things. Upstream, the sudo maintainer removed the TZ variable from sudo's own environment before it computes time, so a future release closes the bug for good. Right now, before that release reaches your distribution, you fix any sudoers rule missing a trailing Z on its NOTBEFORE or NOTAFTER timestamp, which forces UTC and removes the ambiguity the whole bug depends on.

Why does adding a Z to a timestamp fix a security bug?

Because the vulnerability only exists in the gap between an unspecified timezone and sudo asking the C library what time it currently is. A timestamp written as NOTAFTER=20261231235959 has no timezone attached, so sudo falls back on whatever TZ variable is sitting in the environment, and a local user controls that variable. NOTAFTER=20261231235959Z is explicit UTC, so there is no ambiguity left for a fake TZ value to exploit.