Are you sure Java 8 is fine? The exploit is still present in the code it's just that Class has no module property. But there could be other properties that can be writeable that can cause exploit in similar pattern, no?

No. If you've found another way to exploit this with JDK8, you should reach out and share your findings: https://spring.io/security-...

Is Spring Boot executable war (not jar) deployment vulnerable? Thanks!

My understanding (please correct me if I am wrong) is that Spring Boot produces a file that can be executed as a Java archive (jar), and also deployed in a container as a (traditional) web archive (war). If a file is one or the other, then if it is executable, it is called an executable jar file. It does not need to have the WAR directory structure. If it has to be deployed in a web container, then it is a deployable war file. A jar file can be executable. A war file is deployable. Because Spring Boot produces one file for both purposes, it is sometimes loosely called an "executable war" file. However, there is no difference between a Spring Boot executable jar or a Spring Boot executable war. For the same application, they are the same file, called by different names.

It seems one of the requirements makes confusion here:

Packaged as a traditional WAR (in contrast to a Spring Boot executable jar).

does anybody have an answer to this?

The application must be deployed as a war file in a standalone Servlet container to be vulnerable. Running an executable war file with embedded container is not.

Brian Clozel Would it be possible to add this information to the official "Am I Impacted?" section and clearly state that only standalone servlet deployment is impacted and embedded servlet deployment is not?

Please do write that clearly. I sometimes use executable war instead of executable jar files (due to jsp) but I suspect my clients will see java 11, embedded tomcat, war file -> vulnerable and require me an emergency fix while I could be upgrading to the latest spring with a more normal schedule.

We've updated the "Am I impacted section" accordingly.

Just as a side note. Traditional web containers running WAR usually uses class loader hierarchy which resolves the container libraries first before any embedded WAR libraries. This may have an effect here.

Will spring boot 2.4.13 be updatable to the latest spring framework ?

Support for 2.4 ended last November as per https://spring.io/projects/.... Given the severity of this RCE I would like to see them make an exception here but I doubt it'll happen.

I am using spring-boot 2.1.3.RELEASE and I added below dependency as you suggested
<dependency>
<groupid>org.springframework</groupid>
<artifactid>spring-framework-bom</artifactid>
<version>5.3.18</version>
<type>pom</type>
<scope>import</scope>
</dependency>
Getting bellow ERROR when app is bootstraping
java.lang.reflect.InvocationTargetException
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImp...:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.springframework.boot.maven.AbstractRunMojo$LaunchRunner.run (AbstractRunMojo.java:558)
at java.lang.Thread.run (Thread.java:834)
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'handlerExceptionResolver' defined in class path resource [org/springframework/boot/autoconfigure/web/servlet/WebMvcAutoConfiguration$EnableWebMvcConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.web.servlet.HandlerExceptionResolver]: Factory method 'handlerExceptionResolver' threw exception; nested exception is java.lang.NoSuchMethodError: org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration$EnableWebMvcConfiguration.addDefaultHandlerExceptionResolvers(Ljava/util/List;)V

please help me on this

Spring Boot 2.1.x uses Spring Framework 5.1.x so you can’t use 5.3.x with this Spring Boot generation.

Spring Boot 2.1.x is also EOL, please upgrade as soon as possible to a supported version. See https://spring.io/projects/...

After upgrading Spring-boot version from 2.1.3-RELEASE to 2.5.12, we are facing some compile time issues related to Hateoas.
spring boot 2.1.3-RELEASE using Hateoas 0.25.0-RELEASE
spring boot 2.5.12 using Hateoas 1.x
some of the classes are deprecated, how I can migrate could you please help me on this.

You'll need to follow the dedicated Spring HATEOAS guide here: https://docs.spring.io/spri...

There is nothing in Spring Boot that relates to this vulnerability. You can upgrade your build to Spring Framework 5.3.18, check the documentation for more details.

I've pushed a sample repo as well, see https://github.com/snicoll-...

Sure but in previous spring boot releases you couldn’t go higher in the spring framework version without risk. Are you saying that all the 5.3.x releases should be compatible ?It’s never really been clear to me the cross matrix

It’s the same generation and a bug fix level, so it is fine.

I think you’re mixing up with the opposite. A new spring boot version with an older spring framework version.

Im using JDK11, Springboot 2.6.7 and Tomcat 9.0.62. But Still facing this CVE-2022-22965 vulnerability.!!
spring-boot-starter-security-2.6.7.jar | Reference: CVE-2022-22965 | CVSS Score: 9.8

