Skip to content
VulniPulse
Advisory severityHigh7.8Vendor: MediumRed Hat Linux

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.

CVE-2026-72693 Source published Source updated

VulniPulse record published Record updated

Affected products & platforms
Red Hat LinuxRed Hat Enterprise Linux
Open source advisory

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.

Matching phone alertsOptional email delivery

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

Fixed versions
  • 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

Recommended fix / mitigation
  • 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.