Zilliz / Attu

Staff identified two vulnerabilities in Zilliz Attu 2.6.5 related to missing authentication and insecure input validation within the Playground feature. The missing authentication allowed unauthenticated users to proxy arbitrary HTTP and HTTPS requests through affected instances of Attu. Insecure input validation additionally permitted proxying requests to private IP addresses, which bypassed intended restrictions. When combined, these flaws enabled staff to obtain administrative access to the Kubernetes namespace in cloud deployments, such as EKS clusters.
The core issue stemmed from a flawed authorization check where validation for a `milvus-client-id` header was skipped if the header was missing or empty. This vulnerability extended to how the system handled URL validation, specifically a regular expression that failed to correctly identify absolute URLs, allowing malicious input containing schemes like HTTP to be processed by underlying libraries like Axios without proper security checks against private IP ranges. The successful exploitation demonstrated a chain reaction where network proxying led to obtaining AWS credentials, which subsequently granted access to the Kubernetes cluster context and privileges.

* Zilliz Attu version 2.6.5 had two identified vulnerabilities.
* Missing authentication allowed unauthenticated users to proxy arbitrary HTTP/HTTPS requests via the Playground feature.
* Insecure input validation allowed proxying to private IP addresses, bypassing intended restrictions.
* The vulnerabilities could be combined to obtain administrative access to the Kubernetes namespace in cloud deployments like EKS.
* The missing authentication occurred because authorization checks were skipped when the `milvus-client-id` header was absent or empty.
* The URL validation vulnerability involved a regular expression that failed to correctly classify URLs starting with uppercase schemes (e.g., HTTP://) as absolute addresses.
* This flaw allowed requests to bypass private IP address restrictions in the Playground service, allowing requests to be routed to internal network addresses.
* Exploitation involved chaining these flaws to gain an AWS metadata service token from an EC2 instance hosting Attu.
* The session token was used to retrieve IAM role credentials associated with the EKS node role.
* The credentials were used to authenticate directly to the Kubernetes API server as a system:node identity.
* An attacker could use a privileged service account token obtained from a running pod to gain access to the Milvus namespace.

The security failure exhibited a classic case of defense-in-depth breakdown, where multiple independent validation points failed to correlate their results effectively, creating an exploitable seam between application logic and underlying library behavior. The most significant pattern observed is the transformation of a specific input vulnerability (Insecure Input Validation) into an environment control vulnerability (Kubernetes namespace compromise). This suggests that weaknesses in low-level parsing routines—specifically the mismatch in URL classification between the Playground service and Axios—were leveraged to bypass high-level authorization controls designed to protect internal infrastructure. The exploitation path moves systematically from network egress (proxying) to information disclosure (metadata access), culminating in lateral movement within the cloud fabric via assumed-role chaining. This implies that even when strong perimeter security (like private IP blocking) is in place, inconsistencies in how different components handle input and URL resolution become critical vectors for privilege escalation. The vendor's response, pushing an upgrade to v3.0.0, signals a necessary shift away from patching specific logic errors toward fundamental architectural remediation of the entire system.
Bridge Questions:
How can systems be architected so that context derived from one component (like URL parsing) is inherently trusted by all subsequent security checks rather than relying on separate, potentially misaligned validation routines?
What mechanisms exist to prevent privilege escalation paths derived from node or service account identities when network exposure exists, even if underlying application logic is flawed?
If a vendor suggests a major rewrite for remediation, what guarantees are there that the rewritten architecture will inherently resolve these types of chained input/logic errors across future versions?