Skip to content

fix(deps): update maven#166

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate-main/maven
Open

fix(deps): update maven#166
renovate[bot] wants to merge 1 commit into
mainfrom
renovate-main/maven

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate Bot commented Apr 29, 2026 •
edited
Loading

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
org.projectlombok:lombok (source) 1.18.44 → 1.18.46 age adoption passing confidence
org.testcontainers:testcontainers (source) 2.0.4 → 2.0.5 age adoption passing confidence
org.springframework.cloud:spring-cloud-config-server (source) 5.0.2 → 5.0.3 age adoption passing confidence
org.postgresql:postgresql (source) 42.7.10 → 42.7.11 age adoption passing confidence
org.springframework.boot:spring-boot-starter-parent (source) 4.0.5 → 4.0.6 age adoption passing confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Spring Cloud Config vulnerable to Path Traversal

CVE-2026-40982 / GHSA-6g23-24mc-hx6x

More information

Details

Spring Cloud Config allows applications to serve arbitrary text and binary files through the spring-cloud-config-server module. A malicious user, or attacker, can send a request using a specially crafted URL that can lead to a directory traversal attack.
Spring Cloud Config 3.1.x: affected from 3.1.0 through 3.1.13 (inclusive); upgrade to 3.1.14 or greater (Enterprise Support Only). Spring Cloud Config 4.1.x: affected from 4.1.0 through 4.1.9 (inclusive); upgrade to 4.1.10 or greater (Enterprise Support Only). Spring Cloud Config 4.2.x: affected from 4.2.0 through 4.2.6 (inclusive); upgrade to 4.2.7 or greater (Enterprise Support Only). Spring Cloud Config 4.3.x: affected from 4.3.0 through 4.3.2 (inclusive); upgrade to 4.3.3 or greater. Spring Cloud Config 5.0.x: affected from 5.0.0 through 5.0.2 (inclusive); upgrade to 5.0.3 or greater.

Severity

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

References

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

Spring Cloud Config Server Susceptible To TOCTOU Attack

CVE-2026-41002 / GHSA-86wq-234q-r6wg

More information

Details

The base directory (spring.cloud.config.server.git.basedir) used by the Spring Cloud Config Server to clone Git repositories to is susceptible to time-of-check-time-of-use (TOCTOU) attacks.
Spring Cloud Config 3.1.x: affected from 3.1.0 through 3.1.13 (inclusive); upgrade to 3.1.14 or greater (Enterprise Support Only). Spring Cloud Config 4.1.x: affected from 4.1.0 through 4.1.9 (inclusive); upgrade to 4.1.10 or greater (Enterprise Support Only). Spring Cloud Config 4.2.x: affected from 4.2.0 through 4.2.6 (inclusive); upgrade to 4.2.7 or greater (Enterprise Support Only). Spring Cloud Config 4.3.x: affected from 4.3.0 through 4.3.2 (inclusive); upgrade to 4.3.3 or greater. Spring Cloud Config 5.0.x: affected from 5.0.0 through 5.0.2 (inclusive); upgrade to 5.0.3 or greater.

Severity

  • CVSS Score: 7.2 / 10 (High)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N

References

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

Spring Cloud Config Server Logged Sensitive Information

CVE-2026-41004 / GHSA-j6hh-h3cf-c2hf

More information

Details

When enabling trace logging in Spring Cloud Config Server sensitive information was placed in plain text in the logs.
Spring Cloud Config 3.1.x: affected from 3.1.0 through 3.1.13 (inclusive); upgrade to 3.1.14 or greater (Enterprise Support Only). Spring Cloud Config 4.1.x: affected from 4.1.0 through 4.1.9 (inclusive); upgrade to 4.1.10 or greater (Enterprise Support Only). Spring Cloud Config 4.2.x: affected from 4.2.0 through 4.2.6 (inclusive); upgrade to 4.2.7 or greater (Enterprise Support Only). Spring Cloud Config 4.3.x: affected from 4.3.0 through 4.3.2 (inclusive); upgrade to 4.3.3 or greater. Spring Cloud Config 5.0.x: affected from 5.0.0 through 5.0.2 (inclusive); upgrade to 5.0.3 or greater.

Severity

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

References

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

pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS

CVE-2026-42198 / GHSA-98qh-xjc8-98pq

More information

Details

Summary

pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.

Impact

A malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count.
With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail.
A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools.

In affected versions, loginTimeout did not fully mitigate this problem. When loginTimeout expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation.

This issue affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.

A user is vulnerable when all of the following are true:

  1. The connection uses SCRAM-SHA-256 authentication.
  2. The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint.
  3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.

In practice, that can happen in these situations:

  • the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control
  • the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources
  • the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised
  • the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server
  • an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, /etc/hosts, environment variables, or similar indirection
  • an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, sslmode lower than verify-full, or trusting a CA that signs hosts outside the operator's control)

The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.

Patches

The patch introduces a new connection property, scramMaxIterations, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.

Workarounds

Until a patched version of pgjdbc is deployed, the following measures reduce exposure:

  1. Only connect to trusted PostgreSQL servers whose identity is verified.
    Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.
    TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.

  2. Do not rely on loginTimeout as a complete mitigation on unpatched versions.
    On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.

  3. Avoid SCRAM on untrusted or interceptable connection paths.
    For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.

  4. Reduce blast radius operationally.
    Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.

  5. On trusted servers you control, keep SCRAM iteration counts at ordinary values.
    This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.

