GHSA-2mvq-xp48-4c77

What it actually does

This advisory describes a denial-of-service vulnerability in Cilium related to subtext handling. A flaw in input or protocol processing can cause affected Cilium components to become unavailable, degrade service, or interrupt network/security policy enforcement. The issue affects the Go module github.com/cilium/cilium and is fixed in version 1.13.13.

Why it matters to the business

Successful exploitation can disrupt networking or security functions in environments that rely on Cilium, potentially causing application outages, degraded cluster connectivity, delayed deployments, or reduced confidence in network policy enforcement. The advisory is old, not listed in CISA KEV, and has no indicated exploit maturity, so urgency is mainly driven by whether affected Cilium versions are still deployed in production or exposed to untrusted traffic.

How an attack unfolds

An attacker would need a way to reach the vulnerable Cilium-exposed code path or submit crafted input that triggers the vulnerable subtext handling behavior. By sending malformed or specially constructed traffic or requests, the attacker attempts to force the affected component into excessive resource consumption, crash, or an unavailable state. If successful, the result is service degradation or loss of availability rather than direct code execution or data theft. Repeated attempts could be used to sustain disruption until the component is restarted, traffic is filtered, or the software is upgraded.

How to fix it

Upgrade github.com/cilium/cilium to version 1.13.13 or later. For Cilium deployments, update the Cilium agent/operator images and Helm charts/manifests as appropriate, then roll the affected components in a controlled manner. If immediate upgrade is not possible, restrict access to any reachable Cilium APIs or interfaces, reduce exposure to untrusted traffic, apply network filtering where feasible, and monitor for crashes, restart loops, or unusual resource spikes. Because this is an availability issue, ensure rollback and maintenance windows account for possible transient network disruption during remediation.

How to confirm the fix worked

Confirm that all deployed Cilium components report version 1.13.13 or later. Validate container images, Helm chart values, Kubernetes manifests, and Go module dependency locks to ensure no older github.com/cilium/cilium versions remain. After upgrade, run representative connectivity and network policy tests to confirm normal operation. Review Cilium pod status and restart counts to ensure agents/operators are stable after remediation. Where feasible, reproduce only in a safe test environment using non-production systems to verify that the denial-of-service condition no longer occurs.

Typical attack path

1. Identify an environment running an affected version of github.com/cilium/cilium prior to 1.13.13.
2. Determine whether the vulnerable Cilium component or code path is reachable through cluster networking, APIs, or traffic handled by Cilium.
3. Send crafted input or traffic intended to trigger the denial-of-service condition in subtext handling.
4. Observe whether Cilium components crash, hang, restart repeatedly, or degrade network behavior.
5. Repeat the triggering traffic to maintain service disruption or interfere with cluster networking and policy enforcement.

How to detect it

To assess possible prior exploitation, review Kubernetes events, Cilium pod logs, container runtime logs, and node system logs for unexplained Cilium crashes, restart loops, health-check failures, or sudden network policy/connectivity interruptions. Focus on time windows with spikes in Cilium agent/operator restarts, abnormal CPU or memory consumption, repeated malformed traffic, or bursts of rejected/failed requests immediately preceding component failures. Correlate Cilium logs with Kubernetes pod restart counts, node dmesg or OOM-killer events, load balancer/API gateway logs, and network telemetry. Because the advisory does not provide a public exploit string or payload signature, detection should be behavior-based rather than relying on a single definitive IOC.

• cilium-agent
• cilium-operator
• CrashLoopBackOff
• OOMKilled
• Back-off restarting failed container
• Readiness probe failed
• Liveness probe failed
• level=fatal
• panic:
• fatal error:
• context deadline exceeded
• daemon not responding
• Cilium API client timeout

What your security team should do

• Inventory all Cilium deployments and Go dependencies to identify versions of github.com/cilium/cilium older than 1.13.13.
• Prioritize upgrading production and externally exposed or multi-tenant cluster environments to Cilium 1.13.13 or later.
• Monitor Cilium agents, operators, and related pods for crash loops, abnormal restarts, high CPU/memory use, or sudden connectivity failures.
• Restrict access to Cilium management interfaces and cluster control-plane paths to trusted networks and identities only.
• Ensure incident response runbooks include steps for Cilium-related network disruption, including collecting pod logs before restart where possible.
• Add dependency and container image checks to CI/CD or vulnerability management workflows so outdated Cilium versions are flagged automatically.