CVE-2024-5552 is a high severity (CVSS 7.5) regular expression denial of service in kubeflow, in the email validation of the centraldashboard-angular backend. No login is needed. The record names no fixed version, so check the kubeflow releases and limit who can reach the dashboard.
What's affected
The record says the flaw affects the latest version of kubeflow/kubeflow at the time, specifically the centraldashboard-angular backend component. It carries no version bounds, and its only reference is a public bounty report that I could not load. A fixed release is therefore not confirmed here.
The score is 7.5 with CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, which means network reachable, no authentication, no interaction, and an impact only on availability. Nothing in the record suggests data theft or code execution. The result is CPU exhaustion and service disruption.
If your deployment uses the central dashboard, the next step is finding which version you run.
How to check if you're exposed
Find the central dashboard image your cluster runs. The deployment is commonly named centraldashboard in the kubeflow namespace, though your distribution may differ:
kubectl get deploy -n kubeflow -o wide | grep -i dashboard
kubectl get deploy centraldashboard -n kubeflow -o jsonpath='{.spec.template.spec.containers[*].image}'
Compare the image tag with the project's release notes. If you cannot find a note on the email validation change, ask the project through its issue tracker.
Also check who can reach the dashboard. Many Kubeflow installs sit behind an identity aware proxy. If yours is exposed directly, the unauthenticated nature of the flaw matters far more.
What to do now
- Identify the central dashboard image tag in each cluster.
- Check the Kubeflow release notes and the project repository for a change to email validation in the backend.
- Make sure the dashboard sits behind your identity provider or a network control, not open to the internet.
- Set CPU limits and requests on the dashboard pods so a runaway request cannot starve the node.
- Alert on sustained high CPU in the dashboard deployment.
Why it matters
CWE-1333, inefficient regular expression complexity, is the root of a ReDoS. Some patterns take exponentially longer on certain inputs, because the matcher backtracks through many ways to fit a string. An email check looks harmless, yet a badly built expression can pin a CPU on one request.
Because this runs in a Node style backend that handles requests on a small number of threads, a single slow match can stall everyone. The remedy is standard: use a linear time matcher, cap input length before matching, and apply timeouts. The record is not in CISA KEV.
Quick check
Can this lead to data theft?
The vector scores confidentiality and integrity impact as none and availability as high. The record describes resource exhaustion and service disruption.
What is the quickest mitigation if no fix is available?
Keep the dashboard off the open internet, set CPU limits on its pods, and cap request size at the proxy in front of it.
Sources
Last reviewed: 19 October 2026.
