Azure / Azure/azure-sdk-for-java

[BUG] [cosmos-spark] Bump transitive Netty (>=4.1.133.Final), msal4j (>=1.15.1) and replace commons-lang 2.6 with commons-lang3 in azure-cosmos-spark_4-*_2-13 4.49.1 / azure-cosmos 4.81.0

Open
#49,865 2 comments 1 reaction 5 assignees Claimed by @FabianMeiswinkel View on GitHub
bug Client Cosmos customer-reported needs-team-attention Service Attention
Dominant language
Java
Stars
2.6k
Forks
2.2k
Avg merge
2d 8h
Merged PRs (30d)
178

Description

### Library name and version

- `com.azure.cosmos.spark:azure-cosmos-spark_4-0_2-13:4.48.0` (currently deployed)
- `com.azure.cosmos.spark:azure-cosmos-spark_4-0_2-13:4.49.1` (latest)
- `com.azure.cosmos.spark:azure-cosmos-spark_4-1_2-13:4.49.1` (latest)
- Transitively bundled: `com.azure:azure-cosmos:4.81.0`, `com.azure:azure-core-http-netty:1.16.4`

### Describe the bug

An internal SCA scan of the shaded uber-JAR `azure-cosmos-spark_4-0_2-13-4.48.0.jar` (Databricks Runtime 17.3 candidate) surfaced **34 known CVEs** in transitive dependencies (0 CRITICAL, 13 HIGH, 18 MEDIUM, 3 LOW). None originate from Cosmos code — all come from third-party libraries shipped inside the connector's fat JAR.

Verifying against the latest release (`4.49.1`, published 2026-07-03) and the Spark 4.1 sibling artifact (`azure-cosmos-spark_4-1_2-13:4.49.1`) shows **the same dependency versions** are still bundled, so upgrading the connector does not remediate the findings. The `CHANGELOG.md` entries for `azure-cosmos-spark_4-*_2-13` 4.48.0 → 4.49.1 and `azure-cosmos` 4.80.0 → 4.81.0 do not list any Netty / MSAL4J / commons-lang bumps.

Because the connector is shipped as a shaded JAR, consumers cannot override these libraries from their classpath — the fix has to come from the Azure SDK release.

### Concrete vulnerable components and fixed versions requested

| Priority | Component | Bundled version | Requested target | Representative CVEs |
|---|---|---|---|---|
| P0 — HIGH | `io.netty:netty-*` (all modules) | `4.1.118.Final` | **≥ 4.1.133.Final** | CVE-2025-55163 (HTTP/2 "MadeYouReset" DoS), CVE-2026-42579 (DNS codec input validation bypass, CWE-20/CWE-400/CWE-626), CVE-2025-58057 (BrotliDecoder "zip bomb" OOM) |
| P0 — HIGH | `commons-lang:commons-lang` | `2.6` (EOL branch) | **replace with `org.apache.commons:commons-lang3` ≥ 3.18.0** | CVE-2025-48924 (uncontrolled recursion / StackOverflowError in `ClassUtils.getClass`, CWE-674). No fix exists on the 2.x branch. |
| P1 — MEDIUM | `com.microsoft.azure:msal4j` | `1.15.0` | **≥ 1.15.1** | CVE-2024-35255 (race condition, local credential exposure across processes, CWE-362) |
| P2 | Remaining 15 MEDIUM/LOW findings in transitive Azure SDK deps | various | per advisory | (list can be shared privately if useful) |

### Impact / customer context

- We are running Cosmos DB Spark connector on Databricks in **Azure Germany West Central**. The regional constraint means there is currently no readily-swappable managed alternative to Cosmos DB for this workload, so we depend on this connector remaining consumable.
- The current 4.48.0 build was already flagged and blocked by our security review. The candidate upgrade for Databricks Runtime 17.3 (also 4.48.0 → 4.49.1) will fail the same scan for the same reasons, blocking runtime upgrades and reinstallations.
- Because the connector ships as a shaded uber-JAR, we cannot mitigate on the consumer side by pinning newer Netty / MSAL4J via classpath overrides.

### Expected behavior

Publish an `azure-cosmos-spark_4-0_2-13` and `azure-cosmos-spark_4-1_2-13` release (and the underlying `azure-cosmos` release it depends on) in which:

1. `io.netty:netty-*` is upgraded to `4.1.133.Final` or newer.
2. `commons-lang:commons-lang:2.6` is removed and replaced with `org.apache.commons:commons-lang3:3.18.0` (or newer).
3. `com.microsoft.azure:msal4j` is upgraded to `1.15.1` or newer.

If any of these upgrades are blocked by API/behavior compatibility inside the SDK, please share the constraint so we can coordinate a mitigation plan.

### Actual behavior

Current shaded JARs still bundle Netty `4.1.118.Final`, `commons-lang 2.6` and `msal4j 1.15.0`, matching the scan findings.

### Reproduction steps

1. Download `azure-cosmos-spark_4-0_2-13-4.48.0.jar` (or `-4.49.1.jar`, or the corresponding `_4-1_` artifact) from Maven Central.
2. Run any SCA tool (Sonatype Lifecycle, Snyk, Trivy, OWASP Dependency-Check, Black Duck) against the JAR.
3. Observe the CVEs listed above being flagged against the bundled `io/netty/**/*`, `org/apache/commons/lang/**/*`, and `com/microsoft/aad/msal4j/**/*` class paths inside the shaded JAR.

### Environment

- Databricks Runtime 17.3 (target), Spark 4.0 / Scala 2.13
- Region: Azure Germany West Central
- Java: whatever DBR 17.3 ships (Temurin 17)

### Additional context

- Both `azure-cosmos-spark_4-0_2-13` and `azure-cosmos-spark_4-1_2-13` share the `azure-cosmos-spark_4` base module introduced in 4.48.0 (PR #48861), so a single upstream bump in `azure-cosmos` / the shading of the connector should fix both artifacts simultaneously.
- Happy to provide the full scan report privately (34 findings) via MSRC or the Azure SDK security channel if that helps triage.

/cc @xinlian12 @kushagraThapar @FabianMeiswinkel

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.