CVE-2026-53236

What it actually does

This is a Linux kernel information-disclosure weakness in TCP socket handling. Before the fix, an unprivileged local process could use SO_ATTACH_FILTER to attach a classic BPF socket filter to TCP sockets without requiring CAP_NET_ADMIN. That capability could be abused as a side channel to infer TCP sequence and acknowledgment numbers or related connection-state information. The issue does not directly provide remote code execution or privilege escalation, but it may weaken TCP session confidentiality and integrity when combined with other network-positioning or local-compromise techniques.

Why it matters to the business

The primary risk is to shared Linux systems, container hosts, multi-user servers, and platforms that run untrusted local workloads. A malicious local application could potentially gather sensitive TCP connection metadata that helps attack or monitor network sessions. The CVE is not in CISA KEV, is not known to be used in ransomware campaigns, has no public exploit maturity reported, and has a low EPSS score, so immediate mass exploitation is not indicated; however, kernel flaws affecting isolation boundaries should still be prioritized on systems that host untrusted users or workloads.

How an attack unfolds

An attacker first needs the ability to run code as an unprivileged local user or inside a workload on an affected Linux system. The attacker creates or accesses TCP sockets and calls setsockopt() with SOL_SOCKET and SO_ATTACH_FILTER to attach a crafted classic BPF filter. Because the vulnerable kernel does not require CAP_NET_ADMIN for this operation on TCP sockets, the filter can be installed by a process that should not have network-administration privileges. The attacker then uses observations from the filter behavior as a side channel to infer TCP sequence or acknowledgment values associated with TCP traffic. Those inferred values may be used to support follow-on attacks against active TCP sessions, especially in environments where the attacker can also observe, influence, or race network traffic.

How to fix it

Apply a Linux kernel update that includes the upstream fix restricting SO_ATTACH_FILTER on TCP sockets to processes with CAP_NET_ADMIN. Use the fixed kernel packages provided by the operating system or appliance vendor, then reboot into the updated kernel where required. If immediate patching is not possible, reduce exposure by preventing untrusted local code execution, isolating untrusted workloads on separate hosts, limiting shell access, reviewing container privilege settings, and avoiding unnecessary CAP_NET_ADMIN grants. Kernel hardening and workload isolation controls should be treated as mitigations, not substitutes for applying the kernel fix.

How to confirm the fix worked

Confirm that the running kernel version is the vendor-fixed build, not merely that updated packages are installed on disk. Validate with commands such as uname -a, package-manager kernel inventory, and vendor advisory mapping for the relevant distribution. Where safe to test, run a controlled negative test from an unprivileged account that attempts to attach SO_ATTACH_FILTER to a TCP socket; fixed systems should deny the operation unless the process has CAP_NET_ADMIN. Also review container and service definitions to ensure untrusted workloads are not granted CAP_NET_ADMIN unnecessarily.

Typical attack path

1. Gain the ability to execute code as an unprivileged local user or inside an untrusted workload on an affected Linux host.
2. Create or interact with TCP sockets from the unprivileged process.
3. Invoke setsockopt() using SOL_SOCKET and SO_ATTACH_FILTER to attach a crafted classic BPF socket filter.
4. Use the filter behavior to collect side-channel information about TCP sequence or acknowledgment numbers.
5. Combine the leaked TCP state information with network-positioning or traffic-injection techniques to attack or monitor TCP sessions.

How to detect it

To determine whether this was already abused, focus on host-level telemetry because exploitation requires local code execution. Review Linux audit logs, EDR telemetry, syscall tracing, and container runtime logs for unprivileged processes invoking setsockopt with SOL_SOCKET and SO_ATTACH_FILTER on TCP sockets. Pay special attention to processes running from temporary directories, writable application directories, build workspaces, user home directories, or containers that do not normally perform low-level socket filtering. Investigate any unexpected CAP_NET_ADMIN grants, privileged containers, or recent additions of packet-filtering behavior to applications. Correlate suspicious socket-filter attachment activity with signs of TCP session manipulation, unusual connection resets, spoofed packets, anomalous traffic injection, or unexplained authentication/session failures. Because the issue is a side-channel primitive, there may be no single definitive artifact of successful exploitation; detection is most effective when syscall telemetry is combined with process lineage, user identity, container context, and network anomaly data.

• SO_ATTACH_FILTER
• SOL_SOCKET
• setsockopt
• setsockopt(SOL_SOCKET, SO_ATTACH_FILTER)
• optname=SO_ATTACH_FILTER
• syscall=setsockopt
• syscall=54
• a1=1 a2=1a
• CAP_NET_ADMIN
• /tmp/
• /var/tmp/
• /dev/shm/

What your security team should do

• Prioritize patching shared Linux hosts, container platforms, bastion systems, CI runners, and any servers that execute untrusted or semi-trusted local code.
• Inventory running kernel versions and verify that systems have rebooted into a kernel containing the SO_ATTACH_FILTER privilege restriction.
• Review accounts, services, and containers with CAP_NET_ADMIN; remove that capability wherever it is not explicitly required.
• Hunt for unusual unprivileged use of setsockopt with SO_ATTACH_FILTER on TCP sockets, especially from unexpected user accounts, application directories, temporary paths, or containerized processes.
• Increase monitoring of systems where untrusted local execution is possible until the fixed kernel is deployed.
• Treat findings as defense-in-depth hardening unless accompanied by other indicators of network session manipulation or local compromise, because current EPSS is low and no public exploit maturity is reported.