Skip to content

chore(deps): update all non-major dependencies - #390

Open
renovate-bot wants to merge 1 commit into
GoogleCloudPlatform:mainfrom
renovate-bot:renovate/all-minor-patch
Open

chore(deps): update all non-major dependencies#390
renovate-bot wants to merge 1 commit into
GoogleCloudPlatform:mainfrom
renovate-bot:renovate/all-minor-patch

Conversation

@renovate-bot

@renovate-bot renovate-bot commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Type Update Change Age Adoption Passing Confidence
actions/checkout action minor v6.0.2v6.1.0 age adoption passing confidence
actions/setup-go action minor v6.4.0v6.5.0 age adoption passing confidence
actions/setup-java action minor v5.2.0v5.6.0 age adoption passing confidence
github/codeql-action action minor v4.35.1v4.37.3 age adoption passing confidence
ossf/scorecard-action action patch v2.4.3v2.4.4 age adoption passing confidence
step-security/harden-runner action minor v2.17.0v2.20.0 age adoption passing confidence
org.apache.maven.plugins:maven-enforcer-plugin (source) build minor 3.5.03.6.3 age adoption passing confidence
org.apache.maven.plugins:maven-release-plugin (source) build minor 3.0.13.3.1 age adoption passing confidence
org.apache.maven.plugins:maven-plugin-plugin (source) build minor 3.10.23.15.2 age adoption passing confidence
org.apache.maven.plugins:maven-shade-plugin (source) build minor 3.5.33.6.2 age adoption passing confidence
org.apache.maven.plugins:maven-dependency-plugin (source) build minor 3.6.13.11.0 age adoption passing confidence
org.apache.maven.plugins:maven-jar-plugin (source) build patch 3.5.03.5.1 age adoption passing confidence
org.apache.maven.plugins:maven-jar-plugin (source) build minor 3.3.03.5.1 age adoption passing confidence
org.apache.maven.plugins:maven-surefire-plugin (source) build minor 3.1.23.5.6 age adoption passing confidence
org.apache.maven.plugins:maven-compiler-plugin (source) build minor 3.11.03.15.0 age adoption passing confidence
org.apache.maven.plugins:maven-resources-plugin (source) build minor 3.3.13.5.0 age adoption passing confidence
org.apache.maven.plugins:maven-clean-plugin (source) build minor 3.2.03.5.0 age adoption passing confidence
org.apache.maven.plugins:maven-deploy-plugin (source) build patch 3.1.13.1.4 age adoption passing confidence
org.apache.maven.plugins:maven-install-plugin (source) build patch 3.1.23.1.4 age adoption passing confidence
org.slf4j:slf4j-jdk14 (source) compile patch 2.0.172.0.18 age adoption passing confidence
io.cloudevents:cloudevents-api (source) compile minor 4.0.24.1.1 age adoption passing confidence
com.google.cloud.functions.invoker:java-function-invoker compile patch 2.0.12.0.2 age adoption passing confidence
com.google.code.gson:gson compile minor 2.13.22.14.0 age adoption passing confidence
com.google.cloud.functions:functions-framework-api compile patch 2.0.12.0.2 age adoption passing confidence
org.apache.maven:maven-core (source) provided patch 3.9.143.9.16 age adoption passing confidence
org.apache.maven:maven-plugin-api (source) provided patch 3.9.143.9.16 age adoption passing confidence
com.google.cloud.functions:functions-framework-api compile patch 2.0.02.0.2 age adoption passing confidence
com.google.cloud.functions:function-maven-plugin build patch 1.0.01.0.2 age adoption passing confidence
io.cloudevents:cloudevents-json-jackson (source) compile minor 4.0.14.1.1 age adoption passing confidence
io.cloudevents:cloudevents-core (source) compile minor 4.0.14.1.1 age adoption passing confidence
com.google.guava:guava compile minor 33.5.0-jre33.6.0-jre age adoption passing confidence
org.eclipse.jetty:jetty-client (source) test patch 12.1.812.1.11 age adoption passing confidence
org.eclipse.jetty:jetty-server (source) compile patch 12.1.812.1.10 age adoption passing confidence
io.cloudevents:cloudevents-http-basic (source) compile minor 4.0.14.1.1 age adoption passing confidence

