Hello team,
This might have been already be reported, and if it is, apologies, feel free to close, take this as me just wishing you a good day.
It seems there is a CVE on logback 1.4.11 from
[INFO] +- org.springframework.boot:spring-boot-starter-webflux:jar:3.2.0:compile
[INFO] | +- org.springframework.boot:spring-boot-starter:jar:3.2.0:compile
[INFO] | | +- org.springframework.boot:spring-boot:jar:3.2.0:compile
[INFO] | | | \- org.springframework:spring-context:jar:6.1.1:compile
[INFO] | | | +- org.springframework:spring-aop:jar:6.1.1:compile
[INFO] | | | \- org.springframework:spring-expression:jar:6.1.1:compile
[INFO] | | +- org.springframework.boot:spring-boot-starter-logging:jar:3.2.0:compile
[INFO] | | | +- ch.qos.logback:logback-classic:jar:1.4.11:compile
[INFO] | | | | \- ch.qos.logback:logback-core:jar:1.4.11:compile
Would be great if it can get bumped.
Thank you
Comment From: wilkinsona
We'll upgrade in due course. In the meantime, you can override the dependency version to meet your needs. It is also worth noting the conditions that are required in order to be exploitable:
This is only exploitable if logback receiver component is deployed
This is not the case by default in Spring Boot.
Comment From: patpatpat123
Thank you
Comment From: schaoukicoveo
We'll upgrade in due course. In the meantime, you can override the dependency version to meet your needs. It is also worth noting the conditions that are required in order to be exploitable:
This is only exploitable if logback receiver component is deployed
This is not the case by default in Spring Boot. @wilkinsona Sorry pretty knew in the spring boot environment but i wanted to know how can one check if logback receiver component is enabled
Comment From: wilkinsona
Check your logback.xml or logback-spring.xml configuration.
Comment From: schaoukicoveo
Thank you mate
Comment From: dogilvie
We'll upgrade in due course. In the meantime, you can override the dependency version to meet your needs. It is also worth noting the conditions that are required in order to be exploitable:
This is only exploitable if logback receiver component is deployed
This is not the case by default in Spring Boot.
Hi Andy, why does spring not just bump to the latest patch release (currently 1.4.14) in this case?
Attempted, but unit test failures?
I'm interested in the mindset behind the delay.
Comment From: bclozel
@dogilvie there is no delay. We usually run our dependency upgrade process a few days before the release to not miss any. Our next set of maintenance releases is scheduled on December 21, see https://github.com/spring-projects/spring-boot/milestones
Comment From: GeneralNitin
Hi, Can someone please share an example of how to exclude and include, because it is not working for me. :( Thanks, Nitin
Comment From: bclozel
@GeneralNitin you don't need to include/exclude dependencies but you can just override the version if you are using the Spring Boot build plugins. See Maven and Gradle docs for overriding managed versions.
Comment From: geniot
Hi, Can someone please share an example of how to exclude and include, because it is not working for me. :( Thanks, Nitin
I added