CVE-2026-72693: Red Hat Enterprise Linux 10 · Improper Access Control
Affects Red Hat Enterprise Linux 10Source CVE Database V5
Not known to be exploited · CVSS 7.8 High.
Data as of 9 Nov 2026, 23:24 UTC
Thin evidence
One scorer or none| CNA (redhat) | CVSS 3.1 | 7.8 |
|---|
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 3% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 11 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 9 Nov 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Red Hat Enterprise Linux 10kbd | Affected– | Fixed in– |
| Red Hat Enterprise Linux 8kbd | Affected– | Fixed in– |
| Red Hat Enterprise Linux 9kbd | Affected– | Fixed in– |
| Red Hat OpenShift Container Platform 4.22openshift/ose-rhel-coreos-9 | Affected– | Fixed in– |
| Red Hat OpenShift Container Platform 4.22openshift/ose-rhel-coreos-9 | Affected– | Fixed in– |
| Red Hat Hardened Imageskbd-main | Affected– | Fixed in– |
AI-suggested
Red Hat advises avoiding the use of openvt -u in privileged kbrequest/init deployments. Instead, configure kbrequest 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. Users should monitor the Red Hat advisory for updates.
Description
`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/<pid>/fd/0")`. `stat()` on `/proc/<pid>/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.
References
- access.redhat.com/security/cve/CVE-2026-72693 (opens in a new tab)
- bugzilla.redhat.com/show_bug.cgi?id=2462115 (opens in a new tab)
- access.redhat.com/errata/RHSA-2026:41136 (opens in a new tab)
- access.redhat.com/errata/RHSA-2026:57597 (opens in a new tab)
- access.redhat.com/errata/RHSA-2026:57610 (opens in a new tab)
- access.redhat.com/errata/RHSA-2026:60440 (opens in a new tab)
- access.redhat.com/errata/RHSA-2026:66357 (opens in a new tab)
- access.redhat.com/errata/RHSA-2026:78951 (opens in a new tab)