chore: fix CVE-2025-67735 in 2.19

[pyek-bot]

Description

Modifying the netty dependency to rely on the version from core.

This was done earlier: #4338
This can be considered a backport

Check List

• New functionality includes testing.
• New functionality has been documented.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[brianf-aws]

Cool looks like OpenSearch core addressed this issue to

https://github.com/opensearch-project/OpenSearch/blob/880832d96934729075297f8dac21636f4a860529/gradle/libs.versions.toml#L37

[mingshl]

Unsupported class file major version 69

[pyek-bot]

Unsupported class file major version 69

Yes, I noticed that too. Looking into it.

[pyek-bot]

The error "Unsupported class file major version 69" indicates that Gradle is trying to compile code with Java 25, but Gradle 8.11.1 doesn't support Java 25 yet. Java class file major version 69 corresponds to Java 25.

The issue is that your CI is running with Java 25 (as shown in the output: "openjdk version '25.0.2'"), but Gradle 8.11.1 doesn't support it yet. Gradle 8.11.1 supports up to Java 23.

---

Looking at CI-workflow.yml, it shouldn't be trying to run Java 25 at all. Trying to see what went wrong.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 6680113)

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Gradle Upgrade The Gradle version is being upgraded from 8.11.1 to 9.2.0. This is a major version bump that could introduce breaking changes in build scripts, plugin compatibility, or task behavior. Verify that all existing build tasks, plugins, and configurations are compatible with Gradle 9.2.0 before merging. distributionSha256Sum=16f2b95838c1ddcf7242b1c39e7bbbb43c842f1f1a1a0dc4959b6d4d68abcac3 distributionUrl=https\://services.gradle.org/distributions/gradle-9.2.0-all.zip

[github-actions]

PR Code Suggestions ✨

Latest suggestions up to 6680113

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Verify checksum matches distribution file The distributionSha256Sum should be placed after distributionUrl to maintain consistency with the standard Gradle wrapper properties file format. More importantly, verify that the SHA256 checksum 16f2b95838c1ddcf7242b1c39e7bbbb43c842f1f1a1a0dc4959b6d4d68abcac3 actually matches the gradle-9.2.0-all.zip distribution, as a mismatch would cause build failures. The official Gradle 9.2.0 all-zip SHA256 should be confirmed against the Gradle release page. gradle/wrapper/gradle-wrapper.properties [3-4] +distributionUrl=https\://services.gradle.org/distributions/gradle-9.2.0-all.zip distributionSha256Sum=16f2b95838c1ddcf7242b1c39e7bbbb43c842f1f1a1a0dc4959b6d4d68abcac3 -distributionUrl=https\://services.gradle.org/distributions/gradle-9.2.0-all.zip Suggestion importance[1-10]: 5 __ Why: The suggestion to verify the SHA256 checksum is valid and important for build reliability, but the ordering of distributionSha256Sum vs distributionUrl is a minor style concern. The core value is in verifying the checksum correctness, which is a legitimate concern but requires external verification rather than a code change.	Low

---

Previous suggestions

Suggestions up to commit 95524b8

Category	Suggestion	Impact
Possible issue	Verify checksum matches distribution variant The distributionSha256Sum should be placed after distributionUrl to maintain conventional ordering and match the standard Gradle wrapper format. More critically, verify that the SHA256 checksum 16f2b95838c1ddcf7242b1c39e7bbbb43c842f1f1a1a0dc4959b6d4d68abcac3 actually corresponds to gradle-9.2.0-all.zip (not the -bin.zip variant), as a mismatch would cause build failures or a security bypass. gradle/wrapper/gradle-wrapper.properties [3-4] +distributionUrl=https\://services.gradle.org/distributions/gradle-9.2.0-all.zip distributionSha256Sum=16f2b95838c1ddcf7242b1c39e7bbbb43c842f1f1a1a0dc4959b6d4d68abcac3 -distributionUrl=https\://services.gradle.org/distributions/gradle-9.2.0-all.zip Suggestion importance[1-10]: 5 __ Why: The suggestion to reorder distributionSha256Sum after distributionUrl is a minor style improvement, and the verification of the SHA256 checksum against gradle-9.2.0-all.zip is a valid concern. However, the ordering of these properties doesn't affect functionality, and the checksum verification is more of a manual check request than a code fix.	Low

Suggestions up to commit a24986e

