[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

[aslomka]

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 [Spark connector]Added spark 4.1 support #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

[github-actions]

Thank you for your feedback. Tagging and routing to the team member(s) best able to assist.

//cc: @kushagraThapar @pjohari-ms @TheovanKraay

[github-actions]

🎯 Agentic Issue Triage

Summary: External customer reports 34 known CVEs in the shaded uber-JAR of azure-cosmos-spark_4-0_2-13 and azure-cosmos-spark_4-1_2-13 (versions 4.48.0–4.49.1), all from bundled transitive dependencies (Netty, commons-lang 2.6, msal4j). Because the connector is a fat JAR, consumers cannot override these versions from their classpath — upgrades must come from the SDK release.

📋 Issue Details

Package: com.azure.cosmos.spark:azure-cosmos-spark_4-0_2-13:4.49.1 (and azure-cosmos-spark_4-1_2-13:4.49.1), transitively bundling com.azure:azure-cosmos:4.81.0 and com.azure:azure-core-http-netty:1.16.4

Affected components:

• io.netty:netty-* bundled at 4.1.118.Final
• commons-lang:commons-lang:2.6 (EOL branch)
• com.microsoft.azure:msal4j:1.15.0

Scenarios:

• SCA scan (Sonatype Lifecycle, Snyk, Trivy, OWASP Dependency-Check, Black Duck) against the shaded JAR surfaces CVEs in the embedded class paths
• Upgrading the connector from 4.48.0 to 4.49.1 does not resolve findings — same dependency versions are bundled
• Security reviews are blocking deployment and runtime upgrades on Databricks Runtime 17.3 (Azure Germany West Central)

Root ask: Publish new azure-cosmos-spark_4-*_2-13 releases (and the underlying azure-cosmos release) with:

1. io.netty:netty-* ≥ 4.1.133.Final
2. commons-lang:commons-lang:2.6 removed; replaced with org.apache.commons:commons-lang3:3.18.0+
3. com.microsoft.azure:msal4j ≥ 1.15.1

🔎 Debugging / Reproduction Notes

The issue is straightforward to reproduce: download either the 4.48.0 or 4.49.1 shaded JAR from Maven Central and run any standard SCA tool against it. The CVEs are well-documented:

• CVE-2025-55163 (Netty HTTP/2 "MadeYouReset" DoS)
• CVE-2026-42579 (Netty DNS codec input validation bypass, CWE-20/400/626)
• CVE-2025-58057 (Netty BrotliDecoder OOM)
• CVE-2025-48924 (commons-lang 2.x uncontrolled recursion / StackOverflowError in ClassUtils.getClass, CWE-674 — no fix on 2.x branch)
• CVE-2024-35255 (msal4j race condition, local credential exposure, CWE-362)

Suggested investigation steps:

1. Confirm bundled dependency versions in the pom/shade config under sdk/cosmos/azure-cosmos-spark/ for the 4-0 and 4-1 variants.
2. Evaluate whether io.netty ≥ 4.1.133.Final is compatible with the connector's internal Netty usage.
3. Assess the commons-lang 2.x → commons-lang3 migration scope within azure-cosmos-spark and azure-cosmos.
4. Update msal4j to ≥ 1.15.1 (should be a drop-in version bump).
5. Author notes that 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 PR [Spark connector]Added spark 4.1 support #48861), so a single upstream fix should address both artifacts.
6. Customer has offered to share the full 34-finding report privately via MSRC or the Azure SDK security channel.

🏷️ Label Confidence

• Category: Client — The issue is about third-party library versions bundled inside the Azure SDK client artifact (the shaded JAR), not a REST API / service-side issue. Category "Mgmt" and "Provisioning" do not apply.
• Service: Cosmos — Explicitly names azure-cosmos-spark_4-*_2-13 and azure-cosmos packages under sdk/cosmos/.
• Confidence: High — The affected packages, service directory, and category are unambiguous. Reference issues (e.g., [QUERY] When will Azure Cosmos DB OLTP Spark 4 connector be ready? #46290) confirm the Client + Cosmos label combination for this service directory.

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Cosmos (line 295) — service label "Cosmos" matches directly
• AzureSdkOwners: none listed
• ServiceOwners: @kushagraThapar @pjohari-ms @TheovanKraay
• Routing action: Added "Service Attention" and "needs-team-attention" labels; @mentioned ServiceOwners via routing comment
• Scan notes: Scanned bottom-to-top; no more-specific multi-label entry for %Cosmos was found above this entry. Management-section entries were skipped (require %Mgmt). Spring-Cosmos entry at line 552 requires %Azure.Spring - Cosmos which is not applicable here.

Generated by Agentic Triage for #49865 · 34.7 AIC · ⌖ 5.86 AIC · ⊞ 11K · ◷