Cilium

### Impact Users with the ability to create CiliumLocalRedirectPolicies can specify arbitrary ClusterIPs via addressMatcher, which enables hijacking traffic to Services in any namespace, bypassing the namespace-scoping guarantees enforced by serviceMatcher. In addition, deleting such a policy can corrupt Cilium's internal service state, causing service translation to stop working entirely for the affected Service.

### Impact `CiliumNetworkPolicy`s 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.

### Impact When using [Wireguard transparent encryption](https://docs.cilium.io/en/stable/security/network/encryption-wireguard/#encryption-wg) 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.

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

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

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

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

### Impact Gateway API HTTPRoutes and GRPCRoutes do not follow the match precedence specified in the Gateway API specification.

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

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

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

### Impact For Cilium users who have enabled [an external kvstore](https://docs.cilium.io/en/stable/installation/k8s-install-external-etcd/#when-do-i-need-to-use-a-kvstore) and [Wireguard transparent encryption](https://docs.cilium.io/en/stable/security/network/encryption-wireguard/#encryption-wg), 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.

### Impact For Cilium users who are using CRDs to store Cilium state (the default configuration) and [Wireguard transparent encryption](https://docs.cilium.io/en/stable/security/network/encryption-wireguard/#encryption-wg), 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.

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

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

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

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

## Impact 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. Only IPv6 traffic is impacted by this vulnerability.

### Impact 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. ### Patches The issue has been fixed and is available on versions >=1.11.15, >=1.12.8, >=1.13.1.

### Impact If a user has Network Policies with namespace selectors selecting labels of namespaces, or (clusterwide) Cilium Network Policies matching on namespace labels, then it is possible for an attacker with Kubernetes pod deploy rights (either directly or indirectly via higher-level APIs such as Deployment, Daemonset etc) to craft additional pod labels such that the pod is selected by another policy that exists rather than the expected policy.