CVE-2026-49445

What it actually does

When Cilium L7 functionality is enabled, affected Cilium versions create an Envoy admin Unix socket that is accessible too broadly on cluster nodes. A local attacker with access to a node or to a container/pod that can reach the socket can call Envoy administrative endpoints without authentication. Those endpoints can expose Envoy configuration and TLS material, alter or disrupt proxy behavior, drain listeners, or terminate Envoy, affecting confidentiality and availability of Cilium-managed traffic.

Why it matters to the business

An attacker who gains local execution on a Kubernetes node, or reaches the exposed socket through an overly permissive workload mount, could steal sensitive TLS secrets or disrupt application traffic routed through Cilium L7 policy enforcement. This may cause service outages, loss of encrypted credential material, policy bypass concerns, incident response costs, and potential regulatory exposure if intercepted secrets protect sensitive workloads. Although EPSS is currently low and there is no known KEV listing, the high severity and direct impact on cluster traffic make timely remediation important for any Cilium deployment using L7 features.

How an attack unfolds

Exploitation requires local access to a node or equivalent access to the Envoy admin socket from a container context. The attacker first obtains the ability to execute commands on a cluster node, compromises a privileged workload, abuses a hostPath mount, or otherwise reaches the Cilium Envoy runtime directory. They locate the world-accessible admin.sock file and send HTTP requests over the Unix domain socket to Envoy admin endpoints. From there, they can retrieve configuration dumps, inspect clusters/listeners, access certificate or TLS-related information, trigger drains, or call administrative shutdown endpoints such as quitquitquit. Successful exploitation can expose secrets and interrupt L7 proxying for workloads dependent on Cilium/Envoy.

How to fix it

Upgrade Cilium to a fixed version: 1.17.14 or later for the 1.17 branch, 1.18.8 or later for the 1.18 branch, or 1.19.2 or later for the 1.19 branch. Prioritize clusters where Cilium L7 policy, ingress, gateway, service mesh, or other Envoy-backed functionality is enabled. If immediate upgrade is not possible, reduce exposure by disabling unnecessary Cilium L7 functionality, restricting node shell access, removing unnecessary hostPath mounts to Cilium/Envoy runtime directories, preventing untrusted workloads from running as privileged or with host filesystem access, and enforcing least privilege for Kubernetes exec, debug, and node access. Do not rely solely on network controls, because the vulnerable interface is local to the node.

How to confirm the fix worked

Confirm the running Cilium version on every cluster and ensure it is at or above 1.17.14, 1.18.8, or 1.19.2 depending on the deployed branch. On nodes using Cilium L7 functionality, inspect the Envoy admin socket location and verify it is not world-accessible. Validate that unprivileged users or ordinary workloads cannot connect to admin.sock. Review workload specifications for hostPath mounts that expose Cilium or Envoy runtime directories. After upgrade, test L7 policy functionality and verify Envoy remains operational without exposing the admin socket to unauthorized local principals.

Typical attack path

1. Gain local command execution on a Kubernetes node or in a container with access to the host path containing the Cilium Envoy socket.
2. Locate the Envoy admin Unix socket, commonly named admin.sock, under the Cilium/Envoy runtime socket directory.
3. Confirm that the socket permissions allow unauthorized local access.
4. Use a tool such as curl, socat, or nc with Unix-socket support to issue HTTP requests to Envoy admin endpoints.
5. Query sensitive endpoints such as /config_dump, /certs, /clusters, /listeners, or /server_info to collect configuration and TLS-related data.
6. Optionally call disruptive endpoints such as /drain_listeners or /quitquitquit to degrade or terminate Envoy and disrupt cluster traffic.

How to detect it

Investigate host audit logs, Linux process execution telemetry, EDR events, shell history, Kubernetes audit logs, Cilium logs, and Envoy logs. Look for commands that connect to the Envoy admin Unix socket using curl, socat, nc, Python, or custom binaries. Review Kubernetes audit events for pod exec, debug container creation, privileged pod launches, and hostPath mounts exposing Cilium or Envoy runtime directories. On nodes, inspect auditd or eBPF telemetry for connect, open, or write activity against admin.sock by unexpected users or processes. In Envoy/Cilium logs, look for unexpected admin-triggered drains, shutdowns, listener changes, or repeated Envoy restarts. Because admin access may occur over a Unix socket, network logs may not show the activity; host-level telemetry is the most useful source. If /certs or /config_dump access is suspected, assume exposed TLS material may require rotation.

• /var/run/cilium/envoy/sockets/admin.sock
• admin.sock
• curl --unix-socket
• socat - UNIX-CONNECT
• nc -U
• GET /certs
• GET /config_dump
• GET /clusters
• GET /listeners
• GET /server_info
• POST /quitquitquit
• GET /quitquitquit
• POST /drain_listeners
• GET /drain_listeners
• cilium-envoy
• envoy

What your security team should do

• Inventory all clusters running Cilium and identify those with L7 features or Envoy-backed components enabled.
• Upgrade affected Cilium installations to 1.17.14, 1.18.8, 1.19.2, or a newer supported release as soon as operationally feasible.
• Treat clusters with privileged workloads, broad hostPath usage, or shared node access as higher risk and remediate them first.
• Search for evidence of local access to Envoy admin endpoints, especially requests for /certs, /config_dump, /clusters, /listeners, /drain_listeners, and /quitquitquit.
• Audit Kubernetes RBAC for permissions that allow exec, debug containers, privileged pod creation, or hostPath mounts on nodes running Cilium.
• Add runtime or host-based detections for curl, socat, nc, or similar tools connecting to the Cilium Envoy admin socket.
• Review Cilium and Envoy logs for unexpected restarts, drains, listener changes, or proxy interruptions around suspicious local activity.
• If exposure is confirmed and sensitive endpoints may have been accessed, rotate TLS certificates and other secrets that may have been visible through Envoy configuration.