CVE-2022-33891: Apache Spark UI command injection via user impersonation, actively exploited
The short version: Apache Spark's UI has a flaw (CVE-2022-33891) that surfaces when ACLs are enabled: a code path in the security filter lets an attacker supply an arbitrary username, impersonate that user, and run shell commands as the account Spark runs under. It's in CISA's KEV catalog. Patch, and keep the Spark UI off the public internet. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — exploited, but gated on ACLs being enabled and the UI reachable |
| CVSS v3.1 (NVD) | 8.8 — High · AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| EPSS | ~92.98% · 99.82th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation was due 2023-03-28 |
| Known exploited? | Yes — public exploit code; CISA-listed as exploited |
| Vulnerability type | CWE-78 OS command injection (via user impersonation in HttpSecurityFilter) → shell command execution as the Spark user |
| Requires authenticated session? | No — the flaw is the impersonation itself |
| Affected | Apache Spark ≤ 3.0.3; 3.1.1–3.1.2; 3.2.0–3.2.1 (with spark.acls.enable set) |
| Fixed in | Apache Spark 3.1.3 · 3.2.2 · 3.3.0 |
What you need to know
Apache Spark can enforce access control on its UI via spark.acls.enable. CVE-2022-33891 is a flaw in the code that checks those ACLs: through the HttpSecurityFilter, an attacker can provide an arbitrary user name and have Spark treat the request as that user. Because the impersonation feeds into a command path, it results in arbitrary shell command execution as the account the Spark process runs under.
The practical shape of the risk:
- The precondition is ACLs enabled. The vulnerable path only triggers when
spark.acls.enableis set — but that's a common hardening choice, so plenty of deployments qualify. - The UI has to be reachable. Spark UIs are frequently exposed for convenience, which is exactly where this bites.
- It's exploited and automatable. Public exploit code exists and CISA lists it as exploited.
How serious we see it
High — real and exploited, with an honest precondition.
We don't call it Critical because two things have to be true: ACLs enabled, and the UI reachable by the attacker. Where both hold, this is unauthenticated-feeling command execution as the Spark user on a data-processing node — serious, and in KEV, which is why it clears High comfortably. The reassuring part is that it's fully in your hands: patch, and don't expose the Spark UI to the internet.
Recommendations
Straight from the Apache Spark security guidance and CISA:
- Patch now. Upgrade to Apache Spark 3.1.3 / 3.2.2 / 3.3.0 or later.
- Get the Spark UI off the internet. Restrict it to trusted networks or behind a VPN.
- Review ACL configuration. Understand where
spark.acls.enableis set and what those nodes can reach. - Hunt for prior use. Review logs for requests supplying unexpected
doAs/user parameters to the Spark UI. - Confirm your exposure first. Verify whether any internet-facing Spark UI runs an affected version with ACLs enabled.
How BreachRisk sees it
BreachRisk discovers internet-facing Spark UIs from little more than your domain, fingerprints the version, and flags exposure tied to KEV-listed vulnerabilities like this one — surfaced at the top of your results because it's in KEV.
That outside-in view matters most for services people expose for convenience and forget: an internet-reachable Spark UI is mapped and ranked, so you can close it before it becomes someone's command shell.