CVE-2026-33150

What it actually does

CVE-2026-33150 is a local use-after-free in libfuse 3.18.0 and 3.18.1 affecting the io_uring startup path. If io_uring thread creation fails, for example because a container or cgroup has exhausted its pids.max limit, fuse_uring_start() frees the ring pool structure but leaves a stale pointer in the FUSE session state. When the session later shuts down, libfuse can dereference freed memory, causing a crash and, depending on allocator state and process privileges, potentially allowing arbitrary code execution in the context of the affected FUSE filesystem process.

Why it matters to the business

Organizations running FUSE-based filesystems on affected libfuse versions may experience local denial of service, filesystem process crashes, container instability, or disruption to applications that depend on mounted FUSE filesystems. Because exploitation requires local access but is reliable in constrained containerized environments, the highest-risk scenarios are multi-user Linux systems, container platforms, CI/CD workers, developer workstations, and services that allow untrusted users to run workloads. The issue is not currently listed in CISA KEV, has low EPSS, and has no known mature public exploit, but the CVSS score is high because successful exploitation can affect confidentiality, integrity, and availability of the impacted process.

How an attack unfolds

An attacker first obtains the ability to run code locally on a Linux system or inside a container where applications use libfuse 3.18.0 or 3.18.1. The attacker then creates or waits for a resource-constrained condition, most notably exhaustion of allowed process or thread creation under cgroup pids.max. Under that condition, a FUSE filesystem process using libfuse attempts to initialize its io_uring support and fails to create the required thread. The vulnerable cleanup path frees the io_uring ring pool but leaves the freed address recorded in the FUSE session. When the FUSE session is later torn down, the stale pointer is used again, leading to a crash. With additional memory-shaping techniques, an attacker may attempt to reclaim the freed memory and influence the later dereference, potentially turning the crash into code execution within the privileges of the FUSE filesystem process.

How to fix it

Upgrade libfuse to version 3.18.2 or later. Although no fixed version list was supplied in the package metadata, the vulnerability description identifies 3.18.2 as the patched upstream release. After upgrading the library package, restart all FUSE filesystem processes, affected services, containers, and long-running workloads so they load the corrected library. Where immediate upgrade is not possible, reduce exposure by avoiding untrusted local workloads on systems using affected libfuse versions, disabling or avoiding the affected io_uring path where supported by the application or distribution build, increasing overly restrictive pids.max limits only as a temporary reliability mitigation, and isolating FUSE workloads from untrusted users. Treat resource-limit changes as mitigation only; they do not remove the underlying memory safety flaw.

How to confirm the fix worked

Confirm that installed libfuse packages are not version 3.18.0 or 3.18.1 and are upgraded to 3.18.2 or later. Use distribution package tools such as rpm, dpkg, apk, or pacman as applicable, and verify dynamically linked binaries with ldd or equivalent tooling to ensure active FUSE processes are loading the patched libfuse3 shared object. Restart or redeploy workloads after patching, then confirm open file mappings no longer reference an old deleted libfuse library. In a non-production test environment, reproduce the previously vulnerable condition by constraining process/thread creation with a low cgroup pids.max and exercising FUSE startup/shutdown; patched builds should fail cleanly without crashing or producing use-after-free sanitizer findings.

Typical attack path

1. Gain local code execution as an unprivileged user or inside a container on a Linux host using libfuse 3.18.0 or 3.18.1.
2. Identify or create a FUSE workload that uses the affected libfuse io_uring path.
3. Force thread creation failure by exhausting the applicable process/thread limit, commonly through cgroup pids.max or similar resource limits.
4. Trigger FUSE session initialization so fuse_uring_start() enters the vulnerable failure path.
5. Cause or wait for FUSE session shutdown so the stale session pointer is dereferenced.
6. Achieve denial of service through process crash, or attempt heap manipulation to turn the use-after-free into code execution in the FUSE filesystem process.

How to detect it

To determine whether this issue was already exploited, review host logs, container runtime logs, systemd journals, kernel logs, audit logs, and coredump records for FUSE filesystem crashes that coincide with process/thread exhaustion. Relevant sources include journalctl output for affected services, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-coredump metadata, container runtime events, Kubernetes pod/container restart events, and auditd records showing repeated clone, fork, or thread-creation failures. Look for segfaults or aborts in FUSE-based processes that load libfuse3, especially when preceded by pids.max limit hits, "Resource temporarily unavailable" thread creation failures, or container OOM/resource pressure events without a clear application-level cause. For deeper forensics, inspect coredumps for stack frames or symbols involving fuse_uring_start, libfuse3, io_uring, FUSE session teardown, or heap use-after-free diagnostics from ASan or similar tooling. There are no known public campaign-specific indicators or named threat actors for this vulnerability based on the provided data, so detection should focus on behavioral evidence: local resource exhaustion followed by FUSE process crashes on hosts running vulnerable libfuse versions.

• libfuse3.so.3
• fuse_uring_start
• io_uring
• pids.max
• Resource temporarily unavailable
• pthread_create failed
• thread creation failed
• segfault.*libfuse3
• general protection fault.*libfuse3
• use-after-free.*libfuse
• heap-use-after-free.*libfuse
• systemd-coredump.*libfuse3
• systemd-coredump.*fuse
• /usr/lib/libfuse3.so.3
• /usr/lib64/libfuse3.so.3
• /lib/x86_64-linux-gnu/libfuse3.so.3
• /var/lib/systemd/coredump
• fusermount3
• mount.fuse3

What your security team should do

• Inventory Linux systems, containers, base images, and appliances that include libfuse 3.18.0 or 3.18.1, prioritizing multi-user hosts, container platforms, CI runners, and systems running untrusted workloads.
• Upgrade libfuse to 3.18.2 or later and restart all FUSE-dependent services and containers to ensure the patched library is loaded.
• Search for crashes in FUSE filesystem processes, kernel segfault logs, coredumps, and sanitizer output involving libfuse3, io_uring, fuse_uring_start, or FUSE session shutdown.
• Review cgroup pids.max, user process limits, and container runtime limits for evidence of deliberate thread/process exhaustion near the time of FUSE crashes.
• Do not rely on EPSS or non-KEV status as a reason to defer patching on shared Linux infrastructure; local privilege boundaries and workload isolation make this class of flaw operationally important.
• Where patching is delayed, restrict local shell/container access, avoid running untrusted FUSE workloads, and monitor for repeated FUSE process crashes or resource-limit exhaustion.