CVE-2023-0386

What it actually does

This vulnerability is a local privilege-escalation flaw in the Linux kernel OverlayFS subsystem. It occurs when a file with setuid or file capabilities is copied from a nosuid mount into another mount in a way that mishandles UID/GID mapping and ownership checks. A low-privileged local user can abuse this behavior to create or execute a privileged binary and gain root-level capabilities. Successful exploitation provides high-impact compromise of confidentiality, integrity, and availability on the affected host, but requires local code execution or an existing low-privileged account/container foothold.

Why it matters to the business

An attacker who already has limited access to a vulnerable Linux system can become root, disable security controls, steal sensitive data, modify workloads, deploy persistence, or use the host to move laterally. This is especially important for multi-user Linux servers, shared hosting, developer workstations, container hosts, CI/CD runners, and Kubernetes or virtualization nodes where an initial low-privileged foothold is plausible. The vulnerability is listed in CISA KEV and has active in-the-wild exploitation, with a federal remediation due date of 2025-07-08, so organizations should treat exposure as a priority even though exploitation is local rather than remote. It is not specifically flagged by KEV as ransomware-used, but local privilege escalation is commonly chained after initial access by ransomware and intrusion operators.

How an attack unfolds

An attacker first obtains local code execution on a vulnerable Linux host, for example through stolen credentials, an exposed service, a compromised application, a container escape chain, or malware running as an unprivileged user. They then prepare a user-controlled OverlayFS mount scenario involving a nosuid source and another mount destination. By copying a file that has setuid behavior or Linux file capabilities across the affected OverlayFS boundary, the kernel incorrectly preserves or applies privileged attributes despite the nosuid and UID mapping expectations. The attacker then executes the resulting file or payload to obtain elevated privileges, typically root. After privilege escalation, they may add persistence, dump credentials, tamper with logs, disable endpoint controls, access protected data, or pivot to other systems. Public proof-of-concept exploit patterns for this issue commonly involve temporary working directories, OverlayFS lower/upper/work/merged directories, and creation of a root-capable helper binary.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the upstream fix for commit 4f11ada10d0a or the equivalent distribution backport. Because Linux distributions frequently backport kernel security fixes without changing to the latest upstream kernel version, validate against the vendor advisory and package changelog rather than version number alone. Reboot systems after installing the fixed kernel so the patched kernel is actually running. Where immediate patching is not possible, reduce exposure by disabling unprivileged user namespaces where operationally feasible, restricting local shell access, limiting container privilege and mount capabilities, preventing untrusted users from creating OverlayFS mounts, enforcing least privilege on CI/CD runners and developer systems, and monitoring for suspicious OverlayFS mount activity. Treat mitigations as temporary; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is patched. On Linux hosts, compare `uname -r` with the distribution vendor’s fixed kernel package, and verify package metadata or changelogs reference the CVE or the upstream fix commit 4f11ada10d0a. Confirm the host has been rebooted after kernel update. Review whether unprivileged users can create user namespaces or OverlayFS mounts, for example via sysctl settings and container runtime policy. If vulnerability scanning is used, ensure it checks distribution backports and running-kernel state. For high-risk systems, perform a controlled validation using a safe non-destructive check from the vendor or a trusted security tool rather than running public exploit code in production.

Typical attack path

1. Gain low-privileged local code execution on a vulnerable Linux system.
2. Check kernel version, OverlayFS availability, user namespaces, mount permissions, and filesystem layout.
3. Create attacker-controlled temporary directories for OverlayFS lower, upper, work, and merged layers.
4. Use OverlayFS copy-up behavior involving a nosuid mount and a file with setuid or file capabilities.
5. Trigger the UID mapping flaw so privileged ownership, setuid, or capability attributes are retained incorrectly.
6. Execute the resulting privileged helper or payload to obtain root privileges.
7. Establish persistence, access protected files, disable defenses, harvest credentials, or move laterally.

How to detect it

Detection should focus on signs of local privilege escalation rather than remote network exploitation. Review Linux audit logs, syslog/journald, EDR telemetry, shell history, process execution logs, container runtime logs, and file integrity monitoring. Look for unprivileged users invoking `mount` with OverlayFS, creating temporary `lower`, `upper`, `work`, and `merged` directories, copying binaries with setuid bits or file capabilities, and executing newly created root-owned files from temporary paths such as `/tmp`, `/var/tmp`, `/dev/shm`, or container writable layers. Search for unexpected setuid-root files and files with elevated Linux capabilities created shortly before a privilege change. Audit for successful `execve` of suspicious helper binaries followed by UID 0 process creation, new root cron/systemd entries, SSH authorized keys, or changes to `/etc/passwd`, `/etc/shadow`, and sudoers files. Kernel or audit records showing OverlayFS mounts by non-admin users are especially relevant. Because exploitation often uses short-lived temporary files, combine historical telemetry with current filesystem sweeps for anomalous setuid/capability files. Known public exploit tooling may use generic names and temporary directories, so absence of exact filenames does not rule out compromise.

• mount -t overlay
• type=SYSCALL msg=audit
• exe="/usr/bin/mount"
• fstype=overlay
• lowerdir=
• upperdir=
• workdir=
• merged
• /tmp/ovlcap
• /tmp/overlayfs
• /tmp/upper
• /tmp/work
• /tmp/lower
• /tmp/merged
• /var/tmp/upper
• /var/tmp/work
• /var/tmp/lower
• /var/tmp/merged
• /dev/shm/upper
• /dev/shm/work
• /dev/shm/lower
• /dev/shm/merged
• setcap cap_setuid+ep
• cap_setuid+ep
• security.capability
• find / -perm -4000
• chmod u+s
• /etc/ld.so.preload
• /etc/sudoers
• /etc/sudoers.d/
• /root/.ssh/authorized_keys

What your security team should do

• Prioritize patching all internet-facing, multi-user, container-hosting, CI/CD, development, and high-value Linux systems because the vulnerability is in CISA KEV and has active exploitation reported.
• Upgrade to a vendor-supported kernel containing the fix equivalent to upstream commit 4f11ada10d0a, then reboot and verify the running kernel is patched.
• Inventory systems where OverlayFS, unprivileged user namespaces, containers, or local shell access are enabled; treat these as higher-risk exposure points.
• Temporarily restrict unprivileged user namespaces and untrusted mount operations where compatible with business workloads.
• Harden container and CI/CD environments by removing unnecessary `CAP_SYS_ADMIN`, privileged containers, host mounts, and untrusted build execution.
• Hunt for suspicious OverlayFS mount activity, unexpected setuid-root files, unusual file capabilities, and recent root-level process execution from temporary directories.
• Review endpoint, auditd, syslog, shell history, and container runtime logs for signs of local privilege escalation before marking remediation complete.
• If exploitation is suspected, preserve forensic evidence, isolate the host, rotate credentials exposed to the host, and investigate lateral movement.