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.
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 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
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.