A Container in a Pod Is Not a Security Boundary - Lateral Movement into Envoy Sidecars#

Michael Rodler (X-41 DSEC)

• Why: In an Envoy-based service mesh, the sidecar is your security policy — mTLS termination, authz, rate limits. This shows the pod boundary around that control plane is softer than assumed, which matters to anyone running Istio/Envoy in multi-tenant clusters.
• What: From root in one container of a Pod, the authors reach Envoy's hot-restart shared-memory file and turn it into an ASLR leak and an arbitrary-write primitive — effectively compromising the mesh proxy from a sibling container. Upstream called it "not a security issue"; the authors argue that's only half true on Kubernetes, where containers in a Pod share more than the kernel. A 5-minute lightning talk; the research was previously published as an X-41 blog post (so full technical depth is available outside the talk slot).
• How: Envoy's hot-restart feature keeps a shared-memory region (normally under /dev/shm) for parent/child handoff and stats. Containers in the same Pod can reach that file; corrupting it yields memory-disclosure and memory-corruption primitives inside Envoy itself.
• Where applicable: Kubernetes deployments running Envoy sidecars. Requires prior code execution/root in a container in the same Pod — it is lateral movement and boundary erosion, not a remote exploit. General technique, not tied to a specific vendor or distro; the mitigation question (isolating sidecars, restricting shm access) applies to any mesh sidecar sharing pod-level resources.