chore(QTDI-3340): Bump cxf.version to fix CVE-2026-50645

[undx]

Requirements

• Any code change adding any logic MUST be tested through a unit test executed with the default build
• Any API addition MUST be done with a documentation update if relevant

Why this PR is needed?

Remediates CVE-2026-50645 (CWE-400 uncontrolled resource consumption / unauthenticated DoS via
unbounded attachment parts per message, CVSS 3.1 7.5 High) in Apache CXF cxf-core.

Jira: QTDI-3340

What does this PR adds (design/code thoughts)?

• Bumps the root pom.xml cxf.version property from 3.5.11 → 3.6.12. This single property
  governs every org.apache.cxf artifact declared in the reactor's dependencyManagement, and
  remediates all 10 reactor modules that resolve org.apache.cxf:cxf-core directly or
  transitively (verified via mvn dependency:tree -Dincludes=org.apache.cxf:cxf-core, reactor
  root, no -q): component-server-parent/component-server, vault-client, documentation,
  talend-component-maven-plugin, component-starter-server, component-tools,
  component-tools-webapp, images/component-server-image, images/component-starter-server-image,
  reporting.
• Fixes a regression the bump directly causes in documentation/.../Github.java: CXF 3.6.x no
  longer transitively supplies jakarta.xml.ws-api (previously pulled in via
  cxf-rt-frontend-jaxrs's own POM), so reflectively loading the optional CXF GZIPFeature class
  now throws NoClassDefFoundError (an Error, not caught by the existing catch (Exception e))
  instead of succeeding. Widened the catch to catch (Exception | NoClassDefFoundError e),
  mirroring the existing, identical idiom already used in component-server's
  ComponentServerConfiguration#init for the same CXF reflection pitfall.

Verification performed (see full detail in the review-history PR comments):

• mvn dependency:tree -Dincludes=org.apache.cxf (reactor-wide) — all 10 affected modules resolve
  3.6.12.
• mvn clean install -pl component-server-parent/component-server -am — full existing suite
  (183 tests), 0 failures/errors.
• Full reactor mvn install -DskipTests (47 modules) — BUILD SUCCESS.
• 3 pre-existing, CXF-unrelated flaky/environment test failures reproduced identically on master
  (out of scope — see review comment for detail).

Out of scope (explicitly, per the approved plan):

• connectors-se / connectors-ee / cloud-components — not touched, even though a quick grep
  shows some of those repos also declare their own direct org.apache.cxf dependencies,
  independent of this repo's cxf.version property. Flagged as an out-of-scope observation only;
  no action taken here.
• CXF 4.x migration (javax → jakarta namespace change) — materially larger change, not required
  to remediate this CVE.
• New test authoring — this is a version-bump-only change fully covered by the existing suite plus
  the reactor-wide build check.

Review history (this session)

• Scope & Design Review — Round 1: APPROVED, 1 Minor (non-blocking, pre-existing
  test-coverage gap on Github.java's optional-feature load path, not introduced by this change).
• Compliance Check: 0 Critical, 0 Warning, 1 Info (pre-existing Sonar S2221 bare-Exception
  catch on the touched line, pre-dates this change, out of scope to fix per scope discipline).

Full findings posted as separate PR comments below.

AI contribution metrics

• Code Generation % (this PR): 100% (4/4 changed lines from the AI-tagged commit)
• Code Generation % (ticket-wide cumulative): 100%
• Technical Design % (ticket-wide cumulative): ~3% word-overlap between the reconstructed
  original AI draft and the Dev-approved final plan — likely understated: the original draft
  was reconstructed as a summary (not preserved verbatim), and the core fix approach (single
  cxf.version property bump) was retained unchanged across the revision; only the verification
  scope was widened per Dev's correction (1 module → 10 modules). Treat this figure as a
  conservative lower bound; see step-3-plan-revision.md for the full caveat.

AI generated code

https://internal.qlik.dev/general/ways-of-working/code-reviews/#guidelines-for-ai-generated-code

• this PR has been written with the help of GitHub Copilot or another generative AI tool

[undx]

QTDI-3340 — Step 6A Scope & Design Review (critique-implementation)

Round 1 — Findings

Target list (from git diff master...HEAD --stat):

File	Type	Change
pom.xml	config (property)	cxf.version 3.5.11 → 3.6.12
documentation/src/main/java/org/talend/runtime/documentation/Github.java	source, modification	widen catch (Exception e) → catch (Exception | NoClassDefFoundError e)

Both files read in full; no test file was added or modified (see Test quality below).

Adversarial checklist

Logic & correctness

• No null dereference introduced — change is a version-property bump and a multi-catch widening; no new branching logic.
• Multi-catch Exception | NoClassDefFoundError is syntactically and semantically correct — NoClassDefFoundError is an Error, disjoint from Exception, both handled identically (log-free "not critical" swallow), consistent with Java multi-catch rules.
• No shared mutable state, no concurrency introduced.
• Property-only change — no code path branches on cxf.version directly; propagation to all 10 modules verified via mvn dependency:tree -Dincludes=org.apache.cxf at reactor root (per step-5-build.md), and independently re-confirmed here via grep -rn "cxf.version" --include=pom.xml . — every ${cxf.version} reference across pom.xml, documentation/pom.xml, and component-server-parent/component-server/pom.xml resolves through the single root property; no module pins its own override that would silently stay on 3.5.11.

External system assumptions

• The GZIPFeature load is guarded as best-effort/optional (comment: "not critical") — it does not assume the class is always present, so widening the catch does not introduce a new external-system assumption, it corrects one that the CXF upgrade invalidated (previously cxf-rt-frontend-jaxrs transitively pulled jakarta.xml.ws-api supplying the class graph needed to load GZIPFeature; 3.6.x drops that transitive pull).
• Confirmed via grep -rn "NoClassDefFoundError" --include=*.java . that this exact multi-catch idiom (Exception | NoClassDefFoundError) already exists at ComponentServerConfiguration.java:213 (ComponentServerConfiguration#init, guarding an analogous optional CXF LoggingFeature/GZIPFeature-style reflective class load) — the fix reuses an established, reviewed idiom rather than inventing a new error-handling pattern.
• No connection lifecycle / retry / timeout logic touched.

Design

• Simplest possible fix for the regression — a one-line catch widening, no new abstraction, no defensive rewrite of surrounding code.
• No hidden coupling introduced. Verified (via grep -rn "GZIPFeature") that only Github.java and ComponentServerConfiguration.java load CXF Feature classes reflectively in the whole reactor — the fix is scoped to the one file actually broken by the bump, not applied speculatively elsewhere.
• Scope-discipline check (core-rules.md §4): the Github.java catch-widening is a fix to a regression caused by the approved change itself (CXF 3.6.x no longer transitively supplies jakarta.xml.ws-api), not an unrelated adjacent issue — it is in scope as a necessary consequence of the approved plan, consistent with step-3-plan.md's explicit call-out of Github.java's direct CXF client usage as a residual risk area for this exact module. Correctly not deferred to a separate ticket.
• No undocumented option interactions — none of the changed lines are user-facing configuration.

Test quality

• → Finding fix: fix build issues for windows os #1 (Minor): no automated test exists (before or after this change) for Github.java's load() method or this catch branch specifically — confirmed via find documentation -path "*/test/*" -iname "*.java" | xargs grep -l Github (no results). A regression here would only be caught by the full reactor build's doc-generation execution (which the approved test strategy in step-3-plan.md already designates as sufficient coverage for this module, since it has no bespoke CXF test suite). Not a Blocker/Major: this is pre-existing test posture for the class, not a gap introduced by this change, and the risk surface (a try/swallow around a purely optional compression feature) is low-severity by construction — worst case on a future regression is loss of gzip compression, not a functional break.
• Failure path (the one this change touches) is now actually exercised — the reactor build previously failed here before the fix (confirmed in step-5-build.md), so the fix's correctness was validated against a real, reproduced failure, not just reasoned about.

Security

• No user input reaches a dangerous sink in either changed line.
• cxf.version bump is itself the security fix (CVE-2026-50645 remediation) — no new insecure default introduced; multi-catch does not swallow or hide the security-relevant path (unrelated optional compression feature loading, not the vulnerable attachment-parsing code path).
• No credentials/PII touched by either diff line.

Findings table

#	Severity	File	Description	Suggested Fix
1	MINOR	documentation/src/main/java/org/talend/runtime/documentation/Github.java	No automated test exercises the GZIPFeature load/catch branch (pre-existing condition for this class, not introduced by this change)	Optional follow-up, out of this ticket's scope: a narrow unit test forcing NoClassDefFoundError via a stub classloader, if the team wants direct coverage of this optional-feature path independent of the full reactor build

Approval gate: APPROVED — no Blocker or Major findings. 1 Minor noted (non-blocking, pre-existing test-coverage gap unrelated to this change's correctness).

---

Final verdict

APPROVED at Round 1. No further rounds required. The 1 Minor finding is carried into the PR description per the round-limit table in 04_implement.md Step 6A (noted, non-blocking).

---

Signed: Claude Sonnet 4.5

[undx]

QTDI-3340 — Step 6B Compliance Check (review-changes)

🔍 Code Review — QTDI-3340

Reviewed 2 files changed on branch undx/QTDI-3340_bump_cxf_version (base: master, diff via git diff master...HEAD).

File checklist

[x] pom.xml
[x] documentation/src/main/java/org/talend/runtime/documentation/Github.java

Step 2 — Per-file review

✅ Reviewed: pom.xml — 0 findings

• Single-property change (cxf.version 3.5.11 → 3.6.12), no inline version duplication introduced (java-dependencies-and-build.md — "all dependency versions are declared in the parent POM <dependencyManagement>, never inline"). Confirmed via grep -rn "cxf.version" --include=pom.xml . that every consumer (pom.xml, documentation/pom.xml, component-server-parent/component-server/pom.xml) references ${cxf.version} — no module overrides the property inline.
• No new dependency added (existing managed artifacts, version bump only) — team-review requirement for new dependencies (java-dependencies-and-build.md) does not apply.
• Not a SNAPSHOT version — 3.6.12 is a release version.
• Formatting: XML-only change, single line, no Spotless applicability (Spotless governs Java sources).

✅ Reviewed: documentation/src/main/java/org/talend/runtime/documentation/Github.java — 1 finding (Info, pre-existing/out of scope)

• mvn -pl documentation spotless:check run — BUILD SUCCESS, no formatting violations.
• No wildcard imports introduced (imports untouched by this diff).
• Multi-catch syntax catch (final Exception | NoClassDefFoundError e) is valid Java and mirrors the established repo-wide idiom at ComponentServerConfiguration.java:213 (catch (final Exception | NoClassDefFoundError e)), so no new pattern is introduced.
• No logging added/removed in the touched line; the pre-existing "not critical" empty-body comment is unchanged.
• Finding: java-exception-handling.md requires catching the most specific exception type, "never Exception or Throwable" (Sonar S2221). The touched line still catches bare Exception (catch (final Exception | NoClassDefFoundError e)) — this pre-dates this change (the original line was already catch (final Exception e) on master) and is not introduced or worsened by this diff, which only adds NoClassDefFoundError to the multi-catch. Per core-rules.md §4 (scope discipline) and the repo's "don't propagate complexity" guidance, this pre-existing S2221 violation is not fixed here — flagged as Info for visibility only, not a blocker, since fixing it would require identifying every checked/unchecked exception ClientBuilder/Class.loadClass/Thread.currentThread().getContextClassLoader() can throw, which is out of this ticket's approved scope (CVE remediation + the regression it directly caused).

Findings

File	Line	Severity	Finding	Rule
documentation/.../Github.java	79	ℹ️ Info	Catch clause still includes bare Exception (S2221) — pre-existing on master, not introduced/worsened by this diff; out of scope to fix per core-rules.md §4	java-exception-handling.md / Sonar S2221

No Critical or Warning findings.

Summary

Severity	Count
🔴 Critical	0
⚠️ Warning	0
ℹ️ Info	1

Files with no findings

• pom.xml

---

Exhaustive local review — all 2 changed files reviewed. Generated by AI; findings should be validated by a human reviewer.

Verdict

No Critical findings — no fix/re-verify loop required. Compliance check PASSES. The single Info finding is carried into the PR description (non-blocking, pre-existing).

---

Signed: Claude Sonnet 4.5

[Copilot]

Pull request overview

Updates the reactor’s Apache CXF baseline to remediate CVE-2026-50645, and adjusts optional CXF feature registration in the documentation generator to tolerate CXF 3.6.x classpath changes.

Changes:

• Bump root Maven property cxf.version from 3.5.11 to 3.6.12.
• Broaden the Github.java optional CXF GZIPFeature reflective load guard to also catch NoClassDefFoundError.
• Document CXF bump behavior/lessons learned in repository-knowledge.md.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
repository-knowledge.md	Adds repo knowledge about CXF version bump mechanics and the reflective feature-load pitfall.
pom.xml	Updates cxf.version to 3.6.12.
documentation/src/main/java/org/talend/runtime/documentation/Github.java	Makes optional CXF feature registration resilient to NoClassDefFoundError.

Suppressed comments (1)

documentation/src/main/java/org/talend/runtime/documentation/Github.java:81

• This catch now intentionally swallows NoClassDefFoundError as well as Exception, but it does so silently. Adding at least a debug-level log would make classpath/CXF mismatches diagnosable without changing the non-critical behavior.

        } catch (final Exception | NoClassDefFoundError e) {
            // not critical
        }

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[wwang-talend]

jenkins build fail

[undx]

jenkins build fail

Don't know why automation launched that TEST release build ????

[undx]

Review round N — summary

Comment	Class	Action
PR issue comment (2026-09-01, wwang-talend) — "jenkins build fail" + Jira comment #5 (2026-09-01)	Dropped — resolved	Dev confirmed QA already handled this; no action taken this round
Review thread on repository-knowledge.md (2026-09-01, ozhelezniak-talend) — disputed NoClassDefFoundError framing	Code fix (knowledge-file correction)	Fixed in f8e7a0984234 — removed the inaccurate section; replied to the thread

Fixes pushed: f8e7a0984234 — chore(QTDI-3340): correct repository-knowledge.md NoClassDefFoundError note
Pending clarifications: none
Rebase: no — master had not moved since the last push

Round summary generated by AI. Please resolve threads after verifying the fixes.

---

Signed: Claude Sonnet 4.5

[ozhelezniak-talend]

approved

[sonar-rnd]

Quality Gate passed

Issues

• 0 New Issues
• 0 Fixed Issues
• 0 Accepted Issues

Measures

• 0 Security Hotspots
• No data about coverage (63.30% Estimated after merge)
• 0.00% Duplicated Code (1.40% Estimated after merge)

Project ID: org.talend.sdk.component:component-runtime

View in SonarQube