Check the status of CVEs. Learn More.
php2shell patches (CVE-2026-109618 and CVE-2026-109619) for EOL PHP are out now. With sales replies slower than usual due to high demand, the fastest route to patched packages is to buy ELS for Runtimes online (opens in new tab). | Read the patch FAQ
This CVE has been resolved by the TuxCare team and
a patch has been delivered to ELS for Spring® users.
Spring® Boot is a framework built on top of the Spring® Framework that simplifies the development of standalone, production-ready Spring® applications. It eliminates much of the boilerplate configuration required by traditional Spring® apps by offering auto-configuration, opinionated defaults, and embedded servers.
Spring® Boot Loader is a component of Spring® Boot responsible for launching Spring® Boot applications packaged as executable JARs or WARs. It enables developers to run their apps using java -jar without needing an external application server or classpath setup.
Authentication Bypass by Spoofing is an attack-focused weakness caused by incorrectly implemented authentication schemes that are subject to spoofing attacks. It can allow an attacker to access resources which are not otherwise accessible without proper authentication.
Improper Verification of Cryptographic Signature takes place when the product does not verify, or incorrectly verifies, the cryptographic signature for data. An attacker could gain access to sensitive data and possibly execute unauthorized code.
CVE-2024-38807 is a medium-severity vulnerability identified in Spring® Boot’s spring-boot-loader and spring-boot-loader-classic components. Specifically, applications that utilize these components and implement custom code for signature verification of nested JAR files may be susceptible to signature forgery. This means that content appearing to be signed by one entity could, in reality, have been signed by another, potentially allowing malicious code to be executed under the guise of trusted content.
This issue affects multiple versions of:
org.springframework.boot » spring-boot-loader package,
org.springframework.boot » spring-boot-loader-classic package.
| Vulnerability Dossier | |
| CVE ID | CVE-2024-38807 |
| Severity | Medium: 6.3 |
| CWE-ID and name | CWE-290: Authentication Bypass by Spoofing
CWE-347: Improper Verification of Cryptographic Signature |
| Affected project | Spring® Boot |
| Affected packages | spring-boot-loader
spring-boot-loader-classic |
| Affected versions | <2.7.0;2.7.21>, <3.0.0;3.0.16>, <3.1.0;3.1.12>, <3.2.0;3.2.8>, <3.3.0;3.3.2> |
| NVD Published date | 23rd of August 2024 |
| TuxCare fix date | 4th of February 2025 |
| TuxCare fixed version | 2.7.18.tuxcare.4 |
https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-loader
https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-loader-classic
Spring® Boot applications packaged with the Spring® Boot Loader use a custom class loader to launch applications from a “fat JAR” (i.e., with all dependencies included). This JAR includes nested JARs within /BOOT-INF/lib.
The vulnerability lies in how Java’s signature verification mechanism is handled for these nested JARs. If an application tries to verify the digital signature of a nested JAR using standard JDK APIs, the verification might incorrectly succeed, even if the nested JAR:
This is because the Spring® Boot Loader does not fully preserve the signed JAR’s verification context when extracting and loading nested JARs.
This doesn’t affect most Spring® Boot users unless they explicitly implement custom digital signature validation logic for nested JARs.
Spring® Boot packages applications into self-contained JARs using spring-boot-loader, which includes:
If an organization tries to verify digital signatures on these nested JARs (e.g., to check for tampering or verify trust), the verification can silently pass even if:
Why? Because:
Spring® Boot 2.7.x is no longer supported by the open source community, as its End of Life date was on 2023-06-30. This simply means that versions from that date or before do not receive any updates to address this issue.
Users of the affected components should apply one of the following mitigations:
Do you need a fix for this vulnerability for any other Spring® Framework version? If so, please contact us, we are here to help you!