Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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. This CVE is marked as "low" since the path to exploit requires both relatively high permissions (ability to launch a Spark job) and requires tricking a user with higher permissions to log in and visit the Spark history web page. Users are encouraged to upgrade their Spark history servers to Spark 3.5.8 or later.
Recommended action: Upgrade to 3.5.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security.
Recommended action: Upgrade to 3.5.2 or 3.4.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 reach a permission check function that will ultimately build a Unix shell command based on their input, and execute it. This will result in arbitrary shell command execution as the user Spark is currently running as. This issue was disclosed earlier as CVE-2022-33891, but incorrectly claimed version 3.1.3 (which has since gone EOL) would not be affected. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. Users are recommended to upgrade to a supported version of Apache Spark, such as version 3.4.0.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 reach a permission check function that will ultimately build a Unix shell command based on their input, and execute it. This will result in arbitrary shell command execution as the user Spark is currently running as. This affects Apache Spark versions 3.0.3 and earlier, versions 3.1.1 to 3.1.2, and versions 3.2.0 to 3.2.1. A previous version of this advisory incorrectly stated that version 3.1.3 was not vulnerable. Per GHSA-59hw-j9g6-mfg3, version 3.1.3 is vulnerable and vulnerable version ranges in this advisory have been changed to reflect the correct information.
Recommended action: Upgrade to 3.2.2 or 3.1.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 controlled by "spark.authenticate.enableSaslEncryption", "spark.io.encryption.enabled", "spark.ssl", "spark.ui.strictTransportSecurity". Update to Apache Spark 3.1.3 or later
Recommended action: Upgrade to 3.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 does not affect Spark clusters using other resource managers (YARN, Mesos, etc).
Recommended action: Upgrade to 2.4.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.2.2 or 2.1.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.3.2 or 2.2.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 execute code as the user that ran the Spark application. Users are encouraged to update to version 2.1.2, 2.2.0 or later.
Recommended action: Upgrade to 2.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.