22.07.2026 Problem:
A security scan of a deployed Apache Spark binary distribution reported two vulnerabilities located in Hive artifacts bundled with Spark: CVE-2024-29869 (org.apache.hive:hive-exec, fixed in Hive 4.0.1) and CVE-2024-23953 (org.apache.hive:hive-llap-common, fixed in Hive 4.0.1). The scan showed the vulnerable artifacts present in the shipped Spark distribution (the Spark 3.5.x line shipped a Hive 2.3.x fork pinned by Spark), and these jars are not declared as direct dependencies in the application build, so they cannot be upgraded via the application’s Maven dependency management.
Operational context: Spark is launched on Kubernetes in cluster mode (driver/executor pods via spark-submit). The application uses Kafka, Cassandra and cloud object storage for data; Hadoop client libraries are present but HDFS is not used (only an example hdfs:// entry commented out). The application does not enable Hive usage (no enableHiveSupport, no HiveContext, no saveAsTable, no Thrift server) and does not use LLAP. The customer asked whether removing specific Hive jars from the Spark image would be safe and sufficient to remove the scanner findings without breaking non-Hive Spark SQL workloads.
Process:
Step 1: Verify scanner findings and artifact versions
Observed the scanner output listing hive-exec and hive-llap-common in the Spark binary. Reviewed the Spark distribution’s jars directory to confirm the exact artifact names and versions (Hive 2.3.x fork present in Spark 3.5.x). This established that the vulnerable code was present inside the Spark image and that the fix exists only in Hive 4.0.1, which is metastore-incompatible with Spark 3.5.x — meaning a simple dependency override in the application build is not viable.
Step 2: Inspect runtime deployment configuration
Observed deployment manifests and spark-submit invocation showing Kubernetes cluster-mode driver/executor pods. Reviewed application source and configuration for Hive usage (search for enableHiveSupport, HiveContext, saveAsTable, catalog configurations). No Hive usage constructs were present and no Thrift server was running. This reduced the likelihood that the Hive jars were actually loaded at runtime for this workload.
Step 3: Confirm storage and metadata stack
Observed declared storage backends (Kafka, Cassandra, cloud object storage) and examined Hadoop client usage. Found only client libraries bundled with Spark and no active HDFS usage; the only hdfs:// reference was a commented example. This confirmed the application did not rely on Hive metastore or HDFS, further lowering the chance of runtime exposure from the Hive runtime.
Step 4: Check Spark upstream version behavior
Observed behavior of later Spark releases by checking distribution packaging notes and sample distributions: Spark 4.x still bundled Hive 2.3.x in available builds. This made upgrading Spark to a newer release insufficient to resolve the reported CVEs, since the vulnerable Hive fork remained present in supported Spark releases.
Step 5: Evaluate runtime class-loading and transitive dependencies
Inspected spark-sql and catalyst modules and examined runtime loading expectations for in-memory catalog usage. Identified the specific jar files flagged by the scanner (hive-exec-2.3.9-core.jar and hive-llap-common-2.3.9.jar) and verified that those classes are only required for Hive/LLAP features. Confirmed that leaving hive-storage-api (needed for ORC support) is required when using ORC. This analysis indicated that removing the two flagged jars would not cause ClassNotFoundExceptions for non-Hive workloads that use the default in-memory catalog.
Step 6: Define remediation paths and handoff
Observed organizational constraints (security policy vs. ability to modify images) and presented two practical remediation options: 1) accept the findings as false positives / risk-accepted because the jars are never loaded in this deployment, or 2) remove the two flagged Hive jars from the Spark binary and repackage the container image used on Kubernetes, then run the standard smoke test suite. Prepared the removal approach and testing guidance so the customer could apply the change in their image build pipeline. This step introduced the recommended change that became the remediation path documented in the Solution below.
Solution:
Recommended and documented a safe remediation: remove hive-exec-2.3.9-core.jar and hive-llap-common-2.3.9.jar from the Spark binary distribution used to build the Kubernetes image, keep hive-storage-api (for ORC support) and run the existing Spark smoke tests against the repackaged image. The change is applied at the image/build layer (remove files from the distribution or produce a Spark build without Hive support) so the vulnerable classes are no longer present in deployed pods.
Architectural rationale: Apache Spark’s SQL engine with the default in-memory catalog does not load Hive runtime classes; removing those jars removes vulnerable code from the attack surface without changing Spark’s runtime classpath behavior for non-Hive workloads. If Hive or LLAP were required, a more complex migration (rebuilding Spark against Hive 4.x and migrating metastore) would be necessary.
Conclusion:
Result: actionable remediation options were delivered—either accept the scanner findings as false positives for a non-Hive deployment or repack the Spark image with the two Hive jars removed. Both options reduce risk: the former documents rationale for risk acceptance, and the latter removes vulnerable artifacts from deployed images, reducing attack surface while preserving Spark SQL functionality for in-memory catalog workloads after standard smoke testing.