Severity

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

References

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

pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS

BIT-postgresql-jdbc-driver-2026-42198 / CVE-2026-42198 / GHSA-98qh-xjc8-98pq

More information

Details

Summary

pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.

Impact

A malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count.
With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail.
A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools.

In affected versions, loginTimeout did not fully mitigate this problem. When loginTimeout expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation.

This issue affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.

A user is vulnerable when all of the following are true:

  1. The connection uses SCRAM-SHA-256 authentication.
  2. The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint.
  3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.

In practice, that can happen in these situations:

  • the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control
  • the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources
  • the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised
  • the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server
  • an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, /etc/hosts, environment variables, or similar indirection
  • an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, sslmode lower than verify-full, or trusting a CA that signs hosts outside the operator's control)

The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.

Patches

The patch introduces a new connection property, scramMaxIterations, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.

Workarounds

Until a patched version of pgjdbc is deployed, the following measures reduce exposure:

  1. Only connect to trusted PostgreSQL servers whose identity is verified.
    Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.
    TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.

  2. Do not rely on loginTimeout as a complete mitigation on unpatched versions.
    On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.

  3. Avoid SCRAM on untrusted or interceptable connection paths.
    For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.

  4. Reduce blast radius operationally.
    Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.

  5. On trusted servers you control, keep SCRAM iteration counts at ordinary values.
    This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.

Severity

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

References

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

Release Notes

projectlombok/lombok (org.projectlombok:lombok)

v1.18.46

testcontainers/testcontainers-java (org.testcontainers:testcontainers)

v2.0.5

Compare Source

What's Changed

🚀 Features & Enhancements

🐛 Bug Fixes

📖 Documentation

🧹 Housekeeping

📦 Dependency updates

16 changes
spring-cloud/spring-cloud-config (org.springframework.cloud:spring-cloud-config-server)

v5.0.3: 5.0.3

Compare Source

🔒 Security

Addresses the following CVEs:

📔 Documentation
  • Fix 'occured' -> 'occurred' typo in JGitEnvironmentRepository clone-error log #​3217
❤️ Contributors

Thank you to all the contributors who worked on this release:

@​SAY-5 and @​dependabot[bot]

pgjdbc/pgjdbc (org.postgresql:postgresql)

v42.7.11

Security
  • fix: Limit SCRAM PBKDF2 iterations accepted from the server.
    pgjdbc was vulnerable to a client-side denial of service in SCRAM-SHA-256 authentication, where a malicious or compromised PostgreSQL server could specify an extremely large PBKDF2 iteration count, causing the client to consume unbounded CPU and potentially exhaust connection pools. The fix introduces a new scramMaxIterations connection property (defaulting to 100,000) to cap iteration counts before computation begins.
    See the Security Advisory for more detail.
    The following CVE-2026-42198 has been issued.
Added
  • feat: implement require_auth connection property, aligning with libpq behavior PR #​3895
Changed
  • chore: replace Appveyor CI with ikalnytskyi/action-setup-postgres PR #​3966
  • chore: upgrade Gradle to v9 PR #​3978
Fixed
  • fix: ensure extended protocol messages end with Sync message PR #​3728
  • fix: enable cursor-based fetching in extended protocol when transaction started via SQL command PR #​3996
  • fix: retry with SSL on IOException when sslMode=ALLOW PR #​3973
  • fix: make sure the driver honours connectTimeout when retrying the connection PR #​3968
  • fix: allow fallback to non-SSL connection when sslMode=prefer and sslResponseTimeout kicks in PR #​3968
  • fix: catch SecurityException from setContextClassLoader on ForkJoinPool workers PR #​3962
  • fix: use compareTo for LogSequenceNumber comparison to handle unsigned values correctly PR #​3961
  • fix: release COPY lock on IOException to prevent connection hang PR #​3957
  • fix: return jsonb as PGObject instead of String PR #​3956
  • fix: align SSL key file permission check with libpq PR #​3952
  • fix: guard connection closed flag with a reentrant lock to protect against concurrent close PR #​3905
spring-projects/spring-boot (org.springframework.boot:spring-boot-starter-parent)

v4.0.6

Compare Source

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

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

♻ Rebasing: Whenever PR is behind base branch, 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 renovate Bot requested a review from lis0x90 as a code owner April 29, 2026 11:34
@renovate renovate Bot added the group:maven label Apr 29, 2026
@renovate renovate Bot force-pushed the renovate-main/maven branch 6 times, most recently from daf436f to 5af92bd Compare May 7, 2026 12:35
@renovate renovate Bot force-pushed the renovate-main/maven branch from 5af92bd to c23b465 Compare May 21, 2026 23:44
@renovate renovate Bot added the security label May 21, 2026
@renovate renovate Bot changed the title chore(deps): update maven fix(deps): update maven May 21, 2026
@github-actions github-actions Bot added the bug Something isn't working label May 21, 2026
@sonarqubecloud
Copy link
Copy Markdown

sonarqubecloud Bot commented May 21, 2026

Quality Gate Passed 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@lis0x90 lis0x90 Awaiting requested review from lis0x90 lis0x90 is a code owner

Assignees

@lis0x90 lis0x90

Labels

branch:main bug Something isn't working group:maven manager:maven renovate:core security

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@lis0x90