Description

Tetragon is an eBPF-based security observability and runtime enforcement project. Versions before 1.7.0 can use a Helm default that exposes the privileged Tetragon gRPC API through an unauthenticated TCP listener on localhost:54321. An attacker who can run or compromise same-node hostNetwork pods can reach the listener and invoke privileged methods without authentication. These methods can add, delete, or reconfigure tracing policies and change debug settings, potentially resulting in privilege escalation or container escape. Version 1.7.0 changes the default endpoint to a Unix-domain socket. Deployments that do not expose an unauthenticated TCP listener are not affected.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-11-06T20:17:24.397Z",
  "pubdate": "2026-11-06T20:17:24.397Z",
  "executiveSummary": "Tetragon versions prior to 1.7.0 exhibit an insecure default configuration wherein the privileged gRPC API is exposed via an unauthenticated TCP listener on localhost:54321. This architectural oversight permits unauthorized interaction with the Tetragon runtime enforcement engine.\nThe vulnerability allows an attacker capable of executing code within a hostNetwork pod—or an attacker who has achieved compromise of such a pod—to interface directly with the sensitive API without any form of authentication or authorization checks.\nSuccessful exploitation facilitates unauthorized administrative control over the security observability suite, enabling attackers to modify, inject, or delete tracing policies, as well as manipulate debug configurations. Such actions provide a direct path for privilege escalation and potential container escape, as the attacker can effectively blind the security instrumentation or alter enforcement logic.\nThe risk is significant due to the fundamental nature of the Tetragon engine, which operates with deep system privileges. By manipulating the API, an adversary can bypass security controls and gain deeper access to the underlying host. Mitigation requires upgrading to version 1.7.0 or ensuring that no unauthenticated TCP listeners are active for the Tetragon service.",
  "technicalDetails": "The root cause of this vulnerability lies in the default Helm deployment configuration of Tetragon, which initializes the gRPC communication interface on a TCP socket bound to localhost:54321 without implementing access control lists (ACLs) or transport-level authentication. This effectively bypasses the Principle of Least Privilege by exposing high-privilege management functions to any local process capable of accessing the network stack of the host namespace.\nTetragon utilizes eBPF for runtime security enforcement, providing granular visibility into system calls and process executions. The gRPC API is designed for administrative orchestration, allowing users to modify policies and configurations dynamically. When this API is exposed over a TCP listener, the isolation typically provided by Kubernetes network policies or namespace boundaries is circumvented if the adversary occupies a pod configured with hostNetwork: true.\nThe exploitation flow proceeds as follows: 1. The attacker gains execution capabilities within a pod on the target node, specifically one sharing the host's network namespace. 2. The attacker identifies the open listener at 127.0.0.1:54321. 3. The attacker crafts gRPC requests directed at this endpoint. 4. Due to the lack of an authentication handshake, the Tetragon daemon processes these requests as legitimate administrative commands. 5. The attacker invokes methods such as 'AddTracingPolicy', 'DeleteTracingPolicy', or 'UpdateConfig'.\nPost-exploitation impact is severe. By injecting malicious tracing policies, an attacker can disable detection mechanisms for specific malicious payloads or commands. By reconfiguring debug settings, an attacker might extract sensitive kernel information or manipulate internal state variables. Because Tetragon operates with broad capabilities for system observability, the compromise of its control plane allows the adversary to achieve persistence, evade detection, or gain administrative shell access on the host, ultimately facilitating container breakout scenarios.\nThe vulnerability affects all Tetragon versions prior to 1.7.0. The remediation introduced in 1.7.0 shifts the communication channel from a TCP listener to a Unix-domain socket (UDS). UDS communication inherently restricts access to the local filesystem, which can be protected by standard Linux file permissions, thereby preventing remote or unauthorized local access to the gRPC control plane."
}