The hook
Kubernetes Service ExternalIPs can be legitimate, but the field assumes strong trust around who can create or patch Services. In multi-tenant or delegated clusters, a Service author choosing arbitrary external IPs can create traffic-interception risk if RBAC and admission policy do not restrict that path.
How it works
The repo signal is a Kubernetes Service manifest that explicitly declares `spec.externalIPs`. That source/config evidence is useful because Kubernetes has documented CVE-2020-8554 and has moved toward deprecating Service ExternalIPs, but the manifest alone does not prove the Service is deployed, reachable, or exploitable in a live cluster.
The blast radius
If an untrusted principal can create or update Services and control backing pods or endpoints, ExternalIPs can affect where traffic for selected IPs is routed inside the cluster. The real impact depends on live RBAC, admission controls, tenancy model, network path, encryption, and whether the listed IPs are intentional.
// what fixvibe checks
What FixVibe checks
FixVibe repo scans look for high-confidence security patterns and dependency risk in source context. Reports identify the affected area and recommended fix. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
Ironclad defenses
Remove ExternalIPs where possible and use cloud/provider LoadBalancer, Ingress, Gateway, or controlled service routing instead. If ExternalIPs must remain, restrict Service create/update permissions to trusted administrators, enforce a narrow allowlist or deny policy with admission controls, audit live Services, and monitor future Service changes.