In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix metadatadst leak bpfredirectneighv{4,6}

Cilium has a BPF egress gateway feature which forces outgoing K8s Pod traffic to pass through dedicated egress gateways which then SNAT the traffic in order to interact with stable IPs outside the cluster.

The traffic is directed to the gateway via vxlan tunnel in collect md mode. A recent BPF change utilized the bpfredirectneigh() helper to forward packets after the arrival and decap on vxlan, which turned out over time that the kmalloc-256 slab usage in kernel was ever-increasing.

The issue was that vxlan allocates the metadatadst object and attaches it through a fake dst entry to the skb. The latter was never released though given bpfredirectneigh() was merely setting the new dst entry via skbdstset() without dropping an existing one first.

Impact

CiliumNetworkPolicys which use egress.toGroups.aws.securityGroupsIds to reference AWS security group IDs that do not exist or are not attached to any network interface may unintentionally allow broader outbound access than intended by the policy authors. In such cases, the toCIDRset section of the derived policy is not generated, which means outbound traffic may be permitted to more destinations than originally intended.

Patches

This issue has been patched in:

Cilium v1.18.4 Cilium v1.17.10 Cilium v1.16.17

This issue affects:

- Cilium v1.18 between v1.18.0 and v1.18.3 inclusive - Cilium v1.17 between v1.17.0 and v1.17.9 inclusive - Cilium v1.16.16 and below

Workarounds

There is no workaround to this issue.

Acknowledgements

The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @SeanEmac for reporting this issue and to @fristonio for the patch.

For more information

If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and your report will be treated as top priority.

Impact

In Cilium clusters using Gateway API, users with permissions to create or update namespaced HTTPRoutes can mirror HTTP traffic to any Service in any namespace, bypassing the ReferenceGrant authorization mechanism.

Gateway API functionality is disabled by default.

Patches

This issue affects:

Cilium v1.19 from v1.19.0 to v1.19.4 inclusive Cilium v1.18 from v1.18.0 to v1.18.10 inclusive All versions of Cilium before v1.17.17

This issue is patched in:

Cilium v1.19.5 Cilium v1.18.11 Cilium v1.17.17

Workarounds

There is no workaround to this issue. Users of this feature who are unable to upgrade can mitigate the risk by ensuring that RBAC permissions to create HTTPRoute objects are only granted to cluster admins.

Acknowledgements

The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @galanko for reporting the issue and @mhofstetter for their work on triaging and remediating this issue.

For more information

If you have any questions or comments about this advisory, please reach out on Slack.

If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and your report will be treated as top priority.

Impact

Standard Kubernetes NetworkPolicy specifications using CIDR-based ipBlock rules without pod or namespace selectors erroneously generate a wildcard namespace allow rule under specific cluster configurations.

When Cilium deployment is configured with a specific custom clusterName (rather than the default "any" value), the parser incorrectly instantiates a pod selector on selectorless peer definitions. This leads to Cilium appending an unintended wildcard namespace label selector to the policy's allowed Layer 3 rules, which allows traffic from other workloads in the same namespace as the subject of the policy.

Example policy affected by this issue: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-server namespace: default spec: podSelector: matchLabels: app: test-server policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 192.0.2.3

In affected versions, this policy erroneously allows the test-server Pod in the default namespace to receive any traffic from other workloads running in the default namespace.

Patches

This issue has been patched in:

- Cilium v1.19.5

Releases below v1.19.0 are not affected.

This issue affects:

- Cilium v1.19 between v1.19.0 and v1.19.4 inclusive

Workarounds

Developers can create the equivalent policy using CiliumNetworkPolicy fromCIDR expressions. CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy are not affected by this issue.

Acknowledgements

Special thanks to @TheBeeZee for reporting this issue and preparing the fix, and to @fristonio and @odinuge for their assistance in reviewing the solution.

For more information

If a vulnerability affecting Cilium appears to have been found, the Cilium security team strongly encourages reporting it to the security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and the report will be treated as top priority.

