Is pyspark safe ? 12 known vulnerabilities, worst severity CRITICAL.
// reach 9 direct dependencies
4 carry known advisories, worst CRITICAL
85 packages depend on it
an advisory here reaches each of them
// ai model usage No published models are known to use this package.
cvss CVSS v3.1 base score out of 10
epss chance of exploitation in 30 days, 66th percentile of all CVEs
xyz score CyberXYZ composite out of 10
fig. 01 — GHSA-329j-jfvr-rhr6, the advisory selected below
// 12 advisories GHSA-329j-jfvr-rhr6 In Apache Spark versions prior to versions 3.4.0 and 3.3.3, applications using spark-submit can specify a proxy-user to run as, limiting privileges. The application can execute code with the privileges of the submitting user, however, by providing malicious configuration-related classes on the classpath. This affects architectures relying on proxy-user, for example those using Apache Livy to manag CRIT GHSA-wgx7-jwwm-cgjv In Apache Spark 2.4.5 and earlier, a standalone resource manager's master may be configured to require authentication (spark.authenticate) via a shared secret. When enabled, however, a specially-crafted RPC to the master can succeed in starting an application's resources on the Spark cluster, even without the shared key. This can be leveraged to execute shell commands on the host machine. This doe CRIT GHSA-59hw-j9g6-mfg3 The Apache Spark UI offers the possibility to enable ACLs via the configuration option spark.acls.enable. With an authentication filter, this checks whether a user has access permissions to view or modify the application. If ACLs are enabled, a code path in HttpSecurityFilter can allow someone to perform impersonation by providing an arbitrary user name. A malicious user might then be able to reac HIGH GHSA-4x9r-j582-cgr8 The Apache Spark UI offers the possibility to enable ACLs via the configuration option spark.acls.enable. With an authentication filter, this checks whether a user has access permissions to view or modify the application. If ACLs are enabled, a code path in HttpSecurityFilter can allow someone to perform impersonation by providing an arbitrary user name. A malicious user might then be able to reac KEV HIGH GHSA-9rr6-jpg7-9jg6 Apache Spark supports end-to-end encryption of RPC connections via "spark.authenticate" and "spark.network.crypto.enabled". In versions 3.1.2 and earlier, it uses a bespoke mutual authentication protocol that allows for full encryption key recovery. After an initial interactive attack, this would allow someone to decrypt plaintext traffic offline. Note that this does not affect security mechanisms HIGH GHSA-fp5j-3fpf-mhj5 Prior to Spark 2.3.3, in certain situations Spark would write user data to local disk unencrypted, even if spark.io.encryption.enabled=true. This includes cached blocks that are fetched to disk (controlled by spark.maxRemoteBlockSizeFetchToMem); in SparkR, using parallelize; in Pyspark, using broadcast and parallelize; and use of python udfs. HIGH GHSA-8rhc-48pp-52gr In Apache Spark 1.6.0 until 2.1.1, the launcher API performs unsafe deserialization of data received by its socket. This makes applications launched programmatically using the launcher API potentially vulnerable to arbitrary code execution by an attacker with access to any user account on the local machine. It does not affect apps run by spark-submit or spark-shell. The attacker would be able to e HIGH GHSA-9437-39hj-3c93 There is a lack of XSS escaping in the Spark History Server prior to 3.5.8 which allows a malicious Spark job to generate arbitrary unescaped frontend code which could lead to a minimal privilege escalation in browser. Users are encouraged to upgrade to Spark 3.5.8 or later. MODE GHSA-43xg-8wmj-cw8h A stored cross-site scripting (XSS) vulnerability in Apache Spark 3.2.1 and earlier, and 3.3.0, allows remote attackers to execute arbitrary JavaScript in the web browser of a user, by including a malicious payload into the logs which would be returned in logs rendered in the UI. MODE GHSA-6mqq-8r44-vmjc In Apache Spark 1.0.0 to 2.1.2, 2.2.0 to 2.2.1, and 2.3.0, when using PySpark or SparkR, it's possible for a different local user to connect to the Spark application and impersonate the user running the Spark application. MODE GHSA-fvxv-9xxr-h7wj When using PySpark , it's possible for a different local user to connect to the Spark application and impersonate the user running the Spark application. This affects versions 1.x, 2.0.x, 2.1.x, 2.2.0 to 2.2.2, and 2.3.0 to 2.3.1. MODE GHSA-6p6v-m64v-jx8q This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. LOW In Apache Spark versions prior to versions 3.4.0 and 3.3.3, applications using spark-submit can specify a proxy-user to run as, limiting privileges. The application can execute code with the privileges of the submitting user, however, by providing malicious configuration-related classes on the classpath. This affects architectures relying on proxy-user, for example those using Apache Livy to manage submitted applications.
Update to Apache Spark 3.4.0, 3.3.3, or later, and ensure that spark.submit.proxyUser.allowCustomClasspathInClusterMode is set to its default of "false", and is not overridden by submitted applications.
// cvss v3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Attack vector Network
Attack complexity Low
Privileges required Low
User interaction None
Scope Changed
Confidentiality High
Integrity High
Availability High Checked 2026-11-06 at 22:42 UTC. The most recent advisory here was published 2026-09-02. Updated continuously from NVD, GHSA, OSV and CNA feeds.
Think a verdict here is wrong? Tell us — we respond within 2 business days. Report an issue with this page