High [CVE-2026-72693] Local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login
This high-severity Red Hat Linux advisory covers CVE-2026-72693 affecting Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 4.22.
Aggregated and source-linked by VulniPulse. Data sources, validation and limitations.
VulniPulse record published Record updated
Android app · Google Play
Monitor future Red Hat Linux CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.
Summary
`openvt -u` is intended to identify the owner of the current VT and then execute `login` as that user from a privileged context. In the documented `kbrequest`/init usage, the ownership test in `authenticate_user()` relies on `stat("/proc//fd/0")`.
`stat()` on `/proc//fd/0` follows the symlink to the underlying TTY device node. As a result, `buf.st_uid` reflects the owner of the TTY node rather than the owner of the process holding the file descriptor.
If the TTY owner returns to `root` or the getty owner after logout while an unprivileged process still has `fd 0` attached to that TTY, the check can incorrectly treat that process as belonging to the privileged console owner. Once that check succeeds, the `-u` path executes a passwordless login as the selected user.
In the documented `kbrequest`/init deployment using `openvt -us`, this can result in passwordless `login -f root` on the spawned VT. This report establishes that privilege escalation path for that documented deployment; it does not claim equivalent reachability for deployments that do not use `openvt -u` from a privileged `kbrequest`/init path.
A flaw was found in openvt (part of the kbd package) where incorrect process owner verification can allow a local unprivileged attacker to achieve passwordless root login.
Affected versions
No affected-version range was extracted from the source record. The vendor advisory is authoritative — check it before change work.
Official advisory · high-confidence parse· fetched 26 days ago·verify at source
- kbd-0:2.6.4-8.el10_2
- kbd-0:2.4.0-12.el9_8
- rhcos-4.22.9.8.202608251819-0
- kbd-main-2.10.0-2.hum1
- RHSA-2026:57597
- RHSA-2026:57610
- RHSA-2026:60440
- RHSA-2026:41136
Official advisory · high-confidence parse· fetched 26 days ago·verify at source
Mitigation checklist
- To mitigate this issue, avoid using `openvt -u` in privileged `kbrequest`/init deployments. Instead, configure the keyboard request to initiate a standard authenticated login on the new virtual terminal, or disable the keyboard request binding entirely until a fix is available. Changes to `kbrequest` configurations may require a system restart or service reload to take effect.
Official advisory · high-confidence parse· fetched 26 days ago·verify at source
Discussion(0)
No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.
Sign in to join the discussion.