Warning

Some dependencies could not be looked up. Check the warning logs for more information.


Eclipse Jetty: Cross-Request Leakage for trailers on HTTP/1.1 keep-alive connections

CVE-2026-10051 / GHSA-f4v5-65jj-pcr2

More information

Details

Description

FINDING — MEDIUM (HTTP/1.1 keep-alive connections with trailers)
HttpConnection._trailers Cross-Request Leakage (Never Reset Between Requests)

Location:
jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/
HttpConnection.java:107, 1157-1161, 1170

Detail:
_trailers (line 107) is a connection-scoped HttpFields.Mutable field.
parsedTrailer() (line 1157) populates it when request N carries HTTP trailers.
messageComplete() (line 1170) checks "if (_trailers != null)" — evaluates true
from request N's data — and stamps it onto request N+1.

Grep confirms: ZERO occurrences of "_trailers = null" in entire HttpConnection.java.

Scenario:
Request N: POST /upload (trailers: X-Checksum: abc123)
Request N+1: GET /data (no trailers)
app: request.getTrailers() on N+1 → returns {X-Checksum: abc123} ← STALE

Application logic branching on getTrailers() != null produces incorrect behavior.
Not cross-connection (same keep-alive connection only).

More dangerous scenario: TOCTOU — trailer passes check, target swapped before use.

Workarounds

Do not rely on HTTP request trailers for security-sensitive logic, or disable persistent connections by closing the connection after each HTTP/1.1 request.

Severity

  • CVSS Score: 6.9 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Eclipse Jetty: HTTP Authority/Host mismatch

CVE-2026-6790 / GHSA-7p3p-8qv8-m2vh

More information

Details

Summary

Jetty currently accepts HTTP/2 and HTTP/3 requests where the regular
Host header and the pseudo-header :authority
do not match. As a result, the same request can carry two different host identities
through Jetty:

  • logic based on HttpURI / Request.getServerName(request) uses :authority
  • logic based on raw request headers continues to use Host

This creates a host/authority confusion condition that can break
security assumptions in higher layers.

Jetty already performs an explicit authority/Host consistency check on
the HTTP/1.1 path, but equivalent validation is missing on the HTTP/2
and HTTP/3 paths.

Security Impact

This issue is not inherently remote code execution, but it can become
security-relevant in deployments that rely on the request host for
security-sensitive decisions, including:

  • host-based access control
  • virtual host isolation
  • multi-tenant routing by hostname
  • login/logout/callback URL construction
  • reverse proxy and forwarded-header trust chains
  • auditing, cache keys, and absolute URL generation

Potential consequences include:

  • bypass of host-based ACLs
  • virtual host or tenant isolation failures
  • incorrect or attacker-influenced redirect/callback targets
  • inconsistent proxy/downstream interpretation of the original target host
  • misleading logs and audit records
Technical Root Cause
  1. On the HTTP/2 and HTTP/3 metadata builder paths:
  • :authority is parsed separately into authority/URI state
  • Host is preserved as a normal request header
  • the two values are not compared for consistency
  1. On the HTTP/2 and HTTP/3 server entry paths:
  • Jetty calls ComplianceUtils.verify(httpCompliance, requestMetaData, listener)
  • this verification does not enforce MISMATCHED_AUTHORITY
  1. On the HTTP/1.1 path:
  • Jetty explicitly checks whether authority and Host match
  • mismatches are rejected by default
Relevant Code Locations

HTTP/2 metadata builder:

  • jetty-core/jetty-http2/jetty-http2-hpack/src/main/java/org/eclipse/jetty/http2/hpack/internal/MetaDataBuilder.java

HTTP/3 metadata builder:

  • jetty-core/jetty-http3/jetty-http3-qpack/src/main/java/org/eclipse/jetty/http3/qpack/internal/metadata/MetaDataBuilder.java

