Threats Tagged 'cve-2026-72693'
View all threats tagged with 'cve-2026-72693'. Filter and sort to focus on specific types of threats.
Stop chasing alerts. Route them.
Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.
Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)
API access activates after upgrading in Console -> Billing.
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.
Filter Threats
Narrow down the results by type, severity, or affected countries
Threats Tagged 'cve-2026-72693'
Click on any threat for detailed analysis and mitigation recommendations
0 The kbd packages provide tools for managing console behavior on a Linux system, including the keyboard, screen fonts, virtual terminals, and font files. Security Fix(es): * kbd: Local privilege escalation in openvt via incorrect process owner verification allowing passwordless root login (CVE-2026-72693) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. Join the discussion | GCVE Database | 08/20/2026, 18:39:33 UTC Added: 08/16/2026, 15:27:48 UTC |
`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. Join the discussion | CVE Database V5 | 08/11/2026, 08:39:24 UTC Added: 08/11/2026, 08:56:58 UTC |
0 This update includes the following RPMs: rust: * cargo-1.96.1-1.hum1 (aarch64, x86_64) * clippy-1.96.1-1.hum1 (aarch64, x86_64) * rust-1.96.1-1.hum1 (aarch64, x86_64) * rust-analyzer-1.96.1-1.hum1 (aarch64, x86_64) * rust-debugger-common-1.96.1-1.hum1 (noarch) * rust-doc-1.96.1-1.hum1 (aarch64, x86_64) * rust-gdb-1.96.1-1.hum1 (noarch) * rust-lldb-1.96.1-1.hum1 (noarch) * rust-src-1.96.1-1.hum1 (noarch) * rust-std-static-1.96.1-1.hum1 (aarch64, x86_64) * rust-std-static-aarch64-unknown-none-softfloat-1.96.1-1.hum1 (noarch) * rust-std-static-aarch64-unknown-uefi-1.96.1-1.hum1 (noarch) * rust-std-static-i686-pc-windows-gnu-1.96.1-1.hum1 (noarch) * rust-std-static-wasm32-unknown-unknown-1.96.1-1.hum1 (noarch) * rust-std-static-wasm32-wasip1-1.96.1-1.hum1 (noarch) * rust-std-static-x86_64-pc-windows-gnu-1.96.1-1.hum1 (noarch) * rust-std-static-x86_64-unknown-none-1.96.1-1.hum1 (noarch) * rust-std-static-x86_64-unknown-uefi-1.96.1-1.hum1 (noarch) * rustfmt-1.96.1-1.hum1 (aarch64, x86_64) * rust-1.96.1-1.hum1.src (src) Join the discussion | GCVE Database | 07/02/2026, 15:43:28 UTC Added: 07/03/2026, 22:50:29 UTC |
Showing 1 to 3 of 3 results