Loading vulnerability…
Kubernetes API server and Service networking behavior in all Kubernetes versions allow traffic hijacking when an attacker can create or modify certain Service fields. Specifically, an actor able to create a Service and set .spec.externalIPs can cause kube-proxy to program node-level forwarding/NAT rules for arbitrary destination IP addresses, redirecting traffic for those IPs to attacker-controlled pods. The CVE record also states that an attacker able to patch the privileged status subresource of a LoadBalancer Service can set status.loadBalancer.ingress.ip to achieve a similar effect. In practice, this is an architectural trust-boundary issue in Kubernetes Service handling rather than a memory corruption bug: Kubernetes assumes cluster users are trusted, and in multi-tenant or otherwise untrusted environments this permits interception of traffic destined for external IPs.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
DenyServiceExternalIPs admission controller to block creation of Services using .spec.externalIPs. Audit and restrict RBAC so untrusted users cannot create arbitrary Service objects with external IPs and cannot patch the status subresource of LoadBalancer Services. Use policy enforcement such as Kyverno or equivalent admission controls/GitOps validation to deny these configurations. Prefer administrator-controlled exposure mechanisms such as type: LoadBalancer with constrained address assignment, MetalLB with approved IP ranges, or Gateway API resources protected by RBAC. The provided content also notes that clusters using Cilium with kube-proxy replacement are not affected.Patch, then assume compromise.
.spec.externalIPs, and tightly restrict any ability to patch LoadBalancer Service status. Kubernetes recommends use of the DenyServiceExternalIPs admission controller and migration to safer alternatives such as administrator-managed LoadBalancer Services, supported load balancer controllers such as MetalLB with constrained IP pools, or the Gateway API. Kubernetes 1.36 deprecates .spec.externalIPs, with planned disablement/removal in later releases, but this is a lifecycle change rather than a patch for existing behavior.No public exploits tracked yet. Mallory keeps watching.
No public exploit code observed for this vulnerability.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
13 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
An unfixed Kubernetes CVE mentioned as already correctly recorded as affecting all versions; the article provides no further technical detail here.
A Kubernetes security vulnerability tied to the Service .spec.externalIPs feature, which can enable security exploits in clusters where users are not fully trusted.
A Kubernetes vulnerability tied to the Service.spec.externalIPs field that can enable man-in-the-middle attacks on cluster traffic.
A Kubernetes vulnerability involving the Service spec.externalIPs field that can enable man-in-the-middle attacks on cluster traffic.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.