high

CVE

CVE-2026-46333

CWE

CWE-269

Affected Surface

Linux kernel ptrace_may_access and __ptrace_may_access paths, Linux kernels containing the affected dumpability logic before vendor fixes, Systems with pidfd_getfd syscall support where untrusted local users can run code, Debian 13, Ubuntu 24.04 and 26.04, Fedora 43 and 44 systems tested by Qualys for selected exploit targets, CI runners, developer workstations, multi-user Linux hosts, and desktop Linux systems with setuid or root-daemon attack surfaces

Qualys published the full advisory for CVE-2026-46333 on 20 May 2026 after public exploit material appeared during coordinated distribution patching. The vulnerability is in the Linux kernel’s ptrace access-control path. It allows an unprivileged local attacker to duplicate file descriptors from a privileged process during a narrow exit-time race, after that process has dropped credentials but before the kernel closes its file table.

The bug is local-only, but local-only is not low impact on modern application infrastructure. A malicious package, compromised build step, web shell, low-privilege service account, or shared developer account can use a local kernel issue to cross the boundary from application execution to host secrets.

Affected project

The affected project is the Linux kernel. The vulnerable logic is in __ptrace_may_access() / ptrace_may_access() and the related pidfd_getfd(2) access check.

NVD describes the upstream fix as making the kernel’s get_dumpable() logic saner when a task no longer has an associated memory map. Qualys states that the vulnerable behavior dates back to Linux v4.10-rc1 era logic, while practical exploitation with the published primitive depends on pidfd_getfd(2), which was added in Linux v5.6-rc1.

Vendor impact and fixed versions vary by distribution and backport status. Qualys reported successful exploit development against selected default installs of:

  • Debian 13
  • Ubuntu 24.04
  • Ubuntu 26.04
  • Fedora 43
  • Fedora 44

Canonical lists Ubuntu kernel packages as affected during its mitigation write-up and recommends kernel updates plus a kernel.yama.ptrace_scope mitigation where fixes are not yet installed.

Root cause

The ptrace access check historically included two relevant gates:

tcred = __task_cred(task);
if (uid_eq(caller_uid, tcred->euid) &&
    uid_eq(caller_uid, tcred->suid) &&
    uid_eq(caller_uid, tcred->uid) &&
    gid_eq(caller_gid, tcred->egid) &&
    gid_eq(caller_gid, tcred->sgid) &&
    gid_eq(caller_gid, tcred->gid))
    goto ok;

ok:
mm = task->mm;
if (mm &&
    ((get_dumpable(mm) != SUID_DUMP_USER) &&
     !ptrace_has_cap(mm->user_ns, mode)))
    return -EPERM;

return security_ptrace_access_check(task, mode);

The bypass appears when task->mm is already NULL. During do_exit(), the kernel tears down a task in phases:

do_exit()
  -> exit_mm()      // task->mm becomes NULL
  -> exit_files()   // open files are closed later
  -> do_task_dead()

In the gap between exit_mm() and exit_files(), the task has no mm, so the dumpability check guarded by if (mm && ...) is skipped. If the target process has already dropped to the attacker’s uid and gid, the credential equality check can pass. The remaining hook may still allow access under default Yama policy, depending on distribution configuration and process relationship.

Qualys found pidfd_getfd(2) to be the useful primitive:

if (ptrace_may_access(task, PTRACE_MODE_ATTACH_REALCREDS))
    file = fget_task(task, fd);

If the attacker wins the exit race, pidfd_getfd() duplicates a file descriptor that the privileged process still has open. The attacker then reads or uses that descriptor under their own unprivileged process.

Exploitation case studies

Qualys built four exploit case studies. These are not the complete userland attack surface; they are examples showing what the kernel primitive can steal.

chage: reading /etc/shadow

chage opens /etc/shadow and then drops privileges for the -l path. If the attacker kills the process after the drop but before files are closed, pidfd_getfd() can duplicate the /etc/shadow descriptor.

