Bump reactor-netty from 1.2.18 to 1.3.6 and Netty to 4.2.15.Final

[Yavor16]

Description:

Migrate to the reactor-netty 1.3.x line by bumping reactor-netty from 1.2.18 to 1.3.6, and align the transitive Netty stack to 4.2.15.Final so the runtime is consistent with what reactor-netty 1.3.6 expects. The Netty override also picks up the fix for CVE-2026-42583 (Lz4FrameDecoder resource exhaustion).

What changed

• reactor-netty.version bumped 1.2.18 → 1.3.6.
• netty.version bumped 4.1.135.Final → 4.2.15.Final to match the Netty baseline required by reactor-netty 1.3.x and to pick up the CVE-2026-42583 fix.
• Added explicit dependencyManagement entries for reactor-netty-core and reactor-netty-http, pinned to ${reactor-netty.version}, so the split reactor-netty artifacts resolve to a single consistent version.

Notes for the reviewer

• reactor-netty 1.3.x sits on Netty 4.2.x; the two bumps are intentionally coupled and should land together to avoid a mixed 4.1/4.2 classpath.
• Follow-up under the linked ticket tracks the direct (off-heap) memory behaviour observed on Netty 4.2.x; this PR only performs the version alignment.
• Changelog references: reactor-netty https://github.com/reactor/reactor-netty/releases and Netty https://netty.io/news/.

Issue:

Jira: LMCROSSITXSADEPLOY-3410

[Yavor16]

MTA Quality Report — cloudfoundry/multiapps-controller PR #1874

Jira: No Jira key in PR description — OSS repo; ticket ID intentionally omitted per security boundary. The corresponding change is tracked in the proprietary xsa PR.
Backlog alignment: WARN (NOT_APPLICABLE)

• Implements Jira scope? unclear — No public Jira key to validate against; the pom-only reactor-netty bump is self-describing and internally consistent.
• Changes outside Jira scope? no — The diff is confined to the reactor-netty version bump and managed pins, with no unrelated changes.

---

Code Review

No code-review findings (confidence ≥ 80).

---

Security

No issues found.

The PR preserves the existing Netty 4.1.135.Final CVE-2026-42583 (Lz4FrameDecoder) mitigation, keeps the reactor-netty family version-aligned via the new managed pins (no mixed-version split), and touches no application code (no injection/auth/deserialization/SSRF/credential surfaces).

---

SonarCloud

Quality gate: UNKNOWN — the "Build and analyze" SonarCloud job is still in_progress at head SHA e2c5a4fb25743367037df5514d12cfcf3f562e2f, so no quality gate conclusion or per-line code annotations have posted yet.

No SonarCloud code annotations surfaced. The only check-runs annotation is a non-Sonar GitHub Actions infra warning (Node.js 20 deprecation on actions/cache, actions/checkout, actions/setup-java at .github:2). Consistent with a pom-only version bump where few/no new code findings are expected.

---

Dependency CVEs

✅ No new CVEs introduced by this PR (pre-existing CVEs in the dependency tree are not listed).

OWASP Dependency-Check 11.1.1, 12 modules per side. Head vs base (merge-base = current master tip) both have 91 distinct (CVE, artifact) pairs ≥ 7.0; net-new on head = 0 (confirmed two ways). Delta scanned: reactor-netty 1.2.18 → 1.3.6 plus new reactor-netty-core/http pins (all 1.3.6); netty stays 4.1.135.Final.

• Caveat 1: reactor-netty 1.3.6 JARs carry CRITICAL/HIGH findings in the raw report (CVE-2019-20444/20445, CVE-2023-44487, CVE-2026-4258x cluster), but these are CPE-mismatch false positives (core Netty CVEs mis-attributed onto the reactor-netty filename) and appear identically on head and base, so they cancel out — pre-existing report noise, not a regression.
• Caveat 2: online NVD delta update was disabled (no nvdApiKey; OSS Index 401); scans ran against a cached NVD DB dated ~2026-07-10 (~4 days old, recent enough to include July-2026 Netty CVEs).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Yavor16]

