EUVD-2026-38723
GHSA-qgcc-gwgq-pq62
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H
Triggered by inbound packets (PR:N) but only against a non-default strict multi-element xt_policy IPsec ruleset (AC:H); impact is a limited policy-matching bypass affecting filtering integrity, with minor confidentiality and availability effects.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H
Lifecycle Timeline
5DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_policy: fix strict mode inbound policy matching
match_policy_in() walks sec_path entries from the last transform to the first one, but strict policy matching needs to consume info->pol[] in the same forward order as the rule layout.
Derive the strict-match policy position from the number of transforms already consumed so that multi-element inbound rules are matched consistently.
AnalysisAI
Incorrect strict-mode policy matching in the Linux kernel's netfilter xt_policy module causes multi-element inbound IPsec policy rules to be evaluated in the wrong order, so packets can be matched against the wrong transform descriptor. On systems that filter inbound traffic with iptables/nftables 'policy' matches in strict mode using multiple policy elements, this can let traffic that should be rejected satisfy the rule (or legitimate IPsec traffic fail it), undermining the intended firewall/IPsec enforcement. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires a system using the netfilter xt_policy match in STRICT mode with a MULTI-ELEMENT inbound policy rule (info->pol[] containing more than one policy element corresponding to multiple stacked IPsec transforms) on the inbound (dir in) direction - this is a non-default, IPsec-specific firewall configuration that an administrator must have explicitly created. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | Signals are mixed and should be read carefully. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | On a gateway that uses strict-mode xt_policy rules with several stacked transforms (e.g. nested tunnel + transport IPsec) to admit only properly IPsec-protected inbound traffic, an attacker crafts traffic whose secpath ordering causes the rule to be evaluated against the wrong policy element, letting packets that do not actually satisfy the intended policy pass the match. … |
| Remediation | Apply the vendor-released patch by upgrading to a fixed stable kernel: 5.10.258, 5.15.209, 6.1.175, 6.6.141, 6.12.91, 6.18.33, 7.0.10, or 7.1 (or later within each series), matching your distribution's backport. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
24 hours: Identify Linux systems using iptables/nftables policy matching in strict mode that process IPsec traffic; assess exposure scope. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today