Zilliz Attu CVE-2026-105049

Requires a reachable Zilliz Attu instance running a version before 3.0.0 with the Playground feature present; the feature proxies arbitrary HTTP and HTTPS requests without any authentication, so no credentials, tokens, or user interaction are needed against a default install. The primary limiting factor is network exposure: the attacker must be able to reach the Attu management interface, so instances kept on an internal or firewalled management network (as recommended for admin GUIs) are not exposed to untrusted attackers. Impact is bounded to request proxying/SSRF (I:L, no direct read of Attu data), not code execution or data exfiltration from Attu itself.

This is a moderate-severity missing-authentication flaw (CWE-306) rated CVSS 5.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N). The CVSS signals are internally consistent and credible: network vector, low complexity, and no privileges or user interaction mean any party able to reach the Attu instance can abuse the Playground proxy, and the scope change (S:C) correctly reflects that the impact lands on systems other than Attu itself - the server is turned into an open forward proxy for arbitrary HTTP/HTTPS requests. Impact is constrained to I:L with C:N and A:N, so this is request-forgery/open-proxy abuse rather than direct data theft or service disruption, which is why the base score stays mid-range despite being trivially triggerable. No EPSS score, KEV listing, or explicit POC flag was supplied in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the referenced Bishop Fox blog and GitHub issue #1028 indicate the issue is publicly documented and researched, but that is distinct from confirmed exploit code or in-the-wild use. Net assessment: a real but not top-tier priority - genuinely easy to trigger and useful as an SSRF/open-proxy pivot, yet limited in direct impact and dependent on the Attu management UI being network-exposed, which should not be the case in a well-segmented deployment.

An attacker who can reach an exposed Attu instance (before 3.0.0) sends a request to the unauthenticated Playground feature, instructing it to proxy an arbitrary HTTP/HTTPS URL. The attacker uses the Attu server as an anonymizing open proxy or to perform server-side request forgery against internal or third-party systems that trust the server's network position. No public exploit code is identified in the provided data, though the technique is documented in the referenced Bishop Fox write-up.