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.
Cilium is open source software for providing and securing network connectivity and loadbalancing between application workloads. Cilium prior to versions 1.9.16, 1.10.11, and 1.11.15 contains an incorrect default permissions vulnerability. Operating Systems with users belonging to the group ID 1000 can access the API of Cilium via Unix domain socket available on the host where Cilium is running. This could allow malicious users to compromise integrity as well as system availability on that host. The problem has been fixed and the patch is available in versions 1.9.16, 1.10.11, and 1.11.5. A potential workaround is to modify Cilium's DaemonSet to run with a certain command, which can be found in the GitHub Security Advisory for this vulnerability.
Impact
A policy rule denying a prefix that is broader than /32 may be ignored if there is
- A policy rule referencing a more narrow prefix (CIDRSet or toFQDN) and - This narrower policy rule specifies either enableDefaultDeny: false or - toEntities: all
Note that a rule specifying toEntities: world or toEntities: 0.0.0.0/0 is insufficient, it must be to entity all.
As an example, given the below policies, traffic is allowed to 1.1.1.2, when it should be denied:
apiVersion: cilium.io/v2 kind: CiliumClusterwideNetworkPolicy metadata: name: block-scary-range spec: endpointSelector: {} egressDeny: - toCIDRSet: - cidr: 1.0.0.0/8
---
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: evade-deny spec: endpointSelector: {} egress: - toCIDR: - 1.1.1.2/32 - toEntities: - all
Patches
This issue affects:
- Cilium v1.14 between v1.14.0 and v1.14.15 inclusive - Cilium v1.15 between v1.15.0 and v1.15.9 inclusive
This issue has been patched in:
- Cilium v1.14.16 - Cilium v1.15.10
Workarounds
Users with policies using enableDefaultDeny: false can work around this issue by removing this configuration option and explicitly defining any allow rules required.
No workaround is available to users with egress policies that explicitly specify toEntities: all.
Acknowledgements
The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @squeed, @christarazi, and @jrajahalme for their work in triaging and resolving 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 with top priority.
Cilium is open source software for providing and securing network connectivity and loadbalancing between application workloads. Prior to versions 1.9.16, 1.10.11, and 1.11.15, if an attacker is able to perform a container escape of a container running as root on a host where Cilium is installed, the attacker can escalate privileges to cluster admin by using Cilium's Kubernetes service account. The problem has been fixed and the patch is available in versions 1.9.16, 1.10.11, and 1.11.5. There are no known workarounds available.
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
Cilium's HTTP policies are not consistently applied to all traffic in the scope of the policies, leading to HTTP traffic being incorrectly and intermittently forwarded when it should be dropped.
Patches
This issue affects:
Cilium v1.13 between v1.13.9 and v1.13.12 inclusive Cilium v1.14 between v1.14.0 and v1.14.7 inclusive Cilium v1.15.0 and v1.15.1
This issue has been patched in:
Cilium v1.15.2 Cilium v1.14.8 Cilium v1.13.13
Workarounds
There is no workaround for this issue – affected users are strongly encouraged to upgrade.
Acknowledgements
The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @romikps for discovering and reporting this issue, and @sayboras and @jrajahalme for preparing 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 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 internal security team, and your report will be treated as top priority.
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.
Impact
A race condition in the Cilium agent can cause the agent to ignore labels that should be applied to a node. This could in turn cause CiliumClusterwideNetworkPolicies intended for nodes with the ignored label to not apply, leading to policy bypass.
Patches
This issue was fixed in https://github.com/cilium/cilium/pull/33511.
This issue affects:
- All versions of Cilium before v1.14.14 - Cilium v1.15 between v1.15.0 and v1.15.7 inclusive
This issue has been patched in:
- Cilium v1.14.14 - Cilium v1.15.8
Workarounds
As the underlying issue depends on a race condition, users unable to upgrade can restart the Cilium agent on affected nodes until the affected policies are confirmed to be working as expected.
Acknowledgements
The Cilium community has worked together with members of Google and Isovalent to prepare these mitigations. Special thanks to @skmatti for raising and resolving 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
For users who deploy Hubble UI using either Cilium CLI or via the Cilium Helm chart, an insecure default Access-Control-Allow-Origin header value could lead to sensitive data exposure. A user with access to a Hubble UI instance affected by this issue could leak configuration details about the Kubernetes cluster which Hubble UI is monitoring, including node names, IP addresses, and other metadata about workloads and the cluster networking configuration. In order for this vulnerability to be exploited, a victim would have to first visit a malicious page.
Patches
This issue was patched in https://github.com/cilium/cilium/commit/a3489f190ba6e87b5336ee685fb6c80b1270d06d
This issue affects:
- Cilium between v1.14.0 and v1.14.18 inclusive - Cilium between v1.15.0 and v1.15.12 inclusive - Cilium between v1.16.0 and v1.16.5 inclusive
This issue is patched in:
- Cilium v1.14.19 - Cilium v1.15.13 - Cilium v1.16.6
Workarounds
Users who deploy Hubble UI using the Cilium Helm chart directly can remove the CORS headers from the Helm template as shown in the patch.
Acknowledgements
The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @ciffelia for reporting this issue and to @geakstr 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 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 with IPsec enabled and traffic matching Layer 7 policies:
- Traffic that should be IPsec-encrypted between a node's Envoy proxy and pods on other nodes is sent unencrypted - Traffic that should be IPsec-encrypted between a node's DNS proxy and pods on other nodes is sent unencrypted
Note: For clusters running in native routing mode, IPsec encryption is not applied to connections which are selected by a L7 Egress Network Policy or a DNS Policy. This is a known limitation of Cilium's IPsec encryption which will continue to apply after upgrading to the latest Cilium versions described below.
Patches
This issue affects:
- Cilium v1.15 before v1.15.2 - Cilium v1.14 before v1.14.8 - Cilium v1.13 before v1.13.13 - Cilium v1.4 to v1.12 inclusive
This issue has been resolved in:
- Cilium v1.15.2 - Cilium v1.14.8 - Cilium v1.13.13
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 @jschwinger233, @julianwiedmann, @giorio94, and @jrajahalme for their work in triaging and resolving 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 in Cilium, we strongly encourage you to report it to our private security mailing list at security@cilium.io. This is a private mailing list that only members of the Cilium internal security team are subscribed to, and your report will be treated as top priority.
Impact
In Cilium clusters with WireGuard enabled and traffic matching Layer 7 policies:
- Traffic that should be WireGuard-encrypted is sent unencrypted between a node's Envoy proxy and pods on other nodes. - Traffic that should be WireGuard-encrypted is sent unencrypted between a node's DNS proxy and pods on other nodes.
Patches
This issue affects:
In native routing mode (routingMode=native): Cilium v1.14 versions before v1.14.8 Cilium v1.15 versions before v1.15.2 In tunneling mode (routingMode=tunnel): Cilium v1.14 versions before v1.14.4 Cilium v1.14.4 if encryption.wireguard.encapsulate is set to false (default).
This issue has been resolved in:
In native routing mode (routingMode=native): Cilium v1.14.8 Cilium v1.15.2 In tunneling mode (routingMode=tunnel): Cilium v1.14.4. NOTE encryption.wireguard.encapsulate must be set to true. 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 @brb, @giorio94, @gandro and @jschwinger233 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.
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 a Kubernetes cluster where Cilium is configured to proxy DNS traffic, an attacker can crash Cilium agents by sending a crafted DNS response to workloads from outside the cluster.
For traffic that is allowed but without using DNS-based policy, the dataplane will continue to pass traffic as configured at the time of the DoS. For workloads that have DNS-based policy configured, existing connections may continue to operate, and new connections made without relying on DNS resolution may continue to be established, but new connections which rely on DNS resolution may be disrupted. Any configuration changes that affect the impacted agent may not be applied until the agent is able to restart.
Patches
This issue affects:
- Cilium v1.14 between v1.14.0 and v1.14.17 inclusive - Cilium v1.15 between v1.15.0 and v1.15.11 inclusive - Cilium v1.16 between v1.16.0 and v1.16.4 inclusive
This issue is fixed in:
- Cilium v1.14.18 - Cilium v1.15.12 - Cilium v1.16.5
Workarounds
There are no known workarounds to this issue.
Acknowledgements
The Cilium community has worked together with members of Isovalent and the Cisco Advanced Security Initiatives Group (ASIG) to prepare these mitigations. Special thanks to @kokelley-cisco for reporting this issue and @bimmlerd 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 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
Gateway API HTTPRoutes and GRPCRoutes do not follow the match precedence specified in the Gateway API specification. In particular, request headers are matched before request methods, when the specification describes that the request methods must be respected before headers are matched (HTTPRouteRule, GRPCRouteRule).
If users create Gateway API resources that use both request headers and request methods in order to route to different destinations, then traffic may be delivered to the incorrect backend. If the backend does not have Network Policy restricting acceptable traffic to receive, then requests may access information that you did not intend for them to access.
Patches
This issue was fixed in https://github.com/cilium/cilium/pull/34109.
This issue affects: - Cilium v1.15 between v1.15.0 and v1.15.7 inclusive - Cilium v1.16.0
This issue is fixed in: - Cilium v1.15.8 - Cilium v1.16.1
Workarounds
There is no workaround for this issue.
Acknowledgements
The Cilium community has worked together with members of Cure53 and Isovalent to prepare these mitigations. Special thanks to @sayboras for remediating this issue.
Further 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
When using Wireguard transparent encryption in a Cilium cluster, packets that originate from a terminating endpoint can leave the source node without encryption due to a race condition in how traffic is processed by Cilium.
Patches
This issue has been patched in https://github.com/cilium/cilium/pull/38592.
This issue affects:
- Cilium v1.15 between v1.15.0 and v1.15.15 inclusive - Cilium v1.16 between v1.16.0 and v1.16.8 inclusive - Cilium v1.17 between v1.17.0 and v1.17.2 inclusive
This issue is fixed in:
- Cilium v1.15.16 - Cilium v1.16.9 - Cilium v1.17.3
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 @gandro and @pippolo84 for reporting this issue and to @julianwiedmann 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 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.