HTTP/2 server entry:

  • jetty-core/jetty-http2/jetty-http2-server/src/main/java/org/eclipse/jetty/http2/server/internal/HttpStreamOverHTTP2.java

HTTP/3 server entry:

  • jetty-core/jetty-http3/jetty-http3-server/src/main/java/org/eclipse/jetty/http3/server/internal/HttpStreamOverHTTP3.java

Shared HTTP compliance verification:

  • jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/ComplianceUtils.java

HTTP/1.1 authority/Host consistency check:

  • jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/HttpConnection.java

Defined but not enforced on H2/H3:

  • jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/HttpCompliance.java
  • violation: MISMATCHED_AUTHORITY
Reproduction

I reproduced this on local Jetty 12.1.9-SNAPSHOT source.

Minimal reproduction steps:

  1. Start a Jetty HTTP/2 or HTTP/3 test server.
  2. Send a request with:
    • :authority = localhost:
    • Host = evil.example:
  3. In the request handler, inspect both:
    • Request.getServerName(request)
    • request.getHeaders().get(HttpHeader.HOST)
  4. Observe whether Jetty rejects the request or allows both values to remain visible.
    Observed result:
    • HTTP/2: request is accepted and returns 200
    • HTTP/3: request is accepted and returns 200
    • the server can observe both:
      • serverName=localhost
      • hostHeader=evil.example:

This shows that a single attacker-controlled request can preserve two conflicting host interpretations inside Jetty.

Tests Used

HTTP/2 rejection test:

  • org.eclipse.jetty.http2.tests.HTTP2Test#testRejectMismatchedHostHeaderAndAuthority

HTTP/2 exploitability test:

  • org.eclipse.jetty.http2.tests.HTTP2Test#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader

HTTP/3 rejection test:

  • org.eclipse.jetty.http3.tests.HandlerClientServerTest#testRejectMismatchedHostHeaderAndAuthority

HTTP/3 exploitability test:

  • org.eclipse.jetty.http3.tests.HandlerClientServerTest#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader

Observed behavior:

  • both rejection tests fail because Jetty returns 200 instead of 400
  • both exploitability tests pass, confirming that Jetty exposes different host values to different layers
Project-Internal Evidence of Real Impact

Examples:

  • jetty-openid uses Request.getServerName(request) to construct redirect URLs
  • jetty-ee11-proxy uses the raw Host header when building Forwarded

This indicates that the issue is not merely theoretical: Jetty’s own
ecosystem already contains code paths where different host sources are
used for different purposes.

Affected Version

Confirmed affected version:

  • 12.1.9-SNAPSHOT

Other versions may also be affected if they share the same HTTP/2 /
HTTP/3 request construction and compliance-validation logic. I have
not yet completed a historical version matrix and would recommend
confirming exact affected ranges from Jetty’s branch history.

Suggested Fix

Recommend adding HTTP/2 and HTTP/3 validation equivalent to the
existing HTTP/1.1 authority/Host consistency check:

  • if both :authority and regular Host are present
    • normalize and compare them
    • if they do not match, reject the request with 400 Bad Request
    • route the failure through the existing MISMATCHED_AUTHORITY compliance mechanism

Also adding explicit HTTP/2 and HTTP/3 regression coverage for this case.

Disclosure Status
  • not publicly disclosed
  • no public issue filed
  • shared only privately with the Jetty security contacts

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Release Notes

actions/checkout (actions/checkout)

v6.1.0

Compare Source

v6.0.3

Compare Source

actions/setup-go (actions/setup-go)

v6.5.0

Compare Source

actions/setup-java (actions/setup-java)

v5.6.0

Compare Source

What's Changed

Full Changelog: actions/setup-java@v5...v5.6.0

v5.5.0

Compare Source

v5.4.0

Compare Source

What's Changed
New Contributors

Full Changelog: actions/setup-java@v5...v5.4.0

v5.3.0

Compare Source

What's Changed
New Contributors

Full Changelog: actions/setup-java@v5...v5.3.0

