fix(security): backport io.kubernetes:client-java 25.0.1 (CVE-2026-15687) to 2.0

[mohityadav766]

Backport of #31342 to 2.0. Cherry-picked clean — 2.0 carries the same kubernetes-client.version 24.0.0 and the same unpinned logging-interceptor.

Bumps io.kubernetes:client-java 24.0.0 → 25.0.1 to clear CVE-2026-15687 (SNYK-JAVA-IOKUBERNETES-18313175), and pins com.squareup.okhttp3:logging-interceptor to 4.12.0 so the bump does not drag okhttp 5 onto the classpath.

Directory Traversal in copyDirectoryFromPod when enableTarCompressing=false. CVSS 4.8, vulnerable range [,25.0.1). We never call Copy, so this is not exploitable here — but openmetadata-dist ships the jar, so the vulnerable version reaches OSS installs and turns up in downstream scans.

Why our own Snyk report is green on this. Our scan applies a high severity floor, and this finding is medium — so all 20 of our pom.xml manifests report ok: true while shipping the vulnerable version. It surfaced in the Collate scan, which includes medium.

Why the logging-interceptor pin

client-java 25.x declares logging-interceptor 5.1.0, and okhttp 5 relocated the okhttp3.* classes out of okhttp into a new okhttp-jvm artifact. Root dependencyManagement already pins okhttp to 4.12.0, so without a matching pin, okhttp-jvm:5.1.0 joins okhttp:4.12.0 on the classpath and okhttp3.* ends up split across two jars, resolved by classpath order — a silent, order-dependent hazard in the shipped distribution.

okhttp 4.12.0 satisfies client-java 25.0.1: its bytecode references the exact same 118 okhttp3/okio members as 24.0.0 does today — zero added, zero removed. Upstream's move to okhttp 5 is a declared-dependency bump, not an API requirement. The pin should be dropped only as part of a real okhttp 5 migration.

Verification

• Resolved classpath is surgical. Across the 596 artifacts openmetadata-service + openmetadata-k8s-operator resolve, the only three that move are client-java, client-java-api and client-java-proto. No okhttp-jvm; okhttp stays 4.12.0, logging-interceptor 4.12.0, kotlin-stdlib 1.8.21.
• Only API removal in 25.0.1 is unused. I diffed the public API of all 43 io.kubernetes types we import — including CoreV1Api, BatchV1Api, CustomObjectsApi, ApiextensionsV1Api, VersionApi, ClientBuilder, Config and Yaml — between 24.0.0 and 25.0.1. The only removed public members anywhere in that surface are V1ResourceRequirements.claims* and the V1ResourceClaim type (k8s 1.34 DRA rework). Every V1ResourceRequirements call site here (K8sPipelineClient, OMJob, K8sJobUtilsTest) uses only .requests()/.limits(), and there are zero V1ResourceClaim references in the repo.
• openmetadata-service and openmetadata-k8s-operator build against 25.0.1.

Related

Collate carries the same bump: open-metadata/openmetadata-collate#5663 (main) and #5664 (2.0). Collate's root dependencyManagement pins client-java for its own modules, so it was already covered — this PR fixes it at the source so OSS installs are too, and so the Collate pin stops being a silent override of a vulnerable upstream version.

🤖 Generated with Claude Code

[github-actions]

❌ PR checklist incomplete

This PR cannot be merged until the following are addressed on its linked issue:

• No GitHub issue is linked. Link an issue in the Development section of the PR (or add Fixes #12345 to the description). For a same-org cross-repo issue, add Fixes open-metadata/<repo>#123 to the description.

The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically.

Maintainers can bypass this check by adding the skip-pr-checks label.

[gitar-bot]

Code Review ✅ Approved

Bumps io.kubernetes:client-java to 25.0.1 and pins okhttp3:logging-interceptor to 4.12.0 to resolve CVE-2026-15687 without classpath conflicts. No issues found.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}

[github-actions]

✅ Playwright Results — workflow succeeded

Validated commit 84764a7077d0baffad268cb61643bd79624f45e3 in Playwright run 31499593316, attempt 1.

✅ 550 passed · ❌ 0 failed · 🟡 0 flaky · ⏭️ 0 skipped · 🧰 0 lifecycle flaky

Performance

Blocking targets: ✅ met · Optimization targets: 🟡 in progress

Shard-job maxima below are not the full workflow wall time; the linked run includes build, fixture, planning, and reporting.

🕒 Full workflow signal wall (to summary) 56m 4s

⏱️ Max setup 3m 24s · max shard execution 17m 56s · max shard-job elapsed before upload 21m 7s · reporting 4s

🌐 202.49 requests/attempt · 2.83 app boots/UI scenario · 17.10% common-shard skew

Optimization targets still in progress:

• Common shard skew was 17.1% (convergence target: at most 15%).
• Browser traffic was 202.49 requests per attempt (convergence target: fewer than 200).
• Application boot ratio was 2.83 per UI scenario (1617 boots / 571 scenarios; convergence target: at most 1).

Shard	Passed	Failed	Flaky	Skipped	Lifecycle failed	Lifecycle flaky
✅ Shard chromium-01	143	0	0	0	0	0
✅ Shard chromium-02	133	0	0	0	0	0
✅ Shard chromium-03	123	0	0	0	0	0
✅ Shard data-asset-rules-01	61	0	0	0	0	0
✅ Shard domain-isolation-01	14	0	0	0	0	0
✅ Shard global-state-01	34	0	0	0	0	0
✅ Shard ingestion-01	1	0	0	0	0	0
✅ Shard reindex-01	2	0	0	0	0	0
✅ Shard search-01	10	0	0	0	0	0
✅ Shard search-rbac-01	29	0	0	0	0	0

📦 Download artifacts

How to debug locally

# Download playwright-test-results-<shard> artifact and unzip
npx playwright show-trace path/to/trace.zip    # view trace