Category	Suggestion	Impact
Possible issue	Fix inconsistent shell variable expansion The $JAVA_HOME in the double-quoted string is expanded by the outer shell (root's environment) before being passed to su, which is the intended behavior. However, the backtick-based command substitutions for AWS secrets are escaped with </code> to defer evaluation to the inner shell. This inconsistency means JAVA_HOME must be set in root's environment. Verify that $JAVA_HOME is reliably set in the runner's root environment, or escape it as $JAVA_HOME to resolve it in the user-1000 shell context instead. .github/workflows/CI-workflow.yml [80-82] -su `id -un 1000` -c "export JAVA_HOME=$JAVA_HOME && export PATH=\$JAVA_HOME/bin:\$PATH && whoami && java -version && +su `id -un 1000` -c "export JAVA_HOME=\$JAVA_HOME && export PATH=\$JAVA_HOME/bin:\$PATH && whoami && java -version && export OPENAI_KEY=\`aws secretsmanager get-secret-value --secret-id github_openai_key --query SecretString --output text\` && export COHERE_KEY=\`aws secretsmanager get-secret-value --secret-id github_cohere_key --query SecretString --output text\` && Suggestion importance[1-10]: 6 __ Why: This is a valid observation about the inconsistency between $JAVA_HOME being expanded by the outer shell while AWS secret commands are deferred to the inner shell. Escaping $JAVA_HOME as \$JAVA_HOME would make it resolve in the user-1000 shell context, which is more consistent and potentially more reliable if JAVA_HOME is set for that user rather than root.	Low
Security	Ensure secrets are masked before exposure The masking commands use echo '::add-mask::'$VAR which concatenates the literal string with the variable value. However, since the variable is expanded by the outer shell before being passed to su -c, the secret values may be exposed in the process list or logs before masking takes effect. Consider fetching and masking the secrets in the outer shell context first, then passing them as environment variables to the su command. .github/workflows/CI-workflow.yml [83-84] -echo '::add-mask::'\$OPENAI_KEY && -echo '::add-mask::'\$COHERE_KEY && +echo "::add-mask::$OPENAI_KEY" && +echo "::add-mask::$COHERE_KEY" && Suggestion importance[1-10]: 5 __ Why: The suggestion raises a valid concern about when masking takes effect relative to secret retrieval. However, the improved_code actually contradicts the suggestion's own advice - it uses double quotes which would expand $OPENAI_KEY in the outer shell context, but the variables are defined inside the su -c inner shell, so they wouldn't be available in the outer shell at all. The current approach with single-quoted prefix and escaped variable is actually more appropriate for this context.	Low

[pyek-bot]

The CI build was failing because the Docker container's default Java 25 was being used instead of the intended matrix Java versions (11/17/21). While the setup-java action correctly installed the matrix Java version and set JAVA_HOME, the subsequent su command that switches to user 1000 starts a new shell that doesn't inherit environment variables. The fix explicitly passes JAVA_HOME through the su command by adding export JAVA_HOME=$JAVA_HOME && export PATH=$JAVA_HOME/bin:$PATH at the start, and changes the command from single to double quotes (with proper escaping) to allow the parent shell's $JAVA_HOME to be expanded and preserved for user 1000, ensuring the correct Java version is used instead of the unsupported Java 25.

[mingshl]

@pyek-bot the change of the CI will not take effect on this PR's CI.

I will recommend raise a seperate PR to fix the CI issue first, then rebase the change in this PR, we can know the updated CI works, and the CI can see if it passes, you will be more confident in this CVE fixes

[github-actions]

Persistent review updated to latest commit 95524b8

[github-actions]

PR Code Analyzer ❗

AI-powered 'Code-Diff-Analyzer' found issues on commit 6680113.

Path	Line	Severity	Description
gradle/wrapper/gradle-wrapper.properties	4	medium	Gradle wrapper updated to 9.2.0-all.zip with a new SHA256 hash. The switch from '-bin' to '-all' distribution and the new checksum should be independently verified against the official Gradle release page (https://gradle.org/release-checksums/) to confirm no tampering. A mismatched or attacker-supplied SHA256 in the wrapper is a known supply chain attack vector.
client/build.gradle	10	low	Shadow Jar plugin migrated from 'com.github.johnrengelman.shadow' to 'com.gradleup.shadow' across multiple build files. This is the legitimate successor project (transferred to the GradleUp community org), but the publisher change is worth confirming against the official plugin portal to rule out typosquatting.

The table above displays the top 10 most important findings.

Total: 2 | Critical: 0 | High: 0 | Medium: 1 | Low: 1

---

Pull Requests Author(s): Please update your Pull Request according to the report above.

Repository Maintainer(s): You can bypass diff analyzer by adding label skip-diff-analyzer after reviewing the changes carefully, then re-run failed actions. To re-enable the analyzer, remove the label, then re-run all actions.

---

⚠️ Note: The Code-Diff-Analyzer helps protect against potentially harmful code patterns. Please ensure you have thoroughly reviewed the changes beforehand.

Thanks.

[github-actions]

Persistent review updated to latest commit 6680113

[pyek-bot]

Fixed here: #4694