github/codeql-action (github/codeql-action)

v4.37.3

Compare Source

No user facing changes.

v4.37.2

Compare Source

  • The new address format for the config-file input that was introduced in CodeQL Action 4.37.0 is now enabled by default. In addition to the format described there, the remote= prefix can now be used to explicitly indicate that the input refers to a remote file. All previous input formats continue to be accepted as well. #​4023
  • The CodeQL Action can now make use of configured private registries in Default Setup to retrieve CodeQL configuration files from remote repositories that require authentication. This will allow customers to store their CodeQL configuration in a single repository that can then be referenced by Default Setup workflows in other repositories. We expect to roll this and other, related changes out to everyone in July. #​4007

v4.37.1

Compare Source

  • Upcoming breaking change: Add a deprecation warning for customers using CodeQL version 2.20.6 and earlier. These versions of CodeQL were discontinued on 1 July 2026 alongside GitHub Enterprise Server 3.16, and will be unsupported by the next minor release of the CodeQL Action. #​3956
  • Update default CodeQL bundle version to 2.26.1. #​4019

v4.37.0

Compare Source

  • Update default CodeQL bundle version to 2.26.0. #​3995
  • In addition to the existing input format, the config-file input for the codeql-action/init step will soon support a new [owner/]repo[@​ref][:path] format. All components except the repository name are optional. If omitted, owner defaults to the same owner as the repository the analysis is running for, ref to main, and path to .github/codeql-action.yaml. Support for this format ships in this version of the CodeQL Action, but will only be enabled over the coming weeks. #​3973

v4.36.3

Compare Source

No user facing changes.

v4.36.2

Compare Source

  • Cache CodeQL CLI version information across Actions steps. #​3943
  • Reduce requests while waiting for analysis processing by using exponential backoff when polling SARIF processing status. #​3937
  • Update default CodeQL bundle version to 2.25.6. #​3948

v4.36.1

Compare Source

No user facing changes.

v4.36.0

Compare Source

  • Breaking change: Bump the minimum required CodeQL bundle version to 2.19.4. #​3894
  • Add support for SHA-256 Git object IDs. #​3893
  • Update default CodeQL bundle version to 2.25.5. #​3926

v4.35.5

Compare Source

  • We have improved how the JavaScript bundles for the CodeQL Action are generated to avoid duplication across bundles and reduce the size of the repository by around 70%. This should have no effect on the runtime behaviour of the CodeQL Action. #​3899
  • For performance and accuracy reasons, improved incremental analysis will now only be enabled on a pull request when diff-informed analysis is also enabled for that run. If diff-informed analysis is unavailable (for example, because the PR diff ranges could not be computed), the action will fall back to a full analysis. #​3791
  • If multiple inputs are provided for the GitHub-internal analysis-kinds input, only code-scanning will be enabled. The analysis-kinds input is experimental, for GitHub-internal use only, and may change without notice at any time. #​3892
  • Added an experimental change which, when running a Code Scanning analysis for a PR with improved incremental analysis enabled, prefers CodeQL CLI versions that have a cached overlay-base database for the configured languages. This speeds up analysis for a repository when there is not yet a cached overlay-base database for the latest CLI version. We expect to roll this change out to everyone in May. #​3880

[v4.35.4](

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • Between 12:00 AM and 03:59 AM, on day 1 of the month (* 0-3 1 * *)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate-bot
renovate-bot force-pushed the renovate/all-minor-patch branch 5 times, most recently from f730e3c to 424b360 Compare July 8, 2026 21:09
@renovate-bot
renovate-bot force-pushed the renovate/all-minor-patch branch 5 times, most recently from 385ccee to 8f23bb3 Compare July 16, 2026 18:58
@renovate-bot
renovate-bot force-pushed the renovate/all-minor-patch branch 8 times, most recently from 3ce1196 to adf4edc Compare July 24, 2026 21:30
@renovate-bot
renovate-bot force-pushed the renovate/all-minor-patch branch from adf4edc to 85f8670 Compare July 25, 2026 02:59
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.

1 participant