Vulnerabilities for com.databricks:databricks-jdbc:3.4.1 jar

[psjava31955]

We are reporting two groups of Snyk-identified security vulnerabilities in com.databricks:databricks-jdbc:3.4.1 caused by shaded/embedded dependencies that cannot be remediated by consumers through standard dependency management overrides.

Why We Cannot Remediate This on Our Side

The Databricks JDBC driver is a shaded JAR — the vulnerable artifacts (jackson-databind, httpcore5-h2) are bundled inside the driver under relocated package namespaces. Standard Gradle/Maven remediation techniques are ineffective:

ext['jackson-bom.version'] and ext['httpcore5.version'] BOM overrides only affect unshaded transitive dependencies on the classpath — they do not reach bytecode already embedded in the driver JAR.

resolutionStrategy.eachDependency and dependencyManagement constraints similarly have no effect on shaded artifacts.

Snyk continues to flag the vulnerabilities against the shaded copies even after all available overrides are applied.

Please upgrade the following in an upcoming patch release of databricks-jdbc:

com.fasterxml.jackson.core:jackson-databind → 2.21.5+

org.apache.httpcomponents.core5:httpcore5-h2 → 5.4.2+

This will allow enterprise teams operating under strict security scanning policies (Snyk) to remain compliant without being blocked on driver upgrades.

We are currently running Spring Boot 3.5.15 with aggressive Snyk remediation in place for all other transitive dependencies. The JDBC driver is the sole remaining source of these vulnerability flags. We would also welcome any workaround guidance if a patch release is not immediately feasible.

Thank you for your attention to this.

[Louis_Frolio · Accepted solution]

@psjava31955 , thanks for the detailed writeup, and you've got the mechanism exactly right. The uber jar (com.databricks:databricks-jdbc) is shaded, so those artifacts are relocated inside the jar. BOM overrides, resolutionStrategy, and dependencyManagement all act on the resolved classpath, not on bytecode that's already embedded in the jar, so they never reach the shaded copies. That's expected behavior, not something you're doing wrong.

Here's the thing to check before you wait on a patch: 3.4.1 is already the latest release, and it's mostly a dependency-bump release. Per the 3.4.1 notes, the uber jar already moved shaded httpcore5-h2 to 5.5.2 (for CVE-2025-8671), which is above the 5.4.2+ you asked for, and it moved shaded jackson-core to 2.18.7 (for the JSON DoS advisory). The driver tracks the 2.18.x line, so jackson-databind should be sitting on that same line.

So the first step is a clean rebuild and rescan against 3.4.1 with your build cache cleared. That separates what's genuinely still open from what a stale artifact is reporting. If httpcore5-h2 still trips on a clean 3.4.1 build, it's most likely either a cached jar or a newer advisory that came out after the release. If you can share the exact CVE or Snyk advisory IDs your scan reports, that'll settle it quickly.

One honest caution on the jackson side. You cited a jackson-databind floor of 2.21.5+, but the driver pins the 2.18.x line, so 2.21.5 doesn't line up with how they version (Snyk often points you at the newest release rather than the minimal fix). Even after a library gets bumped, I wouldn't assume a policy that demands a specific minimum is satisfied until you've validated the actual artifact against your own scanner.

If you want to remediate yourself today instead of waiting, there's a thin jar published alongside the uber jar:

com.databricks:databricks-jdbc-thin

In the thin jar, the dependencies aren't bundled or relocated, so they resolve as normal transitive deps. Your existing BOM overrides and dependencyManagement constraints take effect again, and you can force jackson-databind and httpcore5-h2 to whatever your policy requires. Two things to weigh before you adopt it: you take on supplying and version-managing those transitive deps yourself, and you'll want to validate packaging and runtime compatibility with the driver before you rely on it in production.

For a fix to the uber jar itself, the more direct path is a GitHub issue on the databricks/databricks-jdbc repo rather than the forum. The driver team does act on these, and they reference the specific advisory IDs when they cut a release. Include the artifact, the advisory ID, and the version you need.

For staying compliant in the meantime: for any finding you can confirm is a false positive, or not exploitable in the driver's actual usage, a documented Snyk ignore with that justification keeps you unblocked. The 3.4.1 notes even label a few of their own bumps as not exploitable in this usage, which is the kind of reasoning that holds up in a security review.

So, to pull it together: rescan a clean 3.4.1 to see what's truly still open, move to databricks-jdbc-thin if you want to self-remediate now, and file a GitHub issue with the advisory IDs for anything that still needs a bump in the uber jar.

Regards, Louis

[psjava31955]

Thank you so much Louis! The above solution to use databricks-jdbc-thin dependency worked. Appreciate your prompt response.

[Louis_Frolio]

If you are satisfied @psjava31955 please "Accept as Solution" so that others can have confidence in the response.  Cheers, Lou.