Impact

When Cilium L7 functionality is enabled on a cluster, the Envoy instance supporting this functionality creates a world-accessible socket on cluster nodes. A local attacker would be able to access Envoy admin endpoints. Depending on deployment configuration, this can expose sensitive information or allow disruptive administrative operations, such as:

- Exposing TLS secrets - Disrupting traffic in the cluster - Terminating the Envoy process

This issue affects both the embedded and standalone Envoy deployment models.

Patches

This issue affects:

- Cilium v1.19 between v1.19.0 and v1.19.1 inclusive - Cilium v1.18 between v1.18.0 and v1.18.7 inclusive - All versions of Cilium prior to v1.17.14

This issue has been patched in https://github.com/cilium/cilium/pull/44512, included in:

- Cilium v1.19.2 - Cilium v1.18.8 - Cilium v1.17.14

Workarounds

There is no known workaround to this issue.

Acknowledgements

The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to moemen for reporting the issue and 0xch4z for their work on triaging and remediating this issue.

For more information

If there are any questions or comments about this advisory, please reach out on [Slack (https://docs.cilium.io/en/latest/community/community/).

If anyone thinks they have found a vulnerability affecting Cilium, it is strongly encouraged to report it to the security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and the report will be treated as a top priority.

Hi Alexander, xylove21's AI sent us 4 other claimed vulnerability reports to oss-security, but not actually this one you're replying to (and I just checked the logs, found no trace of it - not even spam-filtered). I suspect we may have been the initial target for this activity; we received a test email to security () cilium io prior to this email. Additionally, this report has unusual formatting. The email body suggests an intention to send the disclosure to openwall with CC to our list, but the email itself was sent directly to our security list. Have you looked into the reported issue and determined whether it's real or not? I ask so that we have extra input on how to treat other reports by xylove21. The feature discussed in the disclosure is an alpha feature that we've been developing this cycle. We identified and fixed the reported issue as part of development activities, so it will not be part of a stable release. The report from xylove21 accurately identified the commit and PR that introduced the bug, as well as the commit that fixed the bug and corresponding PR.

If you asked a model to read git logs to identify changes with security impact, it would probably point to the fix commit referenced in the original message. The combination of "fix" and "network policy" in a commit title is likely sufficient signal. Evidently the claw was also directed to identify which commit may have introduced the issue. I would guess the motivation was to identify known issues which may not have had a public disclosure, and attempt to file a CVE for the issue to claim some credit. Given these versions are not recommended for production and the feature is alpha, we do not see a motivation to file a CVE.

Cheers, Joe

On Tue, Jul 7, 2026 at 11:26 AM Solar Designer <solar () openwall com> wrote: Hello Feroz,

xylove21's AI sent us 4 other claimed vulnerability reports to oss-security, but not actually this one you're replying to (and I just checked the logs, found no trace of it - not even spam-filtered).

Given the confusion about embargoes vs. publication and a lot of other aspects like this, I doubt the vulnerabilities are for real. It feels like a less capable model from last year or older, not state of the art.

On Tue, Jul 07, 2026 at 09:07:11PM +0530, Feroz Salam wrote: As noted in your report, the issue you have reported only affects development snapshots of Cilium, and no released stable versions. We do not expect these development snapshots to be used in production environments, and do not see the benefit of CVE issuance in this case. Have you looked into the reported issue and determined whether it's real or not? I ask so that we have extra input on how to treat other reports by xylove21. From: xylove21 <xuy0515 () gmail com> Unlike the xylove21 () proton me address these reports were sent from, the above Gmail address actually exists, and we got a response from it (probably also written by AI) on another issue. - 2026-06-29 19:56 +08:00 — Filing publicly via oss-security (escalation after 9 days of GHSA Triage silence). - 90-day public disclosure timeline: public release 2026-09-22 (or upon upstream fix in v1.20.0 stable, whichever comes first). If an AI is so poor it "thinks" there's distinction between "Filing publicly" and "public disclosure", it feels unlikely its "reasoning" about the claimed vulnerabilities is sound.

Alexander

-- You received this message because you are subscribed to the Google Groups "Cilium Security Response Team" group. To unsubscribe from this group and stop receiving emails from it, send an email to cilium-security+unsubscribe () isovalent com. To view this discussion visit https://groups.google.com/a/isovalent.com/d/msgid/cilium-security/20260707182636.GA20763%40openwall.com.

Hello,

As noted in your report, the issue you have reported only affects development snapshots of Cilium, and no released stable versions. We do not expect these development snapshots to be used in production environments, and do not see the benefit of CVE issuance in this case.

Regarding the lack of response from the Cilium project, we responded to your GitHub security advisory submission on 30 June to inform you that we were triaging your report. Your initial report mentions that you are "willing to wait up to 90 days from this report" before disclosure, but filing this issue publicly contradicts your stated timeline.

Feroz Salam Cilium Security Team

On Tue, 7 Jul 2026 at 18:26, 'xylove21' via Cilium Security Response Team < cilium-security () isovalent com> wrote: From: xylove21 <xuy0515 () gmail com> To: oss-security () lists openwall com Cc: security () cilium io Subject: [CVE request] Cilium ClusterNetworkPolicy matchExpressions Values silently dropped — 0-day in v1.20.0-pre releases, no maintainer response in 9 days via GHSA Triage

Hi oss-security,

Filing this publicly because the Cilium project's GitHub Security Advisory has been in Triage state for 9 days with no maintainer engagement, and the chrome 9222 / GitHub UI block in this environment prevents direct follow-up on the GHSA thread. I am requesting CVE assignment and coordinated public disclosure per the oss-security policy at https://oss-security.openwall.org/wiki/mailing-lists/oss-security.

Summary

Cilium's ClusterNetworkPolicy CRD ( sigs.k8s.io/network-policy-api/v1alpha2 <http://sigs.k8s.io/network-policy-api/v1alpha2>) is parsed in pkg/k8s/clusternetworkpolicy.go::toSlimLabelSelector. The conversion of metav1.LabelSelectorRequirement → slimmetav1.LabelSelectorRequirement silently drops every Values slice when the operator is In, NotIn, Equals, or NotEquals. The bug was introduced in PR #42338 (merged 2026-02-13) and silently fixed in PR #46253 / commit 241b4b35 (merged 2026-05-29) — but never released in a stable tagged version.

The result: every CNP / CiliumClusterwideNetworkPolicy selector that uses matchExpressions (alone or combined with matchLabels) silently fails to enforce. In {a, b} matches nothing (fail-open for Deny); NotIn {a, b} matches everything (fail-closed for Allow). This is a defense-in-depth bypass with critical security impact on multi-tenant clusters.

CVSS 3.1

Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N Score: 9.6 Critical (multi-tenant / namespace-admin case)

Conservative variant (single-tenant / cluster-admin only): 8.7 High (PR:H, C:H, I:H, A:N)

Both well above the 7.0 cutoff.

- AV:N — Network (CNP applied via K8s API; bypass affects network traffic enforcement cluster-wide). - AC:L — Low complexity (apply a CNP / CiliumClusterwideNetworkPolicy with matchExpressions). - PR:L / PR:H — depends on cluster RBAC. Multi-tenant: namespace admins typically can create CNP in their namespace (PR:L). Single-tenant: cluster-admin only (PR:H). - UI:N — No user click required; policy is enforced automatically. - S:C — Scope Changed (bypass affects enforcement of other CNP / CiliumNetworkPolicy that rely on matchExpressions selectors). - C:H — Confidentiality High (Deny rules don't fire → protected data is reachable). - I:H — Integrity High (Allow-but-restrict rules match everything → over-broad write access). - A:N — No direct availability impact (separate bypass needed for the allow path).

Affected versions

The bug is only present in v1.20.0-pre releases (and main branch between 2026-02-13 and 2026-05-29). It is not present in any v1.19.x release.

| Tag | Released | Has clusternetworkpolicy.go? | Bug? | |---|---|---|---| | v1.18.x | 2025-07–2025-11 | No (feature not added yet) | N/A | | v1.19.0 | 2026-02-04 | No (branch cut before PR #42338) | N/A | | v1.19.1 | 2026-02-17 | No (branch did not backport) | N/A | | v1.19.2 | 2026-03-23 | No | N/A | | v1.19.3 | 2026-04-15 | No | N/A | | v1.19.4 | 2026-05-13 | No | N/A | | v1.20.0-pre.1 | 2026-04-01 | Yes (14771 bytes) | BUGGY (verified) | | v1.20.0-pre.2 | ~2026-04 | Yes | BUGGY (verified) | | main (post-fix) | 2026-05-29+ | Yes | FIXED (slices.Clone) | | v1.20.0 stable | not yet released | — | likely ships with fix |

Bottom line on impact scope: this is a pre-release / preview-channel bug. It affects anyone running v1.20.0-pre.1 or v1.20.0-pre.2, plus anyone who built Cilium from main between 2026-02-13 and 2026-05-29 with the enable-k8s-cluster-network-policy feature flag enabled. Stable v1.19.x production users are NOT affected.

Disclosure timeline

- 2026-06-20 17:00 +08:00 — 0-day discovered by xylove21 during a version-diff audit of Cilium v1.18 → v1.20.0-dev. - 2026-06-20 17:27 +08:00 — Independent PoC built and verified (3/3 PASS) using a self-contained Go program that reproduces toSlimLabelSelector behavior. - 2026-06-20 18:00 +08:00 — Private disclosure via GitHub Security Advisory Triage. - 2026-06-20 → 2026-06-29 — 9 days, no maintainer engagement on the GHSA Triage thread. - 2026-06-29 19:56 +08:00 — Filing publicly via oss-security (escalation after 9 days of GHSA Triage silence). - 90-day public disclosure timeline: public release 2026-09-22 (or upon upstream fix in v1.20.0 stable, whichever comes first).

Verification (independent, reproducible)

PoC at poc/main.go is a self-contained Go program with zero external dependencies that replicates the buggy toSlimLabelSelector function and demonstrates the silent Values drop. The PoC exercises:

1. In [a, b] → matches nothing (fail-open for Deny) 2. NotIn [a, b] → matches everything (fail-closed for Allow) 3. Equals [a] → matches nothing 4. NotEquals [a] → matches everything 5. Combined matchLabels + matchExpressions → matchLabels works, matchExpressions silently dropped

3/3 PASS on real v1.20.0-pre.1 source, byte-for-byte the same buggy implementation. The fix is a one-line slices.Clone() change in PR #46253.

Root cause (v1.20.0-pre)

pkg/k8s/clusternetworkpolicy.go::toSlimLabelSelector, lines 32–52 of the v1.20.0-pre source (extracted from commit bc340fe80aaa, parent of the fix):

go // VULNERABLE code in v1.20.0-pre for , matchExp := range ls.MatchExpressions { lsr := slimmetav1.LabelSelectorRequirement{ Key: matchExp.Key, Operator: slimmetav1.LabelSelectorOperator(string(matchExp.Operator)), } if matchExp.Values != nil { lsr.Values = make([]string, 0, len(matchExp.Values)) // length 0! copy(lsr.Values, matchExp.Values) // copies 0 elements } result.MatchExpressions = append(result.MatchExpressions, lsr) }

copy(dst, src) copies min(len(dst), len(src)) elements. With make([]string, 0, len(matchExp.Values)), len(dst) is 0 — so every value is silently dropped.

Fix on main (PR #46253, commit 241b4b35): go // FIXED code on main if matchExp.Values != nil { lsr.Values = slices.Clone(matchExp.Values) // correct deep copy }

Impact

The bug causes every matchExpressions selector with In, NotIn, Equals, or NotEquals to behave opposite to its declared intent:

| Operator declared | Intended behaviour | Actual behaviour on v1.20.0-pre | |---|---|---| | In {a, b} | match pods with label ∈ {a, b} | match NOTHING (fail-open for Deny) | | NotIn {a, b} | match pods with label ∉ {a, b} | match EVERYTHING (fail-closed for Allow) | | Equals {a} | match pods with label == a | match NOTHING | | NotEquals {a} | match pods with label != a | match EVERYTHING |

Attack scenarios (require K8s RBAC to create CNP):

- Defence-in-depth bypass: a tenant with pods/log or services write perms in a multi-tenant cluster can apply a CiliumClusterwideNetworkPolicy (or ClusterNetworkPolicy) that claims to deny egress to pods whose label tier=untrusted, but the matchExpressions is silently dropped → the deny never fires and egress flows unimpeded. - Compliance backdoor: an operator crafts a CNP with NotEquals [admin] selectors that looks restrictive but actually matches every pod (the compliance team reads the YAML, sees NotEquals [admin], and approves). - Self-DoS: a less-privileged admin crafts an allow rule with In [api] selectors — the rule matches nothing — so the deny-all default takes over and traffic they wanted to allow is blocked (fail-closed).

Recommendations

For Cilium maintainers: 1. Issue a security advisory (CVE) covering v1.20.0-pre.1 and v1.20.0-pre.2. 2. Explicitly note in the v1.20.0 stable release notes that the pre-release channel was vulnerable to this bug, and that the fix is in v1.20.0 stable. 3. Add a regression test that asserts matchExpressions round-trips through toSlimLabelSelector with Values preserved. 4. Consider adding a slices.Clone lint rule to the Cilium contribution guide to prevent future copy-without-clone bugs.

For users on v1.20.0-pre: 1. Upgrade to v1.20.0 stable (when released) immediately. 2. Until then, do NOT enable the enable-k8s-cluster-network-policy feature flag in production. 3. Audit any existing CNP / CiliumClusterwideNetworkPolicy with matchExpressions and rewrite them using only matchLabels if possible.

Reporter

- Handle: xylove21 - Affiliation: Independent security researcher (coordinated via 小龙虾 / team 小青蟹, 队长 大龙虾 徐岩) - Email: xuy0515 () gmail com - GitHub: https://github.com/xylove21 - Date filed (private via GHSA Triage): 2026-06-20 18:00 +08:00 - Date filed (public via oss-security): 2026-06-29 19:56 +08:00

Thanks for the review and CVE assignment.

— xylove21

-- You received this message because you are subscribed to the Google Groups "Cilium Security Response Team" group. To unsubscribe from this group and stop receiving emails from it, send an email to cilium-security+unsubscribe () isovalent com. To view this discussion visit https://groups.google.com/a/isovalent.com/d/msgid/cilium-security/178313134021.2087278.12123292660777742961%40proton.me .

Impact

For Cilium users who: - Use Gateway API for Ingress for some services AND - Use LB-IPAM or BGP for LB Service implementation AND - Use network policies to block egress traffic from workloads in a namespace to workloads in other namespaces

Egress traffic from workloads covered by such network policies to LoadBalancers configured by Gateway resources will incorrectly be allowed.

LoadBalancer resources not deployed via a Gateway API configuration are not affected by this issue.

Patches

This issue was fixed by https://github.com/cilium/proxy/pull/1172.

This issue affects:

- Cilium v1.15 between v1.15.0 and v1.15.14 inclusive - Cilium v1.16 between v1.16.0 and v1.16.7 inclusive - Cilium v1.17 between v1.17.0 and v1.17.1 inclusive

This issue is fixed in:

- Cilium v1.15.15 - Cilium v1.16.8 - Cilium v1.17.2

Workarounds

A Clusterwide Cilium Network Policy can be used to work around this issue for users who are unable to upgrade. An outline of such a policy is provided below:

apiVersion: "cilium.io/v2" kind: CiliumClusterwideNetworkPolicy metadata: name: "workaround" spec: endpointSelector: matchExpressions: - key: reserved:ingress operator: Exists ingress: - fromEntities: - world

- The policy opens up connectivity from all locations outside the cluster into the Cilium Ingress Gateway. - The policy establishes a default deny for all other traffic towards the Cilium Ingress Gateway, including all in-cluster sources. - It is possible to tailor the policy to more narrowly allow inbound traffic while creating a default deny posture for traffic between namespaces. Users should edit the policy to bring it in line with the security requirements particular to their environments.

Acknowledgements

The Cilium community has worked together with members of the Isovalent team to prepare these mitigations. Special thanks to @jrajahalme for the fix.

For more information

If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and your report will be treated as top priority.

Impact

Node based network policies (fromNodes and toNodes) will incorrectly permit traffic to/from non-node endpoints that share the labels specified in fromNodes and toNodes sections of network policies. Node based network policy is disabled by default in Cilium.

Patches

This issue was fixed by https://github.com/cilium/cilium/pull/36657.

This issue affects:

- Cilium v1.16 between v1.16.0 and v1.16.7 inclusive - Cilium v1.17 between v1.17.0 and v1.17.1 inclusive

This issue is fixed in:

- Cilium v1.16.8 - Cilium v1.17.2

Workarounds

Users can work around this issue by ensuring that the labels used in fromNodes and toNodes fields are used exclusively by nodes and not by other endpoints.

Acknowledgements

The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @oblazek for reporting and fixing this issue.

For more information

If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and your report will be treated as top priority. Please also address any comments or questions on this advisory to the same mailing list.

Impact

For Cilium users who are using CRDs to store Cilium state (the default configuration) and Wireguard transparent encryption, responses from pods to the Ingress and health endpoints are not encrypted. Traffic from the Ingress and health endpoints to pods is not affected by this issue. The health endpoint is only used for Cilium's internal health checks.

Patches

This issue affects Cilium v1.14 before v1.14.7.

This issue has been patched in Cilium v1.14.7.

Workarounds

There is no workaround to this issue - affected users are encouraged to upgrade.

Acknowledgements

The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @gandro for their work on triaging and remediating this issue.

For more information

If you have any questions or comments about this advisory, please reach out on Slack.

If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list where only members of the Cilium internal security team are subscribed to, and your report will be treated as top priority.

Impact

For Cilium users who have enabled an external kvstore and Wireguard transparent encryption, traffic between pods in the affected cluster is not encrypted.

Patches

This issue affects Cilium v1.14 before v1.14.7.

This issue has been patched in Cilium v1.14.7.

Workarounds

There is no workaround to this issue - affected users are encouraged to upgrade.

Acknowledgements

The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @giorio94 and @gandro for their work on triaging and remediating this issue.

For more information

If you have any questions or comments about this advisory, please reach out on Slack.

If you think you found a related vulnerability, we strongly encourage you to report security vulnerabilities to our private security mailing list at security@cilium.io. This is a private mailing list where only members of the Cilium internal security team are subscribed to, and your report will be treated as top priority.

Impact

When the Gateway API is enabled in Cilium, the absence of a check on the namespace in which a ReferenceGrant is created could result in Cilium gaining visibility of secrets (including certificates) and services across namespaces.

An attacker on an affected cluster can configure Cilium to use cluster secrets or communicate with services that it should not have access to.

Gateway API functionality is disabled by default.

Patches

This vulnerability is fixed in Cilium release 1.13.4.

Cilium versions <1.13 are not affected.

Workarounds

There is no workaround to this issue.

Acknowledgements The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @meyskens for investigating and fixing the issue.

For more information If you have any questions or comments about this advisory, please reach out on Slack.

As usual, if you think you found a related vulnerability, we strongly encourage you to report security vulnerabilities to our private security mailing list: security@cilium.io - first, before disclosing them in any public forums. This is a private mailing list where only members of the Cilium internal security team are subscribed to, and is treated as top priority.

Impact The output of cilium-bugtool can contain sensitive data when the tool is run against Cilium deployments with WireGuard encryption enabled.

Users of WireGuard Transparent Encryption are affected. The sensitive data is the WireGuard private key (ciliumwg0.key) used for node-to-node encrypted communication

cilium-bugtool is a debugging tool that is typically invoked manually and does not run during the normal operation of a Cilium cluster. It is also invoked when gathering sysdumps using the Cilium CLI's cilium sysdump command.

Patches This issue affects:

- Cilium v1.19 between v1.19.0 and v1.19.2 inclusive - Cilium v1.18 between v1.18.0 and v1.18.8 inclusive - All versions of Cilium prior to v1.17.15

This issue has been patched in:

- Cilium v1.19.3 - Cilium v1.18.9 - Cilium v1.17.15

Workarounds There is no workaround to this issue.

Users who have previously shared bugtool or sysdump archives from WireGuard-enabled nodes should rotate the WireGuard keys on the affected nodes. This can be done by deleting the key file and restarting the Cilium agent, which will generate a new key pair.

Acknowledgements

The Cilium community has worked together with members of Isovalent to prepare these mitigations. Cillium extends special thanks to @kodareef5 for reporting the issue and @tklauser for their work on triaging and remediating this issue.

For more information

If there are any questions or comments about this advisory, please reach out on Slack.

Cilium strongly encourages the reporting of suspected vulnerabilities to the security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and the report will be treated as top priority.

Impact

Ingress Network Policies are not enforced for traffic from pods to L7 Services (Envoy, GAMMA) with a local backend on the same node, when Per-Endpoint Routing is enabled and BPF Host Routing is disabled.

Per-Endpoint Routing is disabled by default, but is automatically enabled in deployments using cloud IPAM, including Cilium ENI on EKS (eni.enabled), AlibabaCloud ENI (alibabacloud.enabled), Azure IPAM (azure.enabled, but not AKS BYOCNI), and some GKE deployments (gke.enabled; managed offerings such as GKE Dataplane V2 may use different defaults). It is typically not enabled in tunneled deployments, and chaining deployments are not affected. In practice, Amazon EKS with Cilium ENI mode is likely the most common affected environment.

Patches

This issue was fixed by #44693.

This issue affects:

Cilium v1.19 between v1.19.0 and v1.19.1 inclusive Cilium v1.18 between v1.18.0 and v1.18.7 inclusive All versions of Cilium prior to v1.17.13

This issue is fixed in:

Cilium v1.19.2 Cilium v1.18.8 Cilium v1.17.14

Workarounds

Disclaimer: There is currently no officially verified or comprehensive workaround for this issue. The only option would be to disable per-endpoint routes, but this will likely cause disruptions to ongoing connections, and potential conflicts if running in cloud providers.

Acknowledgements

The Cilium community has worked together with members of the Northflank and Isovalent teams to prepare these mitigations. Cilium thanks @sudeephb and @Champ-Goblem for reporting the issue and to @smagnani96 and @julianwiedmann for helping with the resolution.

For more information

Anyone who believes a vulnerability affecting Cilium has been found is strongly encouraged to report it to the security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and any such report will be treated as top priority. Please also address any comments or questions on this advisory to the same mailing list.

Impact

Host Policies will incorrectly permit traffic from Pods on other nodes when all of the following configurations are enabled: Native Routing WireGuard Node Encryption (beta)

These options are disabled by default in Cilium.

Patches

This issue was fixed by #42892.

This issue affects:

Cilium v1.18 between v1.18.0 and v1.18.5 inclusive

This issue is fixed in:

Cilium v1.18.6

Workarounds

There is currently no officially verified or comprehensive workaround for this issue. The following procedure has been validated strictly within a local 'Kind' environment and has not undergone exhaustive testing across diverse production architectures. Proceed with caution.

To mitigate the identified traffic bypass, ensure all ingress traffic from the ciliumwg0 interface is explicitly routed to ciliumhost for policy enforcement. This ensures that host-level security policies are applied to decrypted WireGuard traffic. Execute the following configuration on each CiliumNode:

bash IPv4 Traffic ip rule add iif ciliumwg0 table 300 ip route add default dev ciliumhost table 300

IPv6 Traffic ip -6 rule add iif ciliumwg0 table 300 ip -6 route add default dev ciliumnet table 300

Acknowledgements

Special thanks to @julianwiedmann for reporting the issue and helping with the resolution.

For more information

If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and your report will be treated as top priority. Please also address any comments or questions on this advisory to the same mailing list.

Impact

Users of IPsec transparent encryption in Cilium may be vulnerable to cryptographic attacks that render the transparent encryption ineffective.

In particular, Cilium is vulnerable to the following attacks by a man-in-the-middle attacker:

- Chosen plaintext attacks - Key recovery attacks - Replay attacks

These attacks are possible due to an ESP sequence number collision when multiple nodes are configured with the same key. Fixed versions of Cilium use unique keys for each IPsec tunnel established between nodes, resolving all of the above attacks.

Important: After upgrading, users must perform a key rotation using the instructions here to ensure that they are no longer vulnerable to this issue. Please note that the key rotation instructions have recently been updated, and users must use the new instructions to properly establish secure IPsec tunnels. To validate that the new instructions have been followed properly, ensure that the IPsec Kubernetes secret contains a "+" sign.

Patches

All prior versions of Cilium that support IPsec transparent encryption (Cilium 1.4 onwards) are affected by this issue.

Patched versions:

- Cilium 1.15.3 - Cilium 1.14.9 - Cilium 1.13.14

Workarounds

There is no workaround to this issue. IPsec transparent encryption users are strongly encouraged to upgrade.

Acknowledgements

The Cilium community has worked together with members of Cure53 and Isovalent to prepare these mitigations. Special thanks to @NikAleksandrov and @pchaigno for their work on remediating the issue. Thanks to Marsh Ray, Senior Software Developer at Microsoft, for input and guidance on the fix.

For more information If you have any questions or comments about this advisory, please reach out on Slack.

As usual, if you think you found a related vulnerability, we strongly encourage you to report security vulnerabilities to our private security mailing list: security@cilium.io - first, before disclosing them in any public forums. This is a private mailing list where only members of the Cilium internal security team are subscribed to, and is treated as top priority.

Impact

This issue only impacts users who:

- Have a HTTP policy that applies to multiple toEndpoints AND - Have an allow-all rule in place that affects only one of those endpoints

In such cases, a wildcard rule will be appended to the set of HTTP rules, which could cause bypass of HTTP policies.

Patches

This issue has been patched in Cilium 1.11.16, 1.12.9, and 1.13.2.

Workarounds

Rewrite HTTP rules for each endpoint separately. For example, if the initial rule looks like:

egress: - toEndpoints: - matchLabels: k8s:kind: echo - matchLabels: k8s:kind: example toPorts: - ports: - port: "8080" protocol: TCP rules: http: - method: "GET"

It should be rewritten to: egress: - toEndpoints: - matchLabels: k8s:kind: echo toPorts: - ports: - port: "8080" protocol: TCP rules: http: - method: "GET" - toEndpoints: - matchLabels: k8s:kind: example toPorts: - ports: - port: "8080" protocol: TCP rules: http: - method: "GET"

Acknowledgements

The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @jrajahalme for investigating and fixing the issue.

For more information

If you have any questions or comments about this advisory, please reach out on Slack.

As usual, if you think you found a related vulnerability, we strongly encourage you to report security vulnerabilities to our private security mailing list: security@cilium.io - first, before disclosing them in any public forums. This is a private mailing list where only members of the Cilium internal security team are subscribed to, and is treated as top priority.