GPU VulnDB

Database/Container, Kubernetes & orchestration

Tetragon: unauthenticated gRPC API on localhost lets a same-node pod rewrite tracing policy

CVSS 8.8CVE-2026-65960Container, Kubernetes & orchestrationcurated

Impact

Tetragon's privileged gRPC API is exposed by a Helm default as an unauthenticated TCP listener on localhost:54321. Anything that shares the node's network namespace - any hostNetwork pod, or a compromised one - can call privileged methods with no credentials and add, delete or reconfigure tracing policies and debug settings. On a GPU fleet that means the runtime-enforcement layer itself can be silently disarmed: an attacker turns off the policies that would have flagged a container escape, then escapes. Because Tetragon runs as a privileged DaemonSet, reconfiguring it is a direct path to privilege escalation on the node, and the blinding is fleet-wide wherever the same Helm values were applied. Clusters that already moved the endpoint off TCP are unaffected.

Who can reach it

Local to the node, no authentication: any workload that can run or take over a hostNetwork pod on the same node reaches the loopback listener. Not reachable from off-node if the listener stays bound to localhost.

What to do

Upgrade to Tetragon 1.7.0, which defaults the gRPC endpoint to a Unix-domain socket, and roll the DaemonSet so every node picks it up - a Tetragon pod restart per node, no host reboot and no GPU workload drain. If you cannot upgrade now, set the server address to a Unix socket in your Helm values and restrict hostNetwork pod admission; the advisory states deployments that do not expose an unauthenticated TCP listener are not affected.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.