CVE-2022-1471 has been reported against the SnakeYaml project 1.30+. More information can be found in the google/security-research project security post.

At this stage, SnakeYaml has no patch to fix it. A new issue has been created on SnakeYaml's Bitbucket project.

The description says We recommend using SnakeYaml's SafeConsturctor when parsing untrusted content to restrict deserialization.

Spring Boot uses SnakeYaml so potentially could be impacted. Can somebody (@bclozel) help with checking how Spring Boot uses SnakeYaml since Spring Boot may not be impacted by the vulnerability?

Thank you.

Comment From: philwebb

Thanks for the information.

Spring Boot already uses SafeConstructor internally so I don't think there are any changes we need to make. Furthermore, typically Spring Boot application only use SnakeYaml to parse application.yaml files, which should be trusted already.

Users that use SnakeYaml directly to parse data from untrusted sources should implement their own mitigation strategies.

Comment From: albertwangnz

@philwebb Thanks a lot. Those are the information I am looking for.

Comment From: bisvo01

Is Spring Boot 2.7.x still supported? The unsafe Constructor is still used there.

Comment From: bclozel

@bisvo01 Spring Boot 2.7.x is currently supported, see our support timeline page. We'll do another pass in our codebase to ensure that we're using the safe constructor variant - but in general, Spring Boot is only parsing yaml from trusted sources. Using SafeConstructor is especially useful when you're parsing untrusted content.

Comment From: philwebb

@bisvo01 I just double checked YamlJsonParser in 2.7 and I don't think it's susceptible to the CVE since it already limits the types that can be created.

Comment From: AmigaBlitter

@bisvo01 I just double checked YamlJsonParser in 2.7 and I don't think it's susceptible to the CVE since it already limits the types that can be created.

Thank you for the analysis.

Is Spring Boot 2.5.x susceptible to the CVE? Thank you in advance.

Comment From: bclozel

@AmigaBlitter it's not, unless your application is using SnakeYaml to deserialize untrusted input. I think the biggest security risk right now is being in production with a Spring Boot version that's not supported anymore (unless you've got commercial support).

Comment From: AmigaBlitter

Thank you for the reply.

Comment From: jpcmonster

@philwebb does the statement regarding SafeConstructur also cover https://github.com/springdoc/springdoc-openapi ? I am guessing no, but I am asking for completeness - thanks!

Comment From: scottfrederick

@jpcmonster springdoc-openapi is not a Spring Framework project (despite having "spring" in the name). It is maintained by a completely separate group. Any questions about that project should be asked in its repository.

Comment From: jpcmonster

@jpcmonster springdoc-openapi is not a Spring Framework project (despite having "spring" in the name). It is maintained by a completely separate group. Any questions about that project should be asked in its repository.

thanks for your reply; I suspected so and have followed up there.

Comment From: sreekanth-tf

@philwebb @bclozel Is it safe to exclude the snakeyaml dependency if we are using the application.properties instead of application.yml?

Comment From: philwebb

@sreekanth-tf Yes, it should be fine as long as you don't have any .yml files. If you do, this exception will be thrown.

Comment From: sreekanth-tf

thank you @philwebb!

Comment From: fabionoth

Thanks : )

Comment From: bclozel

We are aware that SnakeYaml 2.0 has been released, fixing this CVE. The team is working on an upgrade strategy. Also see spring-projects/spring-framework#30048.

Comment From: dlipofsky

Could the snakeyaml 2.0 fix be backported to SpringBoot 2.7.x ?

Comment From: wilkinsona

@dlipofsky I'm not sure what fix you're referring to, but this has already been addressed in 2.7.10.

Comment From: dlipofsky

@wilkinsona, I would be referring to having SpringBoot 2.7.x use snakeyaml 2.0. I can see that spring-boot-starter 2.7.10 pom pulls in snakeyaml 1.30. I scanned the ticket you refer to, it sounds like "one person tried it and it didn't break". I suppose I could try it. It also sounds like there might be some jackson compatibility issues that would burn me anyway unless I also upgrade jackson.

Comment From: wilkinsona

I would be referring to having SpringBoot 2.7.x use snakeyaml 2.0

The issue to which I already linked answer this.

I scanned the ticket you refer to, it sounds like "one person tried it and it didn't break". I suppose I could try it.

The commit that closed that issue to which I already linked adds a test that verifies that it works for loading application.yaml.

there might be some jackson compatibility issues

Correct. Compatibility of code that the Spring Boot team does not maintain is out of the Spring Boot team's control.

Comment From: pexa-slee

in your POM add in <snakeyaml.version>2.0</snakeyaml.version>

Comment From: swiss-chris

We're using Spring Boot 3.1.5 in many projects. If I look at the spring-boot-dependencies artifact for this version, I still see <snakeyaml.version>1.33</snakeyaml.version>

when are you planning to change this to 2.0, so that we don't have to temporarily patch this maven property in all our projects (and then remember to remove it again in the future) ?

Comment From: bclozel

@swiss-chris Spring Boot 3.2.0, see #37331

Comment From: swiss-chris

@bclozel The PR you linked has a commit which upgrades snakeyaml 2.1 to library("SnakeYAML", "2.2"). My problem seems to be a different one. I would like <snakeyaml.version>2.0</snakeyaml.version> inside spring-boot-dependencies of Spring Boot 3.x.

Comment From: bclozel

@swiss-chris we've upgraded to the latest SnakeYaml minor version (2.2) in Spring Boot 3.2. You can check the dependencies POM here. The issue I've pointed you to does just that, upgrading the SnakeYaml version in our dependency management.

Comment From: swiss-chris

@bclozel thanks for the clarification. As Spring Boot 3.2 is already in RC2, I assume it will be in GA soon ... (?).

Comment From: bclozel

Yes, it will be out soon. You can check our release dates on the milestone page and on our public release calendar.

Comment From: swiss-chris

Awesome!