CVE-2026-52920

What it actually does

This is an authorization-bypass logic flaw in the Linux kernel netfilter xt_policy match module, which is used by iptables/netfilter rules to match packets based on IPsec/XFRM policy attributes. For inbound traffic, strict policy matching incorrectly walked IPsec transform entries in one order while consuming the configured rule elements in another. As a result, multi-element inbound rules using strict policy matching could be evaluated inconsistently, causing packets to match rules they should not match or fail to match rules they should match. The impact is limited to systems whose packet-filtering policy depends on xt_policy inbound strict matching with multiple policy elements; it is not a memory corruption or direct code-execution issue.

Why it matters to the business

Systems that rely on Linux netfilter rules to enforce IPsec-based access control may make incorrect allow or deny decisions. In practical terms, traffic that administrators intended to block could be accepted, or legitimate protected traffic could be dropped, potentially weakening network segmentation, VPN enforcement, or gateway filtering. The low EPSS score and lack of known exploitation or KEV listing indicate no current broad exploitation signal, but the risk is meaningful for firewalls, VPN gateways, routers, and servers that use complex inbound IPsec policy matching.

How an attack unfolds

An attacker would need to send traffic that is evaluated by a vulnerable Linux host using netfilter xt_policy inbound strict matching. The attacker’s traffic must traverse IPsec/XFRM processing in a way that creates multiple transform or policy elements relevant to the rule. Because the kernel evaluates the inbound transform path in an inconsistent order, the attacker may be able to construct or use traffic whose policy attributes cause the netfilter rule to evaluate differently than intended. If the affected rule is used to permit only specific IPsec-protected traffic, the attacker may bypass that intended restriction; if it is used for blocking or logging, the attacker may avoid the expected enforcement or visibility. Exploitation is configuration-dependent and most plausible where the attacker is an IPsec peer, can influence IPsec-protected traffic, or can route traffic through an affected VPN/firewall path.

How to fix it

Upgrade the Linux kernel to a vendor build that includes the upstream fix for xt_policy inbound strict policy matching. Because no product-specific fixed versions were provided, use the security advisory from the relevant Linux distribution or appliance vendor and install the first kernel version that includes the fix for CVE-2026-52920. Reboot into the patched kernel after installation. As a temporary mitigation, review iptables rules that use the policy match module, especially inbound rules using strict mode with multiple policy elements, and simplify or replace them where possible. Consider enforcing equivalent IPsec authorization in XFRM policy configuration, nftables rules, routing controls, or higher-level access controls until the kernel is patched.

How to confirm the fix worked

Confirm that the running kernel version is the patched vendor version, not only that the package is installed. On Linux systems, compare `uname -r` with the installed kernel package and the vendor advisory. Review active packet-filtering rules for exposure by searching for iptables rules using policy matching, especially inbound strict rules with multiple policy requirements. Commands such as `iptables-save`, `ip6tables-save`, and distribution-specific firewall tooling can be used to identify `-m policy`, `--dir in`, and `--strict` usage. Where feasible, perform a controlled test with representative IPsec traffic to verify that intended allow, deny, and logging rules behave correctly after patching.

Typical attack path

1. Identify a Linux system acting as an IPsec endpoint, VPN gateway, router, or firewall that uses iptables/netfilter policy matching.
2. Determine or infer that inbound rules use the xt_policy match in strict mode with multiple policy elements.
3. Send IPsec-protected inbound traffic with transform/policy characteristics that interact with the strict multi-element rule ordering bug.
4. Cause the vulnerable kernel to evaluate the packet against the wrong policy element order.
5. Reach a rule outcome that differs from the administrator’s intent, such as accepting traffic that should have been denied or avoiding expected logging/filtering.

How to detect it

There are no unique exploit artifacts for this vulnerability, and exploitation is likely to look like ordinary IPsec-protected traffic that was incorrectly allowed or denied. Detection should focus on exposure and behavioral anomalies. Review firewall and kernel logs for inbound traffic accepted by rules using policy matching where the expected policy chain should not have matched. Examine iptables or ip6tables logging rules, syslog/journald kernel messages, VPN gateway logs, IPsec daemon logs such as strongSwan or libreswan, XFRM state and policy changes, and network flow records. Look for unexpected source or destination pairs crossing an IPsec-enforced boundary, unusual rule-hit count increases on policy-based accept rules, missing hits on expected drop/log rules, or traffic that appears under a different IPsec transform sequence than intended. If historical packet-filter logs include rule prefixes, correlate accepted inbound IPsec traffic with the affected rule set and compare it against intended policy definitions. Absence of these artifacts does not prove non-exploitation because the flaw does not inherently create files, processes, crash logs, or distinctive packet signatures.

• -m policy
• --dir in
• --strict
• xt_policy
• policy match
• XFRM
• xfrm_state
• xfrm_policy
• IPsec
• strongSwan
• charon
• libreswan
• pluto

What your security team should do

• Inventory Linux systems that terminate IPsec, act as VPN gateways, routers, firewalls, or enforce traffic policy using iptables/netfilter.
• Prioritize patching systems that use xt_policy inbound strict matching with multi-element IPsec policy rules.
• Upgrade to a vendor kernel containing the fix and reboot into the patched kernel.
• Search firewall configurations for `-m policy`, `--dir in`, and `--strict`; simplify affected rules or add compensating controls if immediate patching is not possible.
• Monitor IPsec gateways and firewalls for unexpected inbound accepted traffic, denied traffic anomalies, and changes in packet-filter rule hit counts.
• Because there is no known active exploitation signal, treat this as configuration-dependent hardening unless the affected systems protect sensitive network boundaries.