Impact:

  • Disclosure of password hashes.
  • Follow-on offline cracking risk.
  • Credential rotation and password reset concerns on multi-user systems.

ssh-keysign: reading SSH host private keys

ssh-keysign is setuid root and opens host private keys under /etc/ssh/*_key before dropping privileges. Qualys demonstrated descriptor theft against Debian and Ubuntu default installs.

Impact:

  • Disclosure of SSH host keys.
  • Possible on-path impersonation risk if clients trust those host keys.
  • Host-based authentication risk for environments that use it.

Canonical’s mitigation write-up focuses on this path and refers to the issue as ssh-keysign-pwn.

pkexec and accounts-daemon: stealing root-authenticated D-Bus connections

The higher-impact case is not only reading files. Some privileged processes hold authenticated IPC channels, including system D-Bus sockets. If an attacker steals a descriptor that is already authenticated as root, they may send privileged requests through that channel.

Qualys demonstrated root command execution paths through:

  • pkexec in specific desktop/session conditions.
  • accounts-daemon on selected systems.

The details vary by distribution, desktop policy, SELinux/AppArmor behavior, and Yama configuration, but the lesson is general: open descriptors are authority. If a privileged process keeps a sensitive file or IPC channel open after dropping credentials, this kernel bug can turn that descriptor into an attacker’s capability.

Why application teams should care

This vulnerability is relevant to application security because the initial foothold can be application-level:

  • A malicious npm, PyPI, Go, RubyGems, or NuGet package lands on a developer workstation.
  • A CI job runs attacker-controlled code in an unprivileged build user.
  • A web application compromise gives a low-privilege shell.
  • A multi-tenant internal Linux host lets untrusted users run code.
  • A container workload executes on a host with a vulnerable kernel and overly broad local primitives.

On container deployments, Canonical notes that disclosed information is generally confined to the container. That does not make every container safe: privileged containers, shared host namespaces, mounted host paths, exposed runtime sockets, and self-hosted CI runners can all change the blast radius. Treat kernel patching as part of application incident response, not only infrastructure hygiene.

Remediation

Apply vendor kernel updates and reboot into the fixed kernel. Checking installed package versions is not enough if the running kernel is still old:

uname -a

Use distribution-specific trackers for fixed kernel packages. Do not assume an upstream stable commit ID maps directly to your distro package without checking backports.

Where patching must wait, raise Yama’s ptrace restriction:

echo kernel.yama.ptrace_scope=2 | sudo tee /etc/sysctl.d/99-CVE-2026-46333.conf
sudo sysctl -p /etc/sysctl.d/99-CVE-2026-46333.conf

kernel.yama.ptrace_scope=2 requires CAP_SYS_PTRACE for attach-style operations and blocks the public pidfd_getfd() exploit path described by Qualys. 3 is stricter, but it cannot be lowered without a reboot. Test before broad rollout because debuggers, crash collection, some browser crash reporters, container debugging, and CRIU-style tooling may be affected.

Detection and response

Host telemetry should prioritize unusual combinations rather than a single syscall:

  • Repeated pidfd_getfd calls against short-lived setuid or root-owned processes.
  • SIGKILL or high-rate process termination around chage, ssh-keysign, pkexec, or desktop account services.
  • Unexpected reads of /etc/shadow or /etc/ssh/*_key by unprivileged process trees.
  • New root-level commands after D-Bus activity from unexpected processes.
  • CI or application worker processes invoking setuid utilities they do not normally use.

If exploitation is suspected, patch or mitigate first, then rotate secrets that may have been exposed:

  • SSH host keys from affected hosts.
  • Local user passwords if /etc/shadow may have been read.
  • Credentials available to the compromised local user.
  • Deployment and package-registry tokens present on CI runners or developer workstations.

Because the exploit can disclose existing file descriptors without changing files on disk, file-integrity monitoring alone is not enough. Pair it with syscall, process, and authentication telemetry around privileged helper binaries.

References