TL;DR: A Kubernetes Pod groups containers, including helpers called sidecars; Envoy often runs as a sidecar to handle app traffic. Envoy's shared-memory file lets its processes access the same memory. X41 showed that an attacker with read and write access to that file can make Envoy overwrite its own memory.
Containers in a Pod share some resources. Our check is whether the application can reach the memory Envoy uses to coordinate restarts.
Attack of the week: corrupting Envoy through a shared file
Michael Rodler at X41, “A Container in a Pod Is Not a Security Boundary - Lateral Movement into Envoy Sidecars” [2026-10-09].
X41 started with root access in a Kubernetes container. Root is the administrator account. They found Envoy's shared file.
Envoy's hot-restart feature lets a replacement process take over while the old process finishes its connections. The 2 Envoy processes coordinate through a file under /dev/shm, a directory for files backed by memory.
In X41's test, the file contained locks, which help processes take turns updating shared data. Their bookkeeping included pointers: values holding memory addresses inside the running Envoy process.
Routine logging uses these locks too. The attack can run while Envoy handles normal traffic.
The attacker reads those addresses, then changes the pointers while Envoy holds a lock. When Envoy releases the lock, it writes to addresses the attacker chose.
A shared file reaches Envoy's live lock state. File permissions decide whether the neighbor can use that path.
Rodler's proof of concept demonstrates a “pointer leak and the arbitrary write” on Envoy 1.38.3 and 1.39.1. Full code execution remains unproven. Credential access would require further exploitation and would depend on the deployment.
Envoy's source creates its shared-memory object with owner-only read/write permissions. On Linux, its name starts with /dev/shm/envoy_shared_memory_.
Kubernetes documents shared inter-process communication within a Pod. In the standard Linux/containerd setup, containerd, the software that starts the containers, gives them access to the Pod's same /dev/shm directory. An explicit mount can replace that default.
File permissions still apply. A neighboring process can use the file if its effective numeric user ID matches Envoy's; root can also reach it with sufficient privileges to override permissions. Some deployments remap those IDs or apply extra restrictions, so check the running containers.
X41 says Envoy's maintainers closed the report because the file is restricted to Envoy's user.
Ship this week. Pick a deployed Pod that runs Envoy beside an application. Inspect its process arguments, mounts and permissions without modifying the live file. Record which containers can read and write /dev/shm/envoy_shared_memory_*, then choose the mitigation below.
Start with kubectl get pod -n NAMESPACE POD -o json. The running Pod includes automatically added sidecars, so inspect every container, including those used during startup or added later for debugging.
Container security settings override matching Pod settings. Check the runtime's default when /dev/shm has no explicit mount.
Configuration can be incomplete. Confirm user IDs and Envoy's final arguments in the running processes: the image or startup command can supply values the Pod JSON doesn't show.
Defender's corner: separate the shared memory
Give each container its own /dev/shm directory. Kubernetes can back each directory with a separate emptyDir volume stored in memory. Use distinct volume names:
# Pod template fragment; merge into the workload or injector configuration.
spec:
containers:
- name: application
volumeMounts:
- name: application-shm
mountPath: /dev/shm
- name: envoy
volumeMounts:
- name: envoy-shm
mountPath: /dev/shm
volumes:
- name: application-shm
emptyDir:
medium: Memory
- name: envoy-shm
emptyDir:
medium: Memory
Each container mounts a different memory-backed volume at /dev/shm. Verify the new Pods after rollout.
Update the workload's Pod template or sidecar injection configuration, then roll out replacement Pods.
Attach mounts to the container definitions that run Envoy and the app. Kubernetes native sidecars keep running after startup and are defined under initContainers with restartPolicy: Always.
Set each volume's sizeLimit for its workload and account for the files in container memory limits. Check whether any processes intentionally need shared memory.
Alternatively, Envoy supports --disable-hot-restart. Check how Envoy hands over traffic and finishes existing connections before changing it. The flag changes startup behavior; verify the running processes after rollout.
Do this week: test the change in staging and check that traffic and restarts work. With separate mounts, confirm the application can't read or write Envoy's live shared-memory file.
With hot restart disabled, confirm the replacement processes have it disabled and no running Envoy process still maps the hot-restart file. A leftover file alone doesn't establish exposure. A Pod still shares other resources.
Until next Tuesday,
R.K.
Sponsored content may appear below. Not part of Weekly Recon editorial.