In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in v1.10.11, v1.11.5, v1.12.3, 1.10.11, 1.11.5, and 1 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- 2 on Exploit-DB, 5 proofs of concept on GitHub
Summary
In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.
Timeline
- CVE published
- Public exploit on Exploit-DB
EDB-46053, EDB-46052
- Record last updated
- EPSS reached 10%
FIRST estimates at least a 10% chance of exploitation in the next 30 days
Affected versions
- Kubernetes Kubernetes
fixed in v1.10.11; fixed in v1.11.5; fixed in v1.12.3
- github.com/kubernetes/kubernetesGo
fixed in 1.10.11
- github.com/kubernetes/kubernetesGo
From 1.11.0 · fixed in 1.11.5
- github.com/kubernetes/kubernetesGo
From 1.12.0 · fixed in 1.12.3
- github.com/kubernetes/kubernetesGo
fixed in 1.10.11; From 1.11.0 · fixed in 1.11.5; From 1.12.0 · fixed in 1.12.3