Skip to content

Bump shaded jackson 2.18.7 to 2.18.8 to fix CVE-2026-54512 and CVE-2026-54513 in uber jar#1507

Merged
vikrantpuppala merged 4 commits into
databricks:mainfrom
o-shevchenko:fix/jackson-databind-cve-2026-54512-54513
Jun 29, 2026
Merged

Bump shaded jackson 2.18.7 to 2.18.8 to fix CVE-2026-54512 and CVE-2026-54513 in uber jar#1507
vikrantpuppala merged 4 commits into
databricks:mainfrom
o-shevchenko:fix/jackson-databind-cve-2026-54512-54513

Conversation

@o-shevchenko

Copy link
Copy Markdown
Contributor

Summary

  • Bumps shaded jackson.version 2.18.7 → 2.18.8 to fix CVE-2026-54512 and CVE-2026-54513 (PolymorphicTypeValidator bypass) bundled in the uber jar.
  • jackson-databind/jackson-core/jackson-annotations are relocated under com.databricks.internal.fasterxml in the uber jar, so consumers cannot override them via Maven dependency management — the bump must happen at the source.
  • Patch-level upgrade within the 2.18.x line; no API changes.

Relationship to #1485

Dependabot #1485 bumps the same property to 2.22 (a minor-version upgrade, currently open). This PR is the minimal security patch (2.18.8) that targets only CVE-2026-54512 / CVE-2026-54513, for a low-risk, fast-to-review fix. Maintainers can take whichever they prefer.

Test plan

  • mvn -pl assembly-uber -am package -DskipTests builds clean
  • uber jar bundles relocated jackson-databind 2.18.8 (verified via META-INF/.../pom.properties and class paths under com/databricks/internal/fasterxml/jackson/databind)
  • CI unit tests pass

NO_CHANGELOG=true

…26-54513 in uber jar

jackson-databind/core/annotations are relocated under
com.databricks.internal.fasterxml in the uber jar and cannot be overridden
by consumers via Maven dependency management, so the bump must happen at the
source. 2.18.8 is a patch-level upgrade within 2.18.x (no API changes) that
remediates the PolymorphicTypeValidator bypass CVEs.

Signed-off-by: Oleksandr Shevchenko <oleksandr.shevchenko@datarobot.com>
@vikrantpuppala vikrantpuppala enabled auto-merge (squash) June 29, 2026 09:04
vikrantpuppala added a commit that referenced this pull request Jun 29, 2026
## Problem

Forked PRs (e.g. #1507) run Maven in **offline mode** against the
`~/.m2` cache pre-populated by the **Warm Maven Dependency Cache**
workflow. They fail with:

```
The following artifacts could not be resolved:
org.apache.maven.surefire:surefire-junit-platform:jar:3.1.2 (absent):
Cannot access central (https://repo.maven.apache.org/maven2) in offline mode
```

This breaks every test job (unit / integration / coverage, all JDK + OS
combinations) on fork PRs.

## Root cause

The warmer relies on its filtered test steps (4–6) to lazily download
the Surefire JUnit Platform provider (`surefire-junit-platform`). But
those steps fail early with `No tests matching pattern "..."` — there
are no compiled test classes for the narrow `-Dtest=` filters to match,
so Surefire prints `No tests to run` and **never loads (or downloads)
the provider**. The failures are masked by `|| true`, so the warmer
reports success while saving a cache that is missing the provider jar.

Verified in the most recent warm run: `surefire-junit-platform` appears
**0 times** in the warmer log on both Linux and Windows.

## Fix

Add an explicit `dependency:get` for
`org.apache.maven.surefire:surefire-junit-platform` (version read from
the `maven-surefire-plugin.version` POM property, falling back to
`3.1.2`) so the provider is cached deterministically, independent of
whether any filtered test run executes.

## Follow-ups (not in this PR)

- Steps 4–6 silently fail with "No tests matching pattern" (masked by
`|| true`) — the warmer's unit-test steps aren't actually exercising
tests and should be fixed to compile + run real tests.
- A maintainer-applied label to trigger the warmer for a specific PR
(auto-removed on new commits) was discussed and deferred.

NO_CHANGELOG=true

This pull request and its description were written by Isaac.

---------

Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
vikrantpuppala added a commit that referenced this pull request Jun 29, 2026
## Problem

The **Security Scan** check fails on **every fork PR** (e.g. #1507), and
not on a CVE finding — it dies earlier, at the SBOM build:

```
spotless-maven-plugin:pom:2.39.0 (absent): Could not transfer ... from central
(https://repo.maven.apache.org/maven2): Remote host terminated the handshake
```

`securityScan.yml` skips JFrog auth for fork PRs (no OIDC token) on the
assumption — see the old comment — that Maven can fetch everything from
**Maven Central** directly. On the `databricks-protected-runner-group`,
that assumption is false: connections to `repo.maven.apache.org` are
refused (`Remote host terminated the handshake`). So `mvn package` can't
resolve build plugins and the job fails before `osv-scanner` ever runs.
The CVE step is `skipped`. This blocks fork PRs regardless of their
actual CVE posture.

## Fix

Switch the job to the same dependency-resolution flow every other CI job
already uses — `fork-check` + `./.github/actions/setup-maven`:

- **Fork PRs** restore the warmed offline cache and run Maven offline
(no Central, no JFrog creds needed).
- **Same-repo runs** authenticate to JFrog as before.

The cache warmer already downloads the plugins the SBOM build needs —
verified in a warm run that both `cyclonedx-maven-plugin:2.9.1` and
`spotless-maven-plugin:2.39.0` are cached.

This also aligns the checkout with the rest of CI (checks out the fork's
head ref).

## Note on the CVE baseline

Separately, the scheduled (non-fork) Security Scan on `main` can fail on
real OSV-Scanner CVE findings — that's a genuine dependency-CVE signal
and unaffected by this change. This PR only fixes the fork-PR case where
the build couldn't even run.

NO_CHANGELOG=true

This pull request and its description were written by Isaac.

Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
@vikrantpuppala vikrantpuppala disabled auto-merge June 29, 2026 16:32
@vikrantpuppala vikrantpuppala merged commit 2d78686 into databricks:main Jun 29, 2026
15 of 16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants