CVE-2025-55039 Overview
CVE-2025-55039 affects Apache Spark versions before 3.4.4, 3.5.2, and 4.0.0. The vulnerability stems from an insecure default network encryption cipher used for Remote Procedure Call (RPC) communication between Spark nodes. When spark.network.crypto.enabled is set to true but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in Counter (CTR) mode (AES/CTR/NoPadding). This mode provides confidentiality without authentication, allowing tampering to go undetected. The weakness maps to [CWE-326] Inadequate Encryption Strength.
Critical Impact
A network-positioned attacker can modify encrypted RPC traffic by flipping ciphertext bits, compromising heartbeat messages or application data and undermining the integrity of Spark workflows.
Affected Products
- Apache Spark versions before 3.4.4
- Apache Spark 3.5.x versions before 3.5.2
- Apache Spark 4.0.0 (pre-release lines prior to fix)
Discovery Timeline
- 2025-10-15 - CVE-2025-55039 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-55039
Vulnerability Analysis
Apache Spark supports optional encryption of RPC traffic between driver, executor, and worker processes. Administrators enable this by setting spark.network.crypto.enabled=true. The cipher used is controlled by spark.network.crypto.cipher. When operators do not set this property, Spark falls back to AES/CTR/NoPadding.
AES-CTR is a stream cipher construction. It provides confidentiality but does not authenticate ciphertext. An attacker who intercepts RPC frames can flip bits in the ciphertext, producing predictable bit flips in the corresponding plaintext after decryption. The receiver has no cryptographic means to detect the modification.
Because Spark RPC carries executor heartbeats, task metadata, block manager messages, and application payloads, silent modification can influence scheduling decisions, corrupt intermediate results, or steer control-plane messages. This is a classic malleability weakness in unauthenticated encryption modes.
Root Cause
The root cause is an insecure default configuration. Spark ships with an unauthenticated cipher as the default value for spark.network.crypto.cipher. Operators enabling encryption reasonably expect both confidentiality and integrity, but the default satisfies only the former.
Attack Vector
Exploitation requires an on-path attacker with the ability to observe and modify RPC traffic between Spark nodes. The attacker does not need credentials or user interaction. By flipping bits at known ciphertext offsets, the attacker changes corresponding plaintext bits after decryption, altering messages such as executor heartbeats or serialized application data. See the Apache Mailing List Thread and the OpenWall OSS-Security Post for the disclosure details.
Detection Methods for CVE-2025-55039
Indicators of Compromise
- Unexplained executor heartbeat failures, task retries, or block manager errors correlated with unusual network activity between Spark nodes.
- Presence of spark.network.crypto.enabled=true in Spark configuration without an explicit spark.network.crypto.cipher=AES/GCM/NoPadding setting.
- Unexpected ARP, routing, or DNS changes on subnets carrying Spark RPC traffic.
Detection Strategies
- Audit Spark configuration files (spark-defaults.conf) and cluster manager submissions for missing spark.network.crypto.cipher values while encryption is enabled.
- Inventory Spark deployments by version and flag any cluster running a release earlier than 3.4.4, 3.5.2, or 4.0.0.
- Use network telemetry to identify traffic paths where Spark RPC transits untrusted network segments.
Monitoring Recommendations
- Forward Spark driver and executor logs to a centralized data lake or SIEM and alert on abnormal rates of RPC deserialization failures.
- Monitor for man-in-the-middle preconditions on Spark subnets, including ARP spoofing and rogue gateway advertisements.
- Track configuration drift so that clusters revert to unauthenticated ciphers do not go unnoticed after redeployment.
How to Mitigate CVE-2025-55039
Immediate Actions Required
- Upgrade Apache Spark to version 3.4.4, 3.5.2, 4.0.0, or later on all driver, executor, and worker nodes.
- Where upgrade is not immediate, explicitly set spark.network.crypto.cipher=AES/GCM/NoPadding to enable authenticated encryption.
- Alternatively, enable Transport Layer Security by setting spark.ssl.enabled=true with valid certificates for RPC endpoints.
- Restrict Spark RPC traffic to trusted network segments protected by segmentation and firewall rules.
Patch Information
Apache addressed the issue in Spark 3.4.4, 3.5.2, and 4.0.0. Upgrade guidance and cipher configuration details are documented in the Apache Mailing List Thread.
Workarounds
- Set spark.network.crypto.cipher=AES/GCM/NoPadding to force authenticated encryption using AES-GCM.
- Enable SSL/TLS with spark.ssl.enabled=true and configure key and trust stores across all cluster nodes.
- Deploy Spark clusters inside isolated virtual private clouds or private subnets to reduce exposure to on-path attackers.
# Configuration example: spark-defaults.conf
spark.network.crypto.enabled true
spark.network.crypto.cipher AES/GCM/NoPadding
# Optional stronger transport security
spark.ssl.enabled true
spark.ssl.keyStore /etc/spark/ssl/keystore.jks
spark.ssl.trustStore /etc/spark/ssl/truststore.jks
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

