CVE-2026-63913

What it actually does

This flaw affects the Linux kernel netfilter TCP connection-tracking state machine. A crafted packet sequence can cause a tracked TCP flow, including a NAT entry, to be moved prematurely into the CLOSE state when an RST packet with an invalid sequence number is observed after a SYN. The vulnerable logic does not sufficiently verify that the RST is in the correct direction or that it is a valid response to a previously observed SYN in the opposite direction. The result is unauthorized manipulation of conntrack state: active or establishing connections may lose their NAT/firewall tracking entry earlier than intended, causing traffic disruption rather than code execution or data disclosure.

Why it matters to the business

Systems that rely on Linux netfilter for stateful firewalling, NAT, gateways, routers, load balancers, container networking, Kubernetes nodes, VPN concentrators, or edge appliances can experience connection interruption if exposed to crafted traffic. The practical consequence is degraded availability: users may see dropped sessions, failed connections, reconnect loops, intermittent service outages, or unstable network paths. The CVSS score indicates high availability impact, but current public exploitation signals are limited: EPSS is low, the issue is not listed in CISA KEV, it is not known to be used in ransomware campaigns, and no mature exploit is currently indicated. Even so, internet-facing or multi-tenant network infrastructure should prioritize remediation because the attack is unauthenticated and network-reachable.

How an attack unfolds

An attacker targets a Linux system that uses netfilter conntrack to track TCP flows, especially where NAT or stateful firewall decisions depend on conntrack entries. The attacker causes or observes a SYN packet for a TCP flow, then sends a crafted RST packet with an invalid TCP sequence number. Due to the vulnerable state transition logic, the conntrack entry can be forced into TCP_CONNTRACK_CLOSE even when the RST is not a valid response in the expected direction. Once the conntrack entry is closed or removed prematurely, NAT state and firewall tracking for that flow can break. The affected connection may drop, fail to establish, or require retransmission/reconnection. Repeating this against many flows can create a denial-of-service condition against services or users behind the affected Linux network path.

How to fix it

Apply the Linux kernel update from the relevant distribution or appliance vendor that includes the upstream netfilter conntrack fix for the TCP RST state transition logic. No product-specific fixed versions were provided in the input, so remediation should be based on vendor advisories and package changelogs referencing the netfilter conntrack TCP fix described as preventing CLOSE transitions from invalid-sequence RST packets without proper direction validation. Prioritize patching systems that perform NAT, stateful firewalling, routing, container networking, VPN termination, or edge packet filtering. Where immediate patching is not possible, reduce exposure by enforcing ingress and egress anti-spoofing controls, dropping obviously spoofed traffic at network boundaries, limiting who can send traffic through conntrack-protected paths, applying RST rate-limiting or anomaly filtering where operationally safe, and disabling conntrack only for traffic classes that do not require stateful inspection or NAT. Test mitigations carefully because overly broad RST filtering can break legitimate TCP behavior.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix, not just that an updated package is installed. Check the active kernel version after reboot, review distribution security advisories and package changelogs for the netfilter conntrack TCP RST fix, and confirm affected systems are no longer running an older vulnerable kernel. For functional validation, use a controlled test environment with conntrack/NAT enabled: create a TCP flow, inject a SYN followed by an invalid-sequence RST in the previously problematic direction, and verify the conntrack entry is not forced into CLOSE unless the RST is a valid response in the correct direction. Exposure can be assessed by checking whether nf_conntrack is loaded and whether the host uses NAT or stateful firewall rules, for example through kernel module status, nftables/iptables rules, conntrack table inspection, and distribution-specific firewall configuration.

Typical attack path

1. Identify or reach a Linux host or appliance performing stateful TCP tracking with netfilter conntrack, commonly a firewall, NAT gateway, router, container host, or load balancer.
2. Select target TCP flows that traverse the affected conntrack path.
3. Send or wait for a SYN packet to create or update a conntrack entry.
4. Inject a crafted TCP RST packet with an invalid sequence number and directionality that should not legitimately close the tracked connection.
5. Trigger the vulnerable conntrack state transition that marks the flow as closed.
6. Cause the NAT/firewall tracking state to be torn down prematurely, disrupting the connection.
7. Repeat the packet sequence across multiple flows to amplify availability impact.

How to detect it

Retrospective detection is difficult because exploitation occurs at the packet and connection-tracking layer and may not produce default Linux logs. Review network telemetry, firewall logs, packet captures, conntrack event logs, IDS/NSM data, and service availability metrics for periods of unexplained connection resets or NAT session churn. Useful sources include conntrack event monitoring if enabled, nftables/iptables logs for TCP RST traffic, Zeek or equivalent network metadata showing unusual reset behavior, router/firewall flow records, packet captures around outage windows, and host metrics showing spikes in TCP retransmissions, failed handshakes, or short-lived connections. Look for sequences where a SYN is followed very quickly by a TCP RST with an invalid or unexpected sequence number and where the corresponding conntrack/NAT entry closes prematurely. Because there are no known named threat actors, KEV listing, ransomware linkage, or mature public exploit signal in the provided data, treat findings as suspicious when they correlate with service disruption or originate from untrusted networks, but validate with packet-level evidence where possible.

What your security team should do

• Inventory Linux systems and appliances that use netfilter conntrack, especially NAT gateways, firewalls, routers, Kubernetes/container nodes, VPN gateways, and internet-facing edge systems.
• Prioritize kernel updates for systems on critical network paths or exposed to untrusted traffic, even though current EPSS and exploitation maturity are low.
• Track vendor advisories for the exact kernel package or appliance firmware version containing the fix and ensure systems are rebooted into the patched kernel.
• Implement or verify anti-spoofing controls at network boundaries, including source validation for ingress and egress traffic.
• Increase monitoring for abnormal TCP reset patterns, sudden connection churn, retransmission spikes, and unexplained NAT/session table turnover on Linux network devices.
• Where feasible, capture packet samples during unexplained outages to determine whether invalid-sequence RST packets are preceding conntrack state changes.
• Avoid relying on application logs alone; this issue can interrupt traffic below the application layer before meaningful application errors are produced.
• Document temporary mitigations and remove or tune them after patching to avoid long-term TCP compatibility problems.