# Host network token sniffing

Shared host network lets pods reach or sniff other tenants' unauthenticated token and metadata endpoints

_Area: Cloud and container security. Seen in 2 disclosed reports; latest 2024-02-09. Updated 2026-10-23._

## How it works
A workload is assumed to be isolated from its neighbors, but it shares a network namespace with them. Token and credential endpoints (managed-identity, pod-identity, metadata) listen on localhost or link-local addresses and rely on "only this workload can reach me" as their only protection. When sandboxes or pods share the host network, that assumption is false: any co-located workload can reach or passively observe another tenant's credential exchange. The endpoint has no authentication of its own, so reachability equals access.

## Where it shows up
- Pods or sandboxes with `hostNetwork: true`, or platform sandboxes documented as sharing a host network.
- Credential/metadata endpoints on localhost or link-local addresses (e.g. `169.254.170.23`, `169.254.169.254`) served over plaintext HTTP.
- Token services on high, seemingly random localhost ports — a sign other tenants' services share the namespace [E1](https://bugbountylibrary.com/r/blog%3Aorca-security-resources-blog-autowarp-microsoft-azure-automation-service-vulnerability.md).
- DaemonSet agents that exchange JWTs for cloud credentials on a node-wide endpoint [E2](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-new-attack-vectors-emerge-via-recent-eks-access-entries-and-pod-identity-features.md).
- Newer API objects (EndpointSlice) that reimplement an older one (Endpoints) with weaker validation [E3](https://bugbountylibrary.com/r/h1%3A1145044.md).

## How to review
The invariant: a workload must not be able to reach or observe another workload's credential endpoint. Check that (a) tenant sandboxes/pods are network-isolated, not just process-isolated; (b) token endpoints require authentication or proof of workload identity, not mere reachability; (c) credential exchange uses TLS or a channel a neighbor cannot passively read; (d) `hostNetwork` pods are restricted or treated as node-trusted; (e) admission validation for EndpointSlice enforces the same port/host restrictions as Endpoints, rejecting loopback and arbitrary host ports [E3](https://bugbountylibrary.com/r/h1%3A1145044.md). Diff old and new API validation paths directly.

## Variants seen
- Shared-host sandbox with per-tenant token service on random localhost ports, reachable unauthenticated [E1](https://bugbountylibrary.com/r/blog%3Aorca-security-resources-blog-autowarp-microsoft-azure-automation-service-vulnerability.md).
- Host-network pod passively sniffing plaintext link-local credential traffic of co-located pods [E2](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-new-attack-vectors-emerge-via-recent-eks-access-entries-and-pod-identity-features.md).
- Lax EndpointSlice validation letting a service owner route traffic to arbitrary host-network ports [E3](https://bugbountylibrary.com/r/h1%3A1145044.md).

## Impact and severity
High to critical: cross-tenant managed-identity JWTs and IAM credentials led to cross-account cloud control [E1](https://bugbountylibrary.com/r/blog%3Aorca-security-resources-blog-autowarp-microsoft-azure-automation-service-vulnerability.md)[E2](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-new-attack-vectors-emerge-via-recent-eks-access-entries-and-pod-identity-features.md). Severity rises when endpoints are unauthenticated, plaintext, and reachable by any co-tenant; it drops when namespaces are isolated or endpoints require proof of identity.

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3Aorca-security-resources-blog-autowarp-microsoft-azure-automation-service-vulnerability.md
- E2: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-new-attack-vectors-emerge-via-recent-eks-access-entries-and-pod-identity-features.md
- E3: https://bugbountylibrary.com/r/h1%3A1145044.md
