Database/Container, Kubernetes & orchestration

Cilium (SDS secret sync for L7 network policies): A tenant confined to their own namespace reaches across and rewrites

CVSS 7.3NCVD-2026-046-cilium-sds-secret-sync-for-l7-neContainer, Kubernetes & orchestrationGHSA-xqhm-7xhv-6ppjcurated

Impact

A tenant confined to their own namespace reaches across and rewrites another tenant's L7 policy enforcement. When SDS is enabled for L7 policies, synced Secrets and ConfigMaps land in a shared namespace where names can collide. An attacker who can create a Secret or ConfigMap in their own namespace plus a CiliumNetworkPolicy referencing it picks a name that collides with a victim's object, and their object overwrites the synchronised SDS object the victim's policy depends on — including policies using headerMatches.secret. The result is that the attacker chooses whether another tenant's traffic is permitted or denied: open a path that should be closed, or close one that should be open and take out that tenant's service. Namespace-scoped create rights on ordinary Kubernetes objects is exactly the permission set a GPU cloud hands every customer.

Who can reach it

Adjacent network / in-cluster. Requires namespace-scoped rights to create a Secret or ConfigMap and a referencing CiliumNetworkPolicy, plus knowledge of the victim object's name, on a cluster with SDS enabled for L7 policies.

What to do

Upgrade to Cilium 1.17.18, 1.18.12 or 1.19.6 and roll the agents. Workaround without upgrading: disable policy Secret synchronisation and manage referenced policy Secrets directly in the configured policy-secrets namespace (cilium-secrets by default), which removes the shared naming surface. Audit existing synced objects for unexpected owners.

References

https://github.com/cilium/cilium/security/advisories/GHSA-xqhm-7xhv-6ppj

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.