Cilium is a networking, observability, and security solution with an eBPF-based dataplane. In version 1.13.0, when Cilium is started, there is a short period when Cilium eBPF programs are not attached to the host. During this period, the host does not implement any of Cilium's featureset. This can cause disruption to newly established connections during this period due to the lack of Load Balancing, or can cause Network Policy bypass due to the lack of Network Policy enforcement during the window. This vulnerability impacts any Cilium-managed endpoints on the node (such as Kubernetes Pods), as well as the host network namespace (including Host Firewall). This vulnerability is fixed in Cilium 1.13.1 or later. Cilium releases 1.12.x, 1.11.x, and earlier are not affected. There are no known workarounds.
Impact
An attacker with the ability to update pod labels can cause Cilium to apply incorrect network policies.
This issue arises due to the fact that on pod update, Cilium incorrectly uses user-provided pod labels to select the policies which apply to the workload in question.
This can affect:
Cilium network policies that use the namespace, service account or cluster constructs to restrict traffic Cilium clusterwide network policies that use Cilium namespace labels to select the Pod Kubernetes network policies
Non-existent construct names can be provided, which bypass all network policies applicable to the construct. For example, providing a pod with a non-existent namespace as the value of the io.kubernetes.pod.namespace label results in none of the namespaced CiliumNetworkPolicies applying to the pod in question.
This attack requires the attacker to have Kubernetes API Server access, as described in the Cilium Threat Model.
Patches
This issue affects:
- Cilium <= v1.14.1 - Cilium <= v1.13.6 - Cilium <= v1.12.13
This issue has been resolved in:
- Cilium v1.14.2 - Cilium v1.13.7 - Cilium v1.12.14
Workarounds
An admission webhook can be used to prevent pod label updates to the k8s:io.kubernetes.pod.namespace and io.cilium.k8s.policy. keys.
Acknowledgements The Cilium community has worked together with members of Palantir and Isovalent to prepare these mitigations. Special thanks to @odinuge for reporting this issue and to @nebril for the fix.
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 in Cilium, we strongly encourage you to report it 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
An attacker with the ability to create or modify CiliumNetworkPolicy objects in a particular namespace is able to affect traffic on an entire Cilium cluster, potentially bypassing policy enforcement in other namespaces.
By using a crafted endpointSelector that uses the DoesNotExist operator on the reserved:init label, the attacker can create policies that bypass namespace restrictions and affect the entire Cilium cluster. This includes potentially allowing or denying all traffic.
This attack requires API server access, as described in the Kubernetes API Server Attacker section of the Cilium Threat Model.
Patches
This issue was patched in https://github.com/cilium/cilium/pull/28007
This issue affects:
- Cilium <= v1.14.1 - Cilium <= v1.13.6 - Cilium <= v1.12.13
This issue has been resolved in:
- Cilium v1.14.2 - Cilium v1.13.7 - Cilium v1.12.14
Workarounds
An admission webhook can be used to prevent the use of endpointSelectors that use the DoesNotExist operator on the reserved:init label in CiliumNetworkPolicies.
Acknowledgements The Cilium community has worked together with members of Palantir and Isovalent to prepare these mitigations. Special thanks to @odinuge for reporting this issue and @joestringer for the fix.
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 in Cilium, we strongly encourage you to report it to our private security mailing list at security@cilium.io first, before disclosing it in any public forum. This is a private mailing list for Cilium's internal 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 (with the --envoy-dump flag set) against Cilium deployments with the Envoy proxy enabled.
Users of the following features are affected:
- TLS inspection - Ingress with TLS termination - Gateway API with TLS termination - Kafka network policies with API key filtering
The sensitive data includes:
- The CA certificate, certificate chain, and private key used by Cilium HTTP Network Policies, and when using Ingress/Gateway API - The API keys used in Kafka-related network policy
cilium-bugtool is a debugging tool that is typically invoked manually and does not run during the normal operation of a Cilium cluster.
Patches
This issue affects:
- Cilium v1.13 between v1.13.0 and v1.13.16 inclusive - Cilium v1.14 between v1.14.0 and v1.14.11 inclusive - Cilium v1.15 between v1.15.0 and v1.15.5 inclusive
This issue has been patched in:
- Cilium v1.15.6 - Cilium v1.14.12 - Cilium v1.13.17
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 @sayboras 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.
Cilium is a networking, observability, and security solution with an eBPF-based dataplane. Prior to versions 1.11.15, 1.12.8, and 1.13.1, under specific conditions, Cilium may misattribute the source IP address of traffic to a cluster, identifying external traffic as coming from the host on which Cilium is running. As a consequence, network policies for that cluster might be bypassed, depending on the specific network policies enabled.
This issue only manifests when Cilium is routing IPv6 traffic and NodePorts are used to route traffic to pods. IPv6 and endpoint routes are both disabled by default.
The problem has been fixed and is available on versions 1.11.15, 1.12.8, and 1.13.1. As a workaround, disable IPv6 routing.
Impact
When run in debug mode, Cilium may log sensitive information.
In particular, Cilium running in debug mode will log the values of headers if they match HTTP network policy rules. This issue affects Cilium versions:
- 1.7. to 1.10. inclusive - 1.11. before 1.11.16 - 1.12. before 1.12.9 - 1.13. before 1.13.2
In addition, Cilium 1.12. before 1.12.9 and 1.13. before 1.13.2., when running in debug mode, might log secrets used by the Cilium agent. This includes TLS private keys for Ingress and GatewayAPI resources, depending on the configuration of the affected cluster. Output of the confidential data would occur at Cilium agent restart, when the secrets are modified, and on creation of Ingress or GatewayAPI resources.
Patches
This vulnerability is fixed in Cilium releases 1.11.16, 1.12.9, and 1.13.2.
Workarounds Disable debug mode.
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.
Cilium is a networking, observability, and security solution with an eBPF-based dataplane. Prior to versions 1.11.15, 1.12.8, and 1.13.1, an attacker with access to a Cilium agent pod can write to /opt/cni/bin due to a hostPath mount of that directory in the agent pod. By replacing the CNI binary with their own malicious binary and waiting for the creation of a new pod on the node, the attacker can gain access to the underlying node.
The issue has been fixed and the fix is available on versions 1.11.15, 1.12.8, and 1.13.1. Some workarounds are available. Kubernetes RBAC should be used to deny users and service accounts exec access to Cilium agent pods. In cases where a user requires exec access to Cilium agent pods, but should not have access to the underlying node, no workaround is possible.
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.
Impact
In Cilium clusters where Cilium's Layer 7 proxy has been disabled, creating workloads with
- policy.cilium.io/proxy-visibility annotations (in Cilium >= v1.13) - io.cilium.proxy-visibility annotations (in Cilium <= v1.12)
causes the Cilium agent to segfault on the node to which the workload is assigned.
Existing traffic on the affected node will continue to flow, but the Cilium agent on the node will not able to process changes to workloads running on the node. This will also prevent workloads from being able to start on the affected node. The denial of service will be limited to the node on which the workload is scheduled, however an attacker may be able to schedule workloads on the node of their choosing, which could lead to targeted attacks.
Patches
Pull request with fix
This issue affects:
Cilium <= v1.14.1 Cilium <= v1.13.6 Cilium <= v1.12.13
This issue has been resolved in:
Cilium v1.14.2 Cilium v1.13.7 Cilium v1.12.14
Workarounds
Users can avoid this denial of service attack by enabling the Layer 7 proxy.
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.