MEDIUM 5.5

CVE-2026-53236: Linux Kernel TCP Socket Privilege Escalation Fix

A vulnerability in the Linux kernel allows unprivileged users to attach Berkeley Packet Filter (cBPF) rules to TCP sockets in a way that could leak sensitive TCP connection information such as sequence and acknowledgment numbers. The fix restricts this socket option to only users with administrative network privileges (CAP_NET_ADMIN), preventing unprivileged applications from exploiting this side-channel to extract data about active TCP connections.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.5 MEDIUM · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
Affected products
13 configuration(s)
Published / Modified
2026-06-25 / 2026-07-08

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.

6 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-53236 addresses a privilege escalation and information disclosure weakness in the Linux kernel's TCP socket filtering mechanism. The vulnerability stems from insufficient access controls on the SO_ATTACH_FILTER socket option when applied to TCP sockets. An unprivileged process can attach a cBPF filter to monitor or infer TCP sequence numbers (ISN) and acknowledgment numbers by observing filter behavior or timing side-channels, potentially enabling TCP connection hijacking or session prediction attacks. The remediation introduces a capability check requiring CAP_NET_ADMIN for SO_ATTACH_FILTER operations on TCP sockets, aligning with the principle of least privilege for kernel security features.

Business impact

This vulnerability primarily affects Linux systems where unprivileged user accounts or containerized workloads can execute code. Exploitation could allow attackers to predict or hijack TCP connections within the same system, compromising inter-process communication security. For organizations relying on TCP-based authentication or session management on multi-tenant or shared Linux systems, this represents a lateral movement and privilege escalation risk. The impact is heightened in cloud environments where container escape or privilege escalation chains could be leveraged to compromise shared infrastructure.

Affected systems

The Linux kernel across multiple versions is affected. Administrators should consult their Linux distribution's security advisory and kernel release notes to identify which specific kernel versions contain the fix. This affects all architectures and distributions shipping the affected kernel versions. Container runtimes and orchestration platforms running affected kernel versions inherit this vulnerability.

Exploitability

The vulnerability requires local access and can be exploited by any unprivileged user on the system. No network access is required. Exploitation requires knowledge of cBPF and TCP sequence number prediction techniques, placing it within the reach of skilled local attackers or sophisticated malware running in user space. The barrier to exploitation is moderate—not trivial scripting, but well within the capabilities of dedicated threat actors familiar with kernel internals.

Remediation

Apply kernel updates from your Linux distribution that include the fix restricting SO_ATTACH_FILTER to CAP_NET_ADMIN users. Verify against your vendor's security advisory for specific patched kernel versions. No configuration workarounds are available; remediation requires a kernel upgrade and reboot. Organizations should prioritize patching systems that run untrusted code or operate in multi-tenant environments.

Patch guidance

Obtain and deploy the patched Linux kernel version from your distribution (Red Hat, Debian, Ubuntu, SUSE, etc.). Most major distributions have released updates addressing this issue. Verify the kernel version post-reboot using `uname -r` and confirm the patch is present by checking kernel release notes for the SO_ATTACH_FILTER restriction. Test updates in non-production environments first, as kernel updates require system reboot.

Detection guidance

Monitor audit logs and kernel security event logs for denied SO_ATTACH_FILTER operations on TCP sockets. Tools like `auditctl` and `ausearch` can track socket option calls. Identify processes attempting SO_ATTACH_FILTER that lack CAP_NET_ADMIN capability. Proactive detection on unpatched systems is difficult without kernel instrumentation; focus detection on confirming patch deployment rather than identifying active exploitation.

Why prioritize this

Although rated CVSS 5.5 (Medium), this vulnerability merits prioritization in multi-tenant, containerized, or shared systems where unprivileged user isolation is critical. It enables local privilege escalation and TCP connection hijacking, both high-impact attack outcomes. Organizations with strict separation requirements between user accounts or tenants should treat this as higher priority. Standard single-user or air-gapped deployments face lower risk.

Risk score, explained

The CVSS 3.1 score of 5.5 reflects local attack vector (AV:L), low attack complexity (AC:L), low privileges required (PR:L), no user interaction (UI:N), and high availability impact (A:H) with no confidentiality or integrity impact noted in the vector. However, the actual information disclosure risk (TCP sequence leakage) and privilege escalation potential suggest organizations may assess risk higher in sensitive environments. The score does not fully capture the implications for connection hijacking; use as a baseline and adjust for your environment's threat model.

Frequently asked questions

Do I need to patch if I run a single-user or dedicated-purpose Linux system?

Lower risk, but still recommended. If your system only runs trusted code or services you control, the attack surface is reduced. However, patching remains advisable for long-term security posture and to prevent future vulnerabilities in related code paths.

Can this be exploited from a container without special capabilities?

Yes. An unprivileged container can exploit this against the host kernel if the container runtime does not restrict socket options or if the kernel is unpatched. This is particularly concerning in Kubernetes clusters or shared container platforms where containers from different tenants or applications run on the same host.

Will patching require application downtime?

Yes. Kernel patches require a reboot to take effect. Plan patching during maintenance windows. Use rolling updates or load balancing to minimize service disruption if you operate in a redundant infrastructure.

What does CAP_NET_ADMIN actually do, and could dropping it break legitimate applications?

CAP_NET_ADMIN permits raw socket access, network namespace manipulation, and other privileged network operations. Dropping it will break applications that rely on SO_ATTACH_FILTER (mainly packet capture tools like tcpdump). Ensure privileged container or system services that require packet filtering run with this capability; most user-facing applications will not be affected.

This analysis is provided for informational purposes and reflects the ground-truth data available as of the publication date. Patch availability, version numbers, and distribution-specific guidance should be verified against official Linux vendor security advisories. No exploit code or weaponized proofs-of-concept are provided or endorsed. Organizations should conduct their own risk assessment and testing before deploying patches in production environments. Source: NVD (public-domain), retrieved 2026-08-03. Analysis generated by SEC.co (claude-haiku-4-5).