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