EUVD-2026-51185
GHSA-h9qj-gx4p-69cp
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Network-reachable REST endpoint with no required auth/UI (AV:N/AC:L/PR:N/UI:N); core impact is arbitrary controlled file write (I:H), with only escalation-dependent confidentiality/availability effects (C:L/A:L).
Primary rating from Vendor (CNA).
CVSS VectorVendor
Lifecycle Timeline
5Description PRE-NVD
Articles & Coverage 1
AnalysisAI
Arbitrary file write in Apache Kyuubi (1.7.0 through 1.11.1) lets a remote attacker abuse the REST batch multipart upload endpoint, which trusts the client-supplied filename, to plant controlled content anywhere the server process can write. Because the server never sanitizes path traversal sequences (../) in the multipart filename, an attacker can escape the intended upload directory and overwrite or create files subject only to filesystem permissions. EPSS is low (0.28%, 21st percentile) and there is no public exploit identified at time of analysis, but the primitive is powerful and the fix is available in 1.12.0.
Technical ContextAI
Apache Kyuubi is a distributed multi-tenant gateway that exposes Spark/SQL engines over Thrift and a REST API; the affected code path is the REST batch job submission feature, which accepts multipart file uploads (e.g. application JARs and resources) to stage batch workloads. The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory / Path Traversal): when Kyuubi creates the temporary uploaded resource it uses the attacker-controlled 'filename' field from the multipart part directly to construct the destination path rather than deriving a safe, server-generated name. Multipart form-data filenames are entirely client-controlled, so embedding '../' segments causes the write to resolve outside the configured upload staging directory.
RemediationAI
Vendor-released patch: upgrade to Apache Kyuubi 1.12.0, which fixes the filename handling - this is the primary and recommended remediation per the Apache advisory (https://lists.apache.org/thread/b0qx2v8k5v4rrqsh53pb146t7so0lmrk). If you cannot upgrade immediately, restrict network exposure of the REST batch endpoint by placing it behind authentication and a reverse proxy or firewall so only trusted tenants/hosts can reach the batch upload path (trade-off: breaks programmatic batch submission from unlisted clients), and enable/enforce Kyuubi's authentication and authorization for the REST API rather than leaving it open (trade-off: requires configuring an auth provider and may need client changes). As additional hardening, run the Kyuubi server under a low-privilege account with the upload staging directory on a filesystem where the process cannot write to sensitive paths (config, binaries, cron), limiting what a traversal write can reach. Do not rely on these workarounds long-term; 1.12.0 is the durable fix.
Any client who can access to Apache Kyuubi Server via Kyuubi frontend protocols can bypass server-side config kyuubi.ses
Server-Side Request Forgery (SSRF) and open-proxy behavior in Apache Kyuubi's Engine UI proxy exposes the Kyuubi server
Same weakness CWE-22 – Path Traversal
View allSame technique Path Traversal
View allShare
External POC / Exploit Code
Leaving vuln.today