What do you mean by "still facing it"? Are you still able to exploit the security issue on your application?
If a tool is providing this information, you should first validate that the effective dependencies of your application are the right ones (like maven dependency:tree or https://docs.gradle.org/cur....

Hi Team, please reply to me at the earliest,
I am using java 8, deploying war on servlet container, using spring parent 1.5.xx and cannot upgrade both tomcat and spring parent, still will I be considered as safe.

As described in this blog post, this only affects applications running with Java 9+ so in that regard, your application is not impacted.
On the other hand, your application is using Spring Boot 1.5.x, which has been out of support for years now (see https://spring.io/projects/... ) - your application is vulnerable to multiple other CVEs. Please upgrade as soon as possible.

we are getting below error after migrating to spring-boot 2.6.6. Test cases are failing with following error stack.

java.lang.IllegalStateException: Failed to load ApplicationContext
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'configurationPropertiesBeans' defined in class path resource [org/springframework/cloud/autoconfigure/ConfigurationPropertiesRebinderAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.cloud.context.properties.ConfigurationPropertiesBeans]: Factory method 'configurationPropertiesBeans' threw exception; nested exception is java.lang.NoClassDefFoundError: org/springframework/boot/context/properties/ConfigurationBeanFactoryMetadata
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.cloud.context.properties.ConfigurationPropertiesBeans]: Factory method 'configurationPropertiesBeans' threw exception; nested exception is java.lang.NoClassDefFoundError: org/springframework/boot/context/properties/ConfigurationBeanFactoryMetadata
Caused by: java.lang.NoClassDefFoundError: org/springframework/boot/context/properties/ConfigurationBeanFactoryMetadata

faced the same error when upgraded to spring boot 2.6.6 adding below spring cloud dependency solved it for me:

<dependency>
<groupid>org.springframework.cloud</groupid>
<artifactid>spring-cloud-dependencies</artifactid>
<version>2021.0.1</version>
<type>pom</type>
<scope>import</scope>
</dependency>

Also see below post:

https://stackoverflow.com/q...

thank you for the info. I tried that option but it did not worked for me as we have some complex maven dependency tree. So I explicitly added the spring cloud dependencies as per compatible matrix.

Please create a question on StackOverflow for this. It’s hard to help you in the comments as we’re missing a lot of information.

If we depend on spring-boot-starter-web, and transitively it depends on spring-webmvc, are we vulnerable, even if we are not using webMvc?
Also, if the Tomcat server, deploying our application, uses JDK 9, are they potentially vulnerable?

If you are 100% sure that no Spring MVC controller is present at all, the exploit might not apply to your application. But this arrangement can be a bit brittle since another developer introducing a controller (which would be a perfect normal thing to do) could make your application vulnerable. Upgrading is still the safest choice.

Are services annotated by @javax.ws.rs.Path impacted? We do not use Spring MVC controller explicitly either. But could it be used implicitly somehow? Anyway to make sure?

See the "Am I impacted" section of this blog post. We can't give you any guarantee without looking at your application. If you're not sure yourself, you should consider it's vulnerable and proceed with upgrading as soon as possible.

We are using Actuator. I turned on logs for the org.springframework.web.servlet.mvc package and I see references like this when doing health checks. So it looks like even if you are not explicitly using it, as you said, another component may. Thanks.

org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor:writeWithMessageConverters - Using 'application/vnd.spring-boot.actuator.v3+json;q=0.8'

Is @RequestMapping annotation in code required to be vulnerable on an endpoint?

Yes and no. It is required, but it can be used without it being present on a controller handler. For example, "@GetMapping" is meta-annotated with "@RequestMapping".

Ok, in the meantime I was able to confirm that the explicit use of @RequestMapping is not necessary as it is used implicitly.
RCE was successful in our application.

it's only affected if you use standalone tomcat and deploy war to it and using form value to accept the payload. If you are using rest service with json with embedded tomcat, jetty etc running it as jar then it should be fine?

This is what I'm perceiving as well. If you're not using @ModelAttribute as an input to a controller, you should be safe.

An application can be vulnerable without the presence of the ModelAttribute annotation in a controller.

Would be awesome to have some examples Brian. Doesn't have to be a working exploit, just a "here's what vulnerable controller methods look like" for @Controller & @RestController etc.

Spring MVC allows flexible methods, so it's hard to show an example without being misleading for many. Any argument annotated with ModelAttribute (or not annotated at all, since this applies by default) could be problematic. See the "any other argument" table entry here: https://docs.spring.io/spri...

What about springboot running jar as standalone with embedded Jetty server?

If the « Am I impacted » section of this blog post isn’t clear enough for your application, you should consider your application vulnerable.

Is not clear if those points are AND or OR or a combination 🤷‍♂️

Those are "AND", for the exploit that was known at the time. But note that other exploits have been found for other Servlet containers as well (namely Glassfish and Payara).

I guess the ultimate answer for me is this:

If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit.

Under the Vulnerability section

Are you sure? Do you have any ref about it? thx

Yes, the use of @ModelAttribute is not required. An unannotated POJO argument will also trigger the use of the DataBinder.

So for clarification - if your controller arguments are always @RequestParam or @PathVariable (as it is in our case), this should not be an issue. Obviously Spring has a default treatment of controller args, which is apparently @ModelAttribute, which is a problem.

On the workaround, can we avoid creating new array `denylist` for each http request? any reason why is it not shared? (afaik, field is private in DataBinder.class and it doesn't mutate it)