Hello SonarSource Community!
This is an announcement to let you know that SonarSource’s products are not susceptible to the Spring4Shell vulnerabilities, i.e. Spring Cloud Function (CVE-2022-22963) or Spring Core (CVE-2022-22965).
Thank you.
7 Likes
Thank you 
Thanks for confirmation but we require some further confirmation for our security team as we seeing some impacted jars in the Sonarqube work & temp folder.
Appreciate response on the the resolution for those jars ?
1 Like
Hello,
The version of SonarQube we are using (9.3 EE) contains a spring-core library which is suspicious:
sonarqube-9.3.0.51899\lib\extensions\sonar-security-java-frontend-plugin-9.3.0.14923.jar → META-INF\lib\spring-core-5.3.15.jar
Dan you explain in more detail why SQ is not vulnerable?
2 Likes
@surendrasajwan, @richard.diederen… have a peek at Spring’s blogpost on the subject: “Spring Framework RCE, Early Announcement”. You will see here that spring-core is not one of the vulnerable components… even though it is mentioned in the announcement above.
The vulnerability appeared in GitHub Security Advisory Database as GHSA-36p3-wjmg-h94x (note no spring-core) on 31st March, and the day before that in Snyk as SNYK-JAVA-ORGSPRINGFRAMEWORK-2436751 (although it only mentions spring-beans as of today, 4th April).
In summary… I think you are both OK 
3 Likes
Hi Mark,
the Remote Code Execution in Spring Framework · CVE-2022-22965 · GitHub Advisory Database · GitHub is mentioning spring-beans and e.g. SonarQube 8.9.8 is including a vulnerable version (< 5.2.20) of this lib:
sonarqube-8.9.8.54436/data/web/deploy/plugins/securityjavafrontend/META-INF/lib/spring-beans-5.2.13.RELEASE.jar
For this reason, I got an alert from our security scanners and was asked to handle this.
Yes, the GitHub Advisory does include spring-beans (along with other components). I was mostly emphasing that spring-core is not impacted. Still, it might help if @Colin gave a bit of clarification. After all, the main reason why Sonarsource products might not be impacted could be down to (say) not using Tomcat.
As an aside, this is where standards such as CycloneDX Vulnerability Exploitability Exchange (VEX) will become important in the future for allowing automation of announcements.
For what it’s worth, the CVE is still (as of 5th April) not analysed fully and lacks information such as CVSS and CWE. Also, it appeared in OSS Index just a couple of hours ago… for spring-beans only. No mention of spring-webmvc or spring-webflux as per the original Spring blogpost!
1 Like
Hey all.
While our Java taint analysis engine (in commercial editions) uses a Spring dependency to parse Thymeleaf templates, it is not used to run any kind of web service.
Our security researchers did not find any type of vulnerability in our limited, parsing-only usage of the dependency.
In our latest version of SonarQube (9.4) we have as a matter of course and not due to any specific CVE upgraded to Spring 5.3.15, we are not planning to make an LTS update due to the non-impacting nature of the dependency.
1 Like
Hi,
we are using the LTS version and like Rainer Montag, I’m also asked to fix it by our security team. So it is not quite “non-impacting” for us…
At Colin: Can you please confirm, that you are also not vulnerable to CVE-2022-22950?
Because if I understand the vulnerability correctly it lies within SPEL which is indeed used when parsing Thymeleaf templates according to the official documentation. See section 2 in this link Tutorial: Thymeleaf + Spring.
Thank you in advance!
None of our products are vulnerable to CVE-2022-22950.
Thank you for the fast and precise response!