CVE-2026-46333

What it actually does

This is a local Linux kernel authorization bypass in ptrace access-control logic. The vulnerable logic evaluates a task's “dumpable” state even when the target task has no associated memory map, such as some kernel threads or threads that have already torn down their address space. In that edge case, a process running with matching UID/GID — notably UID 0 with capabilities intentionally dropped — may be allowed access that should require CAP_SYS_PTRACE. The practical impact is a bypass of Linux capability-based isolation around ptrace/procfs-style inspection or manipulation paths, potentially exposing sensitive process or kernel-thread-related information and undermining defenses that rely on removing CAP_SYS_PTRACE from otherwise privileged processes.

Why it matters to the business

Systems that rely on Linux capabilities, containers, sandboxes, or least-privilege root processes may have weaker isolation than intended. A local attacker who has gained limited privileged execution could use this flaw to expand what they can inspect or influence on the host, increasing the risk of credential exposure, tampering with security-sensitive processes, and deeper host compromise. The vulnerability is not listed in CISA KEV and has a relatively low EPSS score, but the reported exploit maturity is weaponized, so exposed Linux systems should be patched with elevated priority, especially multi-user servers, container hosts, CI runners, and systems running untrusted workloads.

How an attack unfolds

An attacker first needs local code execution with sufficient privileges to run as a UID/GID that matches the target access checks, commonly UID 0 in a constrained environment where CAP_SYS_PTRACE has been deliberately removed. The attacker then targets tasks that lack an active memory map, such as certain kernel threads or threads in teardown states, and invokes ptrace-adjacent interfaces or procfs reads that rely on ptrace_may_access() authorization. On vulnerable kernels, the access decision may fall back to inappropriate dumpability logic rather than requiring CAP_SYS_PTRACE. This can allow access that the capability model was supposed to block. The attacker can use the gained visibility or control to collect sensitive runtime information, weaken process isolation, or support follow-on local privilege escalation and defense-evasion activity.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the upstream fix for the ptrace get_dumpable()/ptrace_may_access() logic. Because no product-specific fixed versions were provided, use distribution advisories from Red Hat, Ubuntu, Debian, SUSE, Amazon Linux, Oracle Linux, Alpine, Flatcar, Bottlerocket, Android, or the relevant appliance/container-host vendor to identify the exact patched kernel package. Reboot after installing the fixed kernel; live patching should only be considered sufficient if the vendor explicitly states that this CVE is covered. As interim risk reduction, minimize local shell access, avoid running untrusted workloads on shared hosts, keep CAP_SYS_PTRACE removed from containers and services, restrict privileged containers, enable user namespaces and LSM controls where appropriate, and monitor or limit access to sensitive /proc interfaces. These mitigations reduce exploitability but do not fully correct the kernel authorization flaw.

How to confirm the fix worked

Confirm exposure by inventorying kernel versions with commands such as uname -a and package-manager queries, then compare the running kernel and installed kernel packages against the relevant vendor advisory. Ensure the system has actually booted into the patched kernel after remediation; merely installing the package is not enough. Validate that the fix is present by checking for the vendor backport or upstream commit addressing the ptrace dumpability behavior for tasks without an mm. In controlled test environments, verify that a UID 0 process without CAP_SYS_PTRACE cannot access protected ptrace/procfs interfaces for no-mm tasks. For container hosts, validate both the host kernel and any node images or immutable OS images, because containers share the host kernel.

Typical attack path

1. Gain local code execution on a Linux system, often through a compromised service, container, build job, or user account.
2. Obtain or already possess UID 0 or matching UID/GID privileges in a constrained context where CAP_SYS_PTRACE is absent.
3. Enumerate candidate target tasks through /proc, focusing on kernel threads or threads without an active memory map.
4. Use ptrace-related syscalls or procfs interfaces governed by ptrace_may_access(), such as process inspection paths.
5. Bypass the intended CAP_SYS_PTRACE requirement because the vulnerable kernel uses unsafe dumpability logic for no-mm tasks.
6. Read sensitive task information or interact with protected process interfaces that should have been denied.
7. Use the recovered information or access to support lateral movement on the host, container escape chains, credential theft, or further local exploitation.

How to detect it

Detection should focus on signs of local exploitation or attempted exploitation rather than a stable remote network signature. Collect auditd, eBPF/EDR telemetry, sysmon-for-Linux events, kernel logs, shell history, container runtime logs, and process execution records. Look for processes without a legitimate debugging role making ptrace-related syscalls or accessing sensitive /proc paths for other tasks, especially from containers, CI jobs, web-service users, or constrained UID 0 processes. Useful audit targets include ptrace syscall activity, process_vm_readv/process_vm_writev, open/openat against /proc/*/mem, /proc/*/stack, /proc/*/syscall, /proc/*/maps, /proc/*/status, and high-volume enumeration of /proc/[0-9]*/task. Investigate denied or allowed access attempts involving processes that lack CAP_SYS_PTRACE. Correlate suspicious activity with subsequent credential access, unexpected debugging tools, kernel-thread enumeration, privilege changes, container escape attempts, or tampering with security tooling. Because the vulnerability is a kernel authorization flaw, absence of logs does not prove non-exploitation unless syscall/procfs telemetry was enabled at the time.

• ptrace(
• PTRACE_ATTACH
• PTRACE_SEIZE
• PTRACE_PEEKDATA
• PTRACE_POKEDATA
• process_vm_readv
• process_vm_writev
• /proc/*/mem
• /proc/*/stack
• /proc/*/syscall
• /proc/*/maps
• /proc/*/status
• /proc/*/task
• CapEff:
• CAP_SYS_PTRACE
• audit: type=SYSCALL
• syscall=ptrace
• comm="strace"
• comm="gdb"
• comm="gcore"
• comm="cat"
• comm="dd"

What your security team should do

• Prioritize patching shared Linux systems, container hosts, Kubernetes nodes, CI/CD runners, jump hosts, and multi-user servers because local attackers or untrusted workloads are the most relevant threat model.
• Treat this as higher priority than the EPSS score alone suggests because exploit maturity is reported as weaponized, even though it is not currently in CISA KEV and is not marked as ransomware-associated.
• Create an inventory of running kernel versions and confirm systems have rebooted into fixed kernels after updates.
• Review workloads that run as UID 0 without CAP_SYS_PTRACE and assess whether their isolation assumptions depend on Linux capabilities.
• Harden container and sandbox configurations: avoid privileged containers, drop unnecessary capabilities, use seccomp/AppArmor/SELinux profiles, and restrict host /proc exposure.
• Add audit or eBPF-based monitoring for unusual ptrace and sensitive /proc access from services, containers, or build jobs that normally should not inspect other tasks.
• Investigate suspicious local post-exploitation activity around the publication window and afterward, especially on systems running untrusted code.
• If immediate patching is not possible, reduce local attack surface by limiting shell access, separating untrusted workloads onto isolated nodes, and increasing monitoring for ptrace/procfs enumeration.