Hardening the Service Mesh: The Linkerd End User Threat Model and Recent Security Advisories

Linkerd (opens in a new tab), a Cloud Native Computing Foundation (CNCF) (opens in a new tab) graduated project, is a lightweight service mesh for Kubernetes that provides secure, observable, and reliable service-to-service communication. It deploys sidecar proxies alongside application containers, automatically encrypting traffic with mutual TLS (mTLS) and enforcing identity-based authorisation between microservices.

Linkerd can also operate in multi-cluster environments, enabling services across separate Kubernetes clusters to communicate securely and transparently. In this setup, Linkerd establishes a connection between clusters that’s reliable, encrypted, and authenticated on both sides with mTLS, enabling organisations to maintain zero-trust communication, observability, and reliability even in distributed, multi-cluster architectures.

As part of their commitment to cloud native security, the CNCF engaged ControlPlane to threat model Linkerd to identify key threats and risks affecting Linkerd across single-cluster and multi-cluster deployments. As a result of this effort, ControlPlane authored a comprehensive resource for platform operators and security teams: the Linkerd End User Threat Model and Hardening Guide.

In addition to the end-user threat model, ControlPlane reported two vulnerabilities identified in Linkerd through the project’s responsible disclosure process: GHSA-7cq8-3jwj-3pcf (opens in a new tab) and GHSA-x393-w43f-gq32 (opens in a new tab). These were two of the six vulnerabilities remediated and disclosed as part of the Buoyant Security Advisory 2026-01 (opens in a new tab).

The Linkerd End User Threat Model and Hardening Guide

The guide presents a threat-model driven approach to hardening the Linkerd service mesh. It serves as a practical, production-ready blueprint for securing Kubernetes deployments with the Linkerd service mesh, going beyond traditional penetration testing to address critical security considerations. Particular focus is given to cross-cluster communications and other high-risk areas relevant to highly regulated industries.

A threat modelling exercise identified a range of risks affecting Linkerd across both single-cluster and multi-cluster architectures. These risks span multiple domains, including:

• PKI architecture and cryptographic key management
• Role-Based Access Control (RBAC)
• Authorisation policy enforcement
• Cross-cluster boundary protection and network isolation
• Certificate lifecycle management
• How the underlying Kubernetes platform's security posture can impact the integrity and security guarantees of the mesh

A report containing risks, threats, and associated recommendations was delivered, along with comprehensive attack trees, to show the most important attack paths for Linkerd deployments.

Read the guide here (opens in a new tab).

Security Advisories

The two vulnerabilities reported by ControlPlane affect how Linkerd selects HTTP routes, with security consequences where routing decisions determine which authorisation policy or backend applies.

Authorisation bypass via case-sensitive HTTP hostname matching

GHSA-7cq8-3jwj-3pcf (opens in a new tab) is a high-severity authorisation bypass caused by case-sensitive hostname matching.

Affected Linkerd versions compared route hostnames case-sensitively, despite DNS names being case-insensitive as defined by RFC 4343 (opens in a new tab). A request with different capitalisation in the Host or :authority value could therefore fail to match the intended hostname-specific HTTPRoute and instead fall through to a broader route with a less restrictive policy.

From a threat-modelling perspective, the more general problem is disagreement between the proxy enforcing the security policy and the application behind it. If the proxy and backend interpret an attacker-controlled request differently, the proxy may authorise one logical request while the backend processes another.

HTTPRoute match precedence contradicts the Gateway API specification

GHSA-x393-w43f-gq32 (opens in a new tab) affects Linkerd’s implementation of Gateway API HTTPRoute match precedence.

The Gateway API gives method matches higher precedence than header and query-parameter matches after path specificity. Affected Linkerd versions evaluated these criteria in a different order. Where multiple routes matched the same request, Linkerd could therefore select a different route from the one required by the specification.

Next Steps

Read the Linkerd End User Threat Model and Hardening Guide for actionable hardening guidelines.

Contact the ControlPlane team (opens in a new tab) to see how we operationalise human-centric security for the world’s most sensitive organisations and data flows, to evaluate and secure your cloud native ecosystem.