Do we have fix for Sonartype vulnerability CVE-2016-1000027 in Spring-web project in any of the latest version of Spring-web jar?

Comment From: bclozel

I guess you're referring to this issue. In this case, it's not a security issue in the Spring Framework codebase, but rather well-known insecure setups that the reference documentation has been warning against for a very long time now.

So the underlying question here is: is your application is using Java deserialization using input from untrusted sources?

Thanks!

Comment From: rstoyanchev

See also answers under #24434.

Comment From: gituserjava

@bclozel , at the moment we are not using Java deserialization, but we see security vulnerability at build time and the builds are breaking and we are forced to not use this Jar. Security teams are not allowing such jars.

Comment From: bclozel

@gituserjava I'm sorry to hear that.

Java deserialization from untrusted sources is a broader problem that's not specific to Spring Framework. Any Java application (without any Spring dependency) can expose such vulnerabilities - this is more about best practices than an actual flaw in Spring Framework's codebase.

As you can see in #24434 there's nothing we can do here from a CVE perspective. Maybe you can get in touch with your security team or your security vulnerability tool vendor and work out this particular case?

Comment From: gituserjava

@bclozel , if we switch to Java 9 or above, will this be solved?

Comment From: bclozel

@gituserjava I don't think it will. For further advice on application security, please reach out to your security team or vendor. Thanks,

Comment From: artem-smotrakov

FYI

Vulnerable applications can be detected using static code analysis.

If you use CodeQL, I've created two CodeQL queries that detect vulnerable service exporters:

This blog post describes the issue, shows an example of vulnerable code, and describes the queries.