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

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

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

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.

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

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

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.

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.

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.

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

Due to ReferenceGrant changes not being immediately propagated in Cilium's GatewayAPI controller, Gateway resources are able to access secrets in other namespaces after the associated ReferenceGrant has been revoked. This can lead to Gateways continuing to establish sessions using secrets that they should no longer have access to.

Patches

This issue was resolved in https://github.com/cilium/cilium/pull/34032.

This issue affects:

- Cilium v1.15 between v1.15.0 and v1.15.7 inclusive - Cilium v1.16.0

This issue has been patched in:

- Cilium v1.15.8 - Cilium v1.16.1

Workarounds

Any modification of a related Gateway/HTTPRoute/GRPCRoute/TCPRoute CRD (for example, adding any label to any of these resources) will trigger a reconciliation of ReferenceGrants on an affected cluster.

Acknowledgements

The Cilium community has worked together with members of Cure53 and Isovalent to prepare these mitigations. Special thanks to @sayboras for 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

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

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

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.

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

For users with the following configuration:

An allow policy that selects a Layer 3 identity and a port range AND A Layer 7 allow policy that selects a specific port within the first policy's range

then Layer 7 enforcement would not occur for the traffic selected by the Layer 7 policy.

This issue only affects users who use Cilium's port range functionality, which was introduced in Cilium v1.16.

For reference, an example of a pair of policies that would trigger this issue is:

apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "layer-3-and-4" spec: endpointSelector: matchLabels: app: service ingress: - fromCIDR: - 192.168.60.0/24 toPorts: - ports: - port: "80" endPort: 444 protocol: TCP and apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "layer-4-and-7" spec: endpointSelector: matchLabels: app: service ingress: toPorts: - ports: - port: "80" protocol: TCP rules: http: - method: "GET" path: "/public"

In the above example, requests would be permitted to all HTTP paths on matching endpoints, rather than just GET requests to the /public path as intended by the layer-4-and-7 policy. In patched versions of Cilium, the layer-4-and-7 rule would take precedence over the layer-3-and-4 rule.

Patches

This issue is patched in https://github.com/cilium/cilium/pull/35150.

This issue affects Cilium v1.16 between v1.16.0 and v1.16.3 inclusive.

This issue is patched in Cilium v1.16.4.

Workarounds

Users with network policies that match the pattern described above can work around the issue by rewriting any policies that use port ranges to individually specify the ports permitted for traffic.

Acknowledgements The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @jrajahalme for 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

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.

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

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.

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.