Every pod in a modern Kubernetes cluster running a service mesh carries a hidden passenger. Alongside your application container sits a sidecar proxy — usually Envoy, sometimes linkerd2-proxy or a Consul equivalent — silently intercepting every packet of traffic in and out. It terminates mTLS, enforces authorization policy, collects telemetry, and retries failed calls, all before your code ever sees a request. That convenience comes at a cost: you have quietly doubled the number of network-facing processes in your cluster, and each one is a full-blown, internet-grade proxy with its own parser, its own CVEs, and its own attack surface. In October 2023, a single Envoy vulnerability turned every Istio gateway on the planet into a potential outage. In 2024, two more let attackers slip past authorization checks and crash the proxy outright. Sidecars were supposed to make microservices safer. Increasingly, they're the thing you have to secure separately.
What Actually Is a Sidecar Proxy, and Why Does It Expand Your Attack Surface?
A sidecar proxy is a second container injected into every application pod that intercepts 100% of inbound and outbound traffic via iptables or eBPF redirection, meaning every network path in your mesh now runs through code you didn't write and often don't patch on the same schedule as your app. In Istio, that's Envoy; in Linkerd, a Rust-based micro-proxy; in Consul Connect, an Envoy sidecar managed by HashiCorp's control plane. The architectural promise is separation of concerns — your app team ships business logic, the mesh handles mTLS, retries, and observability. The security cost is that a cluster of 200 application pods running a mesh isn't running 200 attack surfaces, it's running closer to 400: two container images, two sets of dependencies, two things that need CVE monitoring, and two things an attacker can pivot through. Sidecars also run with elevated network privileges (typically NET_ADMIN/NET_RAW for traffic interception) that the application container itself never needed, which is exactly the kind of quiet privilege escalation that container security reviews routinely miss because they scan the app image and wave the "infrastructure" sidecar through.
Did a Single Envoy Bug Really Threaten Every Mesh Gateway at Once?
Yes — on October 10, 2023, the disclosure of CVE-2023-44487, the HTTP/2 "Rapid Reset" attack, meant that any Envoy proxy handling HTTP/2 traffic, including every Istio sidecar and ingress gateway, could be knocked over by a client that opens a stream and immediately resets it thousands of times per connection. Because Envoy is the data-plane sidecar for Istio and the underlying proxy for several other mesh implementations, this wasn't an isolated app bug — it was a single vulnerability that simultaneously affected every mesh deployment built on that engine, disclosed jointly with Google, AWS, and Cloudflare after it was used in some of the largest DDoS attacks ever recorded. Teams running internet-facing gateways had to patch Envoy versions across every mesh-enabled namespace within days, and the incident became the clearest public proof that a service mesh doesn't distribute your attack surface — it concentrates it into one shared component running in thousands of pods.
Can a Misconfigured Sidecar Actually Bypass Your Authorization Policy?
Yes — CVE-2024-45806, disclosed in September 2024 and fixed in Istio 1.31.2, 1.30.6, 1.29.9, and 1.28.7, was an authorization bypass through a user-controlled key that let a crafted request evade the AuthorizationPolicy the mesh operator believed was enforced at the sidecar. That's the nightmare scenario for zero-trust architectures built on mesh policy: the whole pitch of a service mesh is that you can enforce "deny by default, allow by policy" at the network layer without touching application code, and a bug like this means the policy your compliance team signed off on simply doesn't apply to certain requests. The same year, CVE-2023-35944 showed a related class of problem — Envoy's inconsistent handling of mixed-case HTTP schemes (htTp vs http) allowed request smuggling that could bypass scheme-based access checks, patched in Envoy 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12. And CVE-2024-45810 showed the flip side: a crash in Envoy's HTTP async client (CVSS 6.5) affecting Istio 1.22.0–1.22.4 and 1.23.0–1.23.1, letting attackers take the sidecar itself down. Between authorization bypass, request smuggling, and remote crash, 2023–2024 alone produced all three major failure modes a sidecar can hand an attacker.
Is the Sidecar Model Actually Becoming Too Costly to Run?
Yes, according to the organizations running it — CNCF's own annual survey found service mesh adoption fell from roughly 50% in 2023 to 42% in 2024, and CNCF attributed the drop specifically to operational overhead, not lack of need for the security and traffic-management capabilities meshes provide. That overhead is concrete: every pod effectively runs two containers, sidecar images need independent patch cycles, proxy resource requests add real CPU and memory tax at cluster scale, and until recently, sidecar containers weren't even native application constructs — they were injected via mutating admission webhooks, meaning your security posture depended on a webhook configuration being correct on every single pod creation. Kubernetes didn't ship a native sidecar container primitive until v1.28 in August 2023 (alpha) and v1.29 (beta, enabled by default), with the feature only reaching stable in v1.33 in April 2025. For roughly a decade of mesh adoption before that, "sidecar" wasn't a first-class Kubernetes concept at all — it was a convention enforced by injector webhooks, init-container ordering hacks, and hope.
Do Sidecar-less Meshes Actually Remove the Attack Surface, or Just Relocate It?
They relocate it — eBPF-based approaches like Cilium's sidecar-free mesh and Istio's Ambient Mesh (stable since Istio 1.24 in late 2024) move traffic interception out of per-pod user-space proxies and into a shared per-node component (typically called ztunnel in Ambient), which cuts the number of proxy processes dramatically but concentrates trust in a smaller number of node-level components with kernel-level privileges. That's a legitimate risk trade: fewer processes to patch and less per-pod overhead, but a compromise of the shared node proxy or eBPF program now has blast radius across every workload on that node instead of just one pod. It's not a free security upgrade, it's a different threat model — and teams migrating from sidecar to sidecar-less mesh architectures need to re-run their threat modeling, not just declare victory because the pod count went down.
How Safeguard Helps
Sidecar proxies fail the same test as any other third-party component in your software supply chain: most organizations can tell you what's in their application containers but not what's actually running in their mesh's data plane, at what version, injected by whom, and patched on what cadence. Safeguard closes that gap by treating sidecar images — Envoy, linkerd2-proxy, Consul Connect's proxy, and Ambient's ztunnel — as first-class artifacts in your software supply chain inventory, not invisible infrastructure. Concretely, Safeguard:
- Generates and verifies SBOMs for sidecar images, so when a CVE like CVE-2023-44487 or CVE-2024-45806 drops, you can answer "which of our 400+ pods are running a vulnerable Envoy build" in minutes instead of days of grep-ing Helm values across every namespace.
- Flags privilege drift on injected containers, catching sidecars that hold
NET_ADMIN,NET_RAW, or elevated service-account permissions beyond what the mesh actually requires, closing the "quiet privilege escalation" gap that app-only container scans miss. - Tracks provenance of the mesh control plane and injector webhooks themselves, verifying that the components deciding which image gets injected into every pod in your cluster haven't been tampered with — because a compromised injector is a compromise of every workload it touches.
- Continuously monitors CVE feeds against your actual deployed sidecar versions, correlating new Envoy/Istio/Linkerd advisories against your live cluster state rather than a point-in-time scan, so gaps between disclosure and patch don't sit open unnoticed.
- Supports the sidecar-to-sidecar-less migration path, giving teams evaluating Ambient Mesh or eBPF-based meshes the same supply chain visibility into
ztunneland node-level proxy components so the trust concentration described above is measured, not assumed.
Service meshes aren't going away, and neither is the sidecar pattern for teams not ready to re-architect onto Ambient or Cilium. But "the mesh handles security" was never fully true — the mesh's security depends on a proxy binary with its own CVE history sitting in every pod, and that binary belongs in your supply chain security program, not outside it.