[Snyk] Fix for 3 vulnerabilities

[bogarin]

Snyk has created this PR to fix 3 vulnerabilities in the maven dependencies of this project.

Snyk changed the following file(s):

• pom.xml

Vulnerabilities that will be fixed with an upgrade:

	Issue	Score	Upgrade
	Allocation of Resources Without Limits or Throttling SNYK-JAVA-IOUNDERTOW-15053841	635	Major version upgrade No Path Found No Known Exploit
	Improper Validation of Syntactic Correctness of Input SNYK-JAVA-IOUNDERTOW-14908846	520	Major version upgrade No Path Found No Known Exploit
	External Initialization of Trusted Variables or Data Stores SNYK-JAVA-CHQOSLOGBACK-15062482	290	ch.qos.logback:logback-classic: 1.2.6 -> 1.5.25 ch.qos.logback:logback-core: 1.2.6 -> 1.5.25 No Path Found No Known Exploit

Vulnerabilities that could not be fixed

• Upgrade:
  • Could not upgrade org.springframework.boot:spring-boot-starter-undertow@2.0.5.RELEASE to org.springframework.boot:spring-boot-starter-undertow@3.5.10; Reason could not apply upgrade, dependency is managed externally ; Location: https://maven-central.storage-download.googleapis.com/maven2/io/github/jhipster/jhipster-parent/2.0.25/jhipster-parent-2.0.25.pom

---

Important

• Check the changes in this PR to ensure they won't cause issues with your project.
• Max score is 1000. Note that the real score may have changed since the PR was raised.
• This PR was automatically created by Snyk using the credentials of a real user.

---

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

---

Learn how to fix vulnerabilities with free interactive lessons:

🦉 Allocation of Resources Without Limits or Throttling

[Copilot]

Pull request overview

This PR attempts to fix 3 security vulnerabilities identified by Snyk by upgrading dependencies. The main change is upgrading Logback from 1.2.6 to 1.5.25 to address a low severity vulnerability (SNYK-JAVA-CHQOSLOGBACK-15062482). The PR notes that two high/medium severity Undertow vulnerabilities cannot be fixed due to external dependency management constraints.

Changes:

• Upgraded Logback from version 1.2.6 to 1.5.25 to address security vulnerability
• Minor XML formatting improvements (converting empty tags to self-closing format)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The upgrade from Logback 1.2.6 to 1.5.25 introduces a significant compatibility concern. Logback 1.5.x requires SLF4J 2.0.x or higher, but this project is using SLF4J 1.7.32. According to Logback's official compatibility documentation, Logback 1.5.x is designed to work with SLF4J 2.0.x API. Using Logback 1.5.25 with SLF4J 1.7.32 may lead to runtime errors or unexpected behavior.

To properly fix the security vulnerability, you should either:

1. Upgrade to Logback 1.2.13 (the latest 1.2.x version) which is compatible with SLF4J 1.7.x and addresses the security issue, or
2. Upgrade both Logback to 1.5.25 AND SLF4J to 2.0.x (e.g., 2.0.16) to maintain compatibility.

The first option (Logback 1.2.13) would be less risky as it avoids potential breaking changes from the SLF4J major version upgrade.

Suggested change

	<logback.version>1.5.25</logback.version>
	<logback.version>1.2.13</logback.version>

[Copilot]

This formatting change from opening and closing tags to a self-closing tag is functionally equivalent and valid XML. While this is a stylistic improvement, it appears unrelated to the security vulnerability fixes described in the PR. Consider whether these formatting changes should be in a separate PR focused on code cleanup, rather than mixed with security fixes. This helps maintain clear PR history and easier rollback if needed.

[Copilot]

This formatting change from opening and closing tags to a self-closing tag is functionally equivalent and valid XML. While this is a stylistic improvement, it appears unrelated to the security vulnerability fixes described in the PR. Consider whether these formatting changes should be in a separate PR focused on code cleanup, rather than mixed with security fixes. This helps maintain clear PR history and easier rollback if needed.

Suggested change

	<ignore/>
	<ignore></ignore>