CVE-2026-45860

What it actually does

This flaw affects the Linux kernel netfilter connection counting logic used by nft_connlimit, xt_connlimit, and similar Open vSwitch connection-limit configurations. Under high connection churn, garbage collection of expired connection-count entries can be skipped too aggressively because cleanup is limited per kernel jiffy. If more new connections are tracked than the cleanup path can retire, stale entries may remain long enough for the connection counter to reach configured limits incorrectly. The practical technical effect is a network-triggerable denial of service: legitimate new connections can be rejected or throttled even when real active usage is below the configured limit. The CVSS vector indicates remote, unauthenticated exploitation with low complexity and high availability impact, but no confidentiality or integrity impact.

Why it matters to the business

Systems that rely on Linux netfilter or Open vSwitch connection limiting can incorrectly deny legitimate traffic during bursts of new connections or slow-connection activity. This can cause service degradation, failed user sessions, API timeouts, load balancer or firewall enforcement anomalies, and apparent application outages even when backend services are otherwise healthy. Internet-facing services, high-traffic gateways, reverse proxies, Kubernetes nodes, firewalls, and network appliances based on affected Linux kernels are the most operationally exposed. The vulnerability is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so prioritization should be risk-based; however, the network-reachable unauthenticated availability impact justifies timely kernel maintenance for exposed systems.

How an attack unfolds

An attacker first identifies a service or network path protected by Linux netfilter connection limiting, such as nft_connlimit, xt_connlimit, or an OVS connection limit. They then generate a large number of new or long-lived connections at a rate that exceeds the vulnerable cleanup behavior, for example using slow HTTP-style traffic or rapid connection churn. Because the kernel connection-count garbage collector does not clean stale entries quickly enough, expired connection records can remain counted. Over time, the affected host or gateway may believe the connection limit has been reached even though many counted connections are no longer valid. Once the limit is falsely reached, legitimate clients may be rejected, throttled, or unable to establish sessions, producing a denial-of-service condition. Exploitation does not require authentication, user interaction, or code execution; the attacker only needs network reachability to a path where vulnerable connection limiting is enabled.

How to fix it

Upgrade to a Linux kernel version that includes the netfilter nf_conncount fix increasing the cleanup limit and correcting the same-jiffy garbage-collection skip behavior. Because no exact fixed versions were provided, use the security advisory from the Linux distribution, appliance vendor, cloud image provider, or kernel maintainer for the affected kernel branch, and apply the relevant kernel update. Reboot into the fixed kernel after installation, since kernel package installation alone is not sufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by disabling or relaxing affected nft_connlimit, xt_connlimit, or OVS connection-limit rules where safe; rate-limit abusive sources upstream; place resilient DDoS or reverse-proxy controls in front of exposed services; tune service-level connection handling; and monitor for false connection-limit saturation during bursts. Mitigations should be treated as temporary because the underlying issue is in kernel cleanup behavior.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is at a vendor-fixed build using commands such as uname -r and the distribution package manager. Review vendor changelogs or kernel commit history for the netfilter nf_conncount cleanup-limit fix. Inventory active connection-limit usage by reviewing nftables rulesets, iptables rules using connlimit, and Open vSwitch or firewall policies that enforce connection limits. In a controlled test environment, reproduce high connection churn against a protected service and verify that stale connection counts are cleaned up and legitimate new connections are not incorrectly rejected after bursts subside. Operationally, validate that connection-limit rejection metrics, firewall counters, application 4xx/5xx spikes, TCP resets, and client timeout rates return to expected levels after patching.

Typical attack path

1. Reconnaissance: identify an exposed service, gateway, firewall, load balancer, Kubernetes node, or OVS path using Linux connection-limit controls.
2. Confirm that traffic is subject to connection counting or per-source/per-service connection limits, often inferred from connection rejection behavior under load.
3. Generate many new connections or slow, long-lived connections to the protected service at a rate high enough to outpace vulnerable cleanup behavior.
4. Cause stale connection-count entries to accumulate in the kernel connlimit data structures.
5. Drive the effective connection counter to the configured limit even when real active connections are lower.
6. Sustain traffic so legitimate users or upstream systems are denied, throttled, reset, or experience timeouts.

How to detect it

To determine whether this was already exploited, focus on availability and network-control telemetry rather than malware artifacts. Review firewall, nftables, iptables, Open vSwitch, load balancer, reverse proxy, and application logs for periods where connection-limit counters or drops spiked while backend capacity remained otherwise normal. Look for bursts of new connections, slow HTTP behavior, many long-lived idle connections, repeated client timeouts, TCP resets, SYN/SYN-ACK imbalance, or per-source connection churn immediately preceding service degradation. Kernel logs may not contain a vulnerability-specific message, so correlate rule counters, conntrack statistics, service logs, and network flow data. Useful sources include nft list ruleset counters, iptables rule counters, conntrack -S output collected by monitoring, OVS flow statistics, web server access/error logs, reverse proxy logs, NetFlow/IPFIX, packet captures, and DDoS telemetry. Since no known threat actors or ransomware campaigns are associated in the provided data, detection should be behavior-based: identify suspicious traffic patterns that cause connection-limit denials without a proportional number of genuinely active sessions.

• iptables connlimit
• nft_connlimit
• xt_connlimit
• nf_conncount
• nft list ruleset
• conntrack -S
• insert_failed
• drop
• reject
• connection limit
• too many connections
• client timed out
• upstream timed out
• connection reset by peer
• slowhttptest
• Slowloris
• ovs-ofctl dump-flows
• ovs-appctl dpctl/show
• SYN flood
• TCP reset

What your security team should do

• Prioritize patching internet-facing Linux systems, firewalls, gateways, reverse proxies, Kubernetes nodes, and OVS deployments that use nft_connlimit, xt_connlimit, or connection-limit policies.
• Use vendor kernel advisories to identify the exact fixed package for each distribution or appliance, then reboot and verify the running kernel version.
• Inventory where connection limits are configured with nftables, iptables, Open vSwitch, host firewalls, or network appliances derived from Linux.
• Add monitoring for sudden increases in connection-limit drops, TCP resets, SYN backlog pressure, service timeouts, and long-lived incomplete HTTP sessions.
• If patching must be delayed, apply upstream rate limiting, DDoS filtering, or temporary rule adjustments to reduce attacker ability to create high connection churn.
• Review recent availability incidents on affected services for patterns consistent with false connection-limit saturation.
• Because this is not currently KEV-listed and has low EPSS, balance urgency against exposure, but do not defer on systems where availability is business-critical.