CVE-2026-53249

What it actually does

The flaw allows an unprivileged local application on a vulnerable Linux system to set IPv4 Loose Source and Record Route (LSRR) or Strict Source and Record Route (SSRR) options on outbound packets. These legacy IP options can force traffic to traverse specified intermediate routers, potentially including attacker-controlled infrastructure. If the network path forwards those options, an attacker may observe or influence routing behavior and leak TCP initial sequence numbers or other protocol metadata. The fix restricts use of IPOPT_LSRR and IPOPT_SSRR to processes with CAP_NET_RAW.

Why it matters to the business

This is primarily a local-to-network information disclosure risk: a user or workload with low privileges on a vulnerable Linux host may be able to manipulate outbound packet routing to expose sensitive connection metadata. The practical risk is reduced in many environments because LSRR and SSRR are commonly filtered by routers, firewalls, and service providers, and current exploitation maturity is reported as none with low EPSS and no known KEV listing. However, Linux kernel prevalence is broad, so organizations should still remediate through normal kernel patching and enforce network filtering for IPv4 source-route options.

How an attack unfolds

An attacker first obtains the ability to run an unprivileged process on a vulnerable Linux system, such as through a low-privilege shell, user account, compromised application, or container workload. The process creates IPv4 sockets and sets IP options using LSRR or SSRR without needing CAP_NET_RAW. The attacker crafts outbound connections whose source-route options direct packets through a router or node under attacker control before reaching the intended destination. If intermediate network devices do not drop these IPv4 options, the attacker-controlled hop can observe routing metadata and potentially infer TCP initial sequence numbers or other protocol information. Successful exploitation depends heavily on local execution and permissive network paths that still forward source-routed IPv4 packets.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the change restricting IPOPT_LSRR and IPOPT_SSRR to CAP_NET_RAW. Where exact fixed package versions are not provided, track the vendor advisory for CVE-2026-53249 or the upstream kernel commit described as restricting IPv4 LSRR/SSRR options. As defense in depth, filter or drop IPv4 packets containing LSRR and SSRR options at host firewalls, network firewalls, routers, and ingress/egress gateways in line with RFC 7126. Remove unnecessary CAP_NET_RAW from services and containers, restrict untrusted local code execution, and use seccomp, LSM policy, or container runtime controls where feasible to limit setsockopt/IP_OPTIONS abuse. Ensure source-routed IPv4 traffic is not accepted or forwarded across controlled network boundaries.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor fix for the IPv4 IPOPT_LSRR/IPOPT_SSRR capability restriction. Review kernel package changelogs or vendor advisories for references to CVE-2026-53249, IPOPT_LSRR, IPOPT_SSRR, LSRR, SSRR, or CAP_NET_RAW. On a patched system, an unprivileged test process attempting to set LSRR or SSRR via IP_OPTIONS should fail with a permission error, while appropriately privileged CAP_NET_RAW processes may still be allowed. Validate network controls by sending or simulating IPv4 packets containing LSRR and SSRR options in a controlled test and confirming that routers, firewalls, and packet captures show the packets are dropped before leaving trusted boundaries. Verify that vulnerable kernels are no longer running after reboot, not merely installed alongside a fixed package.

Typical attack path

1. Gain the ability to execute code as an unprivileged local user or workload on a vulnerable Linux host.
2. Create IPv4 network traffic from that process and set IP_OPTIONS using IPOPT_LSRR or IPOPT_SSRR.
3. Specify a route that includes attacker-controlled or observable network infrastructure.
4. Initiate TCP or other protocol connections to external or internal destinations.
5. Rely on intermediate routers, firewalls, or gateways failing to drop LSRR/SSRR IPv4 packets.
6. Observe routed traffic or protocol metadata at the attacker-controlled hop and use the disclosed information for reconnaissance or follow-on attacks.

How to detect it

Look for signs of IPv4 packets using source-route options, which are rare in normal modern environments. Relevant telemetry includes firewall allow/drop logs, IDS/IPS alerts, router ACL logs, packet captures, Zeek/Suricata metadata, NetFlow enriched with IP option fields, and endpoint telemetry that records unusual socket option usage. Search for outbound or lateral traffic containing LSRR or SSRR, IPv4 option type 131 for Loose Source and Record Route, or IPv4 option type 137 for Strict Source and Record Route. If such traffic is found, identify the source host, user, container, process, destination, and any intermediate route addresses embedded in the option. On endpoints, investigate unprivileged processes that create raw-looking crafted traffic or call setsockopt with IP_OPTIONS shortly before unusual outbound connections. Since this issue is not known to be exploited in the wild and exploitation leaves limited host artifacts by default, absence of logs is not proof of non-exploitation; packet-level evidence and network device logs are the most useful sources.

• LSRR
• SSRR
• IPOPT_LSRR
• IPOPT_SSRR
• Loose Source and Record Route
• Strict Source and Record Route
• IPv4 option 131
• IPv4 option 137
• ip.opts.lsrr
• ip.opts.ssrr
• IP_OPTIONS
• setsockopt(IP_OPTIONS)
• source route option
• source-routed packet

What your security team should do

• Prioritize patching internet-facing, multi-user, shared compute, CI/CD runner, bastion, container host, and workload-hosting Linux systems where untrusted or semi-trusted users can execute code.
• Update affected Linux kernels through the appropriate vendor channel and reboot into the fixed kernel.
• Audit containers and services for unnecessary CAP_NET_RAW and remove it wherever possible.
• Configure routers, firewalls, and host packet filters to drop IPv4 packets containing LSRR and SSRR options.
• Add monitoring for outbound or lateral IPv4 packets with source-route options, especially from servers and workload networks where such traffic should be absent.
• Review packet captures, firewall logs, IDS logs, and NetFlow metadata for evidence of IPv4 source-route option usage since exposure began.
• Treat any observed LSRR or SSRR traffic from ordinary workloads as suspicious and investigate the originating process or host.
• Because there is no current KEV listing, no ransomware association, low EPSS, and no known public exploit maturity, handle as a normal-priority kernel hygiene issue unless local untrusted execution or permissive routing paths increase exposure.