Automated code review by MTA Quality Agent — 1 finding(s).

[Yavor16]

Severity: IMPORTANT · Confidence: 82

The comment removing the direct-memory OOM workaround note is silent about whether the regression was actually fixed upstream in reactor-netty 1.3.x. The original comment <!--reactor netty 1.3.x uses direct memory leading to OOM errors--> was a deliberate guard against upgrading past 1.2.x. Upgrading to 1.3.6 without any reference to the upstream fix risks reintroducing OOM in production under heap-limited CF deployments. The PR description or a code comment should cite the upstream reactor-netty issue/commit that resolved the direct-memory problem, so future maintainers understand the constraint was intentionally lifted.

Evidence: <reactor-netty.version>1.3.6</reactor-netty.version>

Fix: Add an inline comment documenting that the direct-memory OOM issue tracked in the original comment was resolved upstream (cite the reactor-netty issue/release), e.g.:

Suggested change

	<reactor-netty.version>1.3.6</reactor-netty.version>
	<!-- reactor-netty 1.3.x direct-memory OOM (previously pinned to 1.2.x) resolved upstream; see reactor-netty#<issue> -->
	<reactor-netty.version>1.3.6</reactor-netty.version>

[Yavor16]

MTA Quality Report — cloudfoundry/multiapps-controller PR #1874

Jira: LMCROSSITXSADEPLOY-3410 — Migrate to reactory-netty 1.3.x
Backlog alignment: WARN

• Implements Jira scope? partial — The reactor-netty 1.2.18 → 1.3.6 and Netty 4.1.135.Final → 4.2.15.Final version migration is done; the direct (off-heap) memory investigation described in the ticket is explicitly deferred to a follow-up.
• Changes outside Jira scope? no — The diff is confined to pom.xml version bumps and the two new reactor-netty-core/reactor-netty-http managed pins, with no unrelated changes.

---

Code Review

1 finding(s): 1 posted inline.
See the inline review on the PR diff for posted findings.

---

Security

• [pom.xml:40] (MEDIUM, CWE-400 resource exhaustion / availability) — reactor-netty.version is bumped from 1.2.18 to 1.3.6, moving onto the exact 1.3.x line the removed comment warned about: reactor netty 1.3.x uses direct memory leading to OOM errors. Reintroducing a known direct-memory OOM risk is a denial-of-service concern for the controller. Fix: confirm the specific direct-memory OOM issue was resolved upstream in reactor-netty 1.3.6 (release notes / issue tracker) before merging; if not resolved, retain 1.2.18 or configure a direct-memory bound. The bumping author should document the verification in the PR.
• [pom.xml:42] (LOW) — netty.version jumps a minor line (4.1.135.Final → 4.2.15.Final). The CVE-2026-42583 override remains present and the version is newer, so the fix is not regressed, but a 4.1.x → 4.2.x jump can alter transitive behavior. No vulnerability introduced by the diff; flagging only so the CVE-fix intent is verified against the new line.

---

SonarCloud

Check	Status	Result	Annotations	Details
Build and analyze	in_progress	⏳ RUNNING	—	https://github.com/cloudfoundry/multiapps-controller/actions/runs/29337161337/job/87099199763

Quality gate: UNKNOWN (analysis still running)

The "Build and analyze" job (which includes SonarCloud analysis) has not completed yet — it is still in_progress. No quality gate conclusion or annotations are available at this time.

---

Dependency CVEs

✅ No new CVEs introduced by this PR (pre-existing CVEs in the dependency tree are not listed).

The PR bumps reactor-netty 1.2.18 → 1.3.6 and netty 4.1.135.Final → 4.2.15.Final. Both head and base report 13 high/critical CVEs (CVSS ≥ 7.0) — an identical set, so the diff is empty. The upgraded netty and reactor-netty artifacts carry no vulnerabilities in the OWASP database, and the netty-family CVE that is present (CVE-2026-33117 on the transitive azure-core-http-netty) exists unchanged on both sides and is therefore pre-existing, not introduced by this PR.