CVE-2026-72693: 
Rocky Linux vulnerability analysis and mitigation

CVE-2026-72693 is a local privilege escalation vulnerability in openvt (part of the kbd package) caused by an incorrect TTY ownership check that can allow an unprivileged local user to achieve passwordless root login. The flaw was reported on April 26, 2026, and publicly disclosed on August 11, 2026. Affected products include the kbd package across Red Hat Enterprise Linux 7, 8, 9, and 10, Red Hat OpenShift Container Platform 4 (via rhcos), and Red Hat Hardened Images (fixed in kbd-2.10.0-2.hum1). It carries a CVSS v3.1 base score of 7.8 (High), assigned by Red Hat as the CNA (Red Hat CVE, Red Hat Bugzilla).

The root cause (CWE-284: Improper Access Control) lies in the authenticate_user() function in src/openvt.c. When openvt -u iterates over /proc/<pid>/fd/0 entries to identify the VT owner, it calls stat() on the symlink, which follows the link to the underlying TTY device node — returning the TTY node's st_uid rather than the owning process's UID. The vulnerable code pattern is:

sprintf(filename, "/proc/%s/fd/0", dentp->d_name);
if (stat(filename, &buf)) continue;
if (buf.st_dev == console_dev && buf.st_ino == console_ino && buf.st_uid == console_uid)
    goto got_a_process;

After a user logs out, TTY ownership reverts to root or the getty owner; if an unprivileged process still holds fd 0 on that TTY, the check incorrectly matches it as privileged, and openvt then executes execlp("login", "login", "-f", username, NULL) — a passwordless login as the selected user. Exploitation requires a non-default kbrequest/init configuration (e.g., kb::kbrequest:/usr/bin/openvt -us) and the ability to keep a background process attached to the TTY (Red Hat Bugzilla, Red Hat CVE).

Successful exploitation grants a low-privileged local attacker complete root access to the affected system, resulting in high confidentiality, integrity, and availability impact. An attacker achieving login -f root can read all system data, modify system state arbitrarily, install rootkits or backdoors, and disrupt services. While the scope is limited to the local system (no scope change), full system compromise enables lateral movement to other systems reachable from the compromised host (Red Hat CVE, Red Hat Bugzilla).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation as of the disclosure date (Feedly). The EPSS score is approximately 0.106% (1st percentile), indicating a low near-term exploitation probability (Github Advisory). CISA's SSVC assessment classifies exploitation as "none" and the attack as non-automatable, reflecting the configuration-dependent and timing-sensitive nature of the flaw. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Prerequisite — Verify target configuration: Confirm the target system uses a kbrequest/init configuration that invokes openvt -u, such as kb::kbrequest:/usr/bin/openvt -us in /etc/inittab or equivalent.
2. Load keyboard mapping: As an unprivileged user, load a keymap that binds a key combination to Spawn_Console, e.g., echo "alt keycode 103 = Spawn_Console" | loadkeys.
3. Log in on tty1: Authenticate as an unprivileged user on the target virtual terminal (e.g., tty1).
4. Anchor a background process to the TTY: Spawn a long-lived background process that keeps fd 0 attached to the current TTY: nohup sh -c 'sleep 1000000' </dev/tty1 >/dev/null 2>&1 &.
5. Log out: Log out from tty1 so that TTY ownership reverts to root or the getty owner, while the background process retains its open file descriptor.
6. Trigger the keyboard request: Press the configured key combination (e.g., Alt+Up Arrow) to invoke the kbrequest action, causing openvt -us to run with root privileges.
7. Observe passwordless root login: The flawed authenticate_user() check matches the background process's fd 0 (now owned by root at the TTY node level) and executes login -f root on the new VT, granting a root shell without a password (Red Hat Bugzilla).

• Process: Unexpected login -f root process spawned from openvt without a preceding password authentication event; openvt process with -u or -s flags running as root outside of expected administrative windows.
• Logs: Auth log entries (e.g., /var/log/secure or journalctl) showing login: ROOT LOGIN or login -f root on a virtual terminal without a corresponding PAM password authentication event; init or systemd log entries for kbrequest invocations at unexpected times.
• File System: Presence of long-lived background processes (e.g., sleep or sh) with fd 0 pointing to a TTY device node owned by root, visible via ls -la /proc/<pid>/fd/0.
• Network: Outbound connections from the system initiated shortly after an unexpected root login event, potentially indicating post-exploitation activity (Red Hat Bugzilla).

Red Hat has released a fix in kbd-2.10.0-2.hum1 for Red Hat Hardened Images via security advisory RHSA-2026:41136 (issued July 16, 2026) (Red Hat Errata). For RHEL 7, 8, 9, and 10, patches are tracked but not yet released as of the disclosure date; administrators should monitor Red Hat's advisory page for updates. As an immediate workaround, Red Hat recommends avoiding openvt -u in privileged kbrequest/init deployments — either configure the keyboard request to start a standard authenticated login on the new VT, or disable the kbrequest binding entirely. The proposed upstream code fix validates the actual process owner from /proc/<pid> before matching its fd/0 against the target TTY, eliminating reliance on the TTY node's st_uid (Red Hat CVE, Red Hat Bugzilla).

Red Hat rates the real-world impact as Moderate despite the 7.8 High CVSS score, noting that exploitation requires a deliberately configured non-default kbrequest/init setup combined with a narrow TTY-state timing condition not present in standard Red Hat deployments (Red Hat CVE). The vulnerability was discovered by "AISLE Research" in partnership with Red Hat and was reported under embargo before public disclosure. A Mastodon post from @thehackerwire noted the disclosure shortly after publication, and the CVE was indexed by standard vulnerability aggregators (VulDB, Vulners, CVEFeed) within hours of release.