Rossen Stoyanchev

On behalf of the Spring for GraphQL team and every contributor, it is my pleasure to announce the 1.0 GA release. It’s been 10 months since the project was announced and under 2 years since the first commit, unremarkably called “first commit”. The project began with the modest goal to replace the (now archived) minimal GraphQL Java Spring integration, but has since moved significantly beyond through community feedback and collaboration across Spring Boot, Spring Framework, Spring Data, and Spring Security.

Yesterday we announced a Spring Framework RCE vulnerability CVE-2022-22965, listing Apache Tomcat as one of several preconditions. The Apache Tomcat team has since released versions 10.0.20, 9.0.62, and 8.5.78 all of which close the attack vector on Tomcat’s side. While the vulnerability is not in Tomcat itself, in real world situations, it is important to be able to choose among multiple upgrade paths that in turn provides flexibility and layered protection.

Upgrading to Spring Framework 5.3.18+ or 5.2.20+ continues to be our main recommendation not only because it addresses the root cause and prevents other possible attack vectors, but also because it adds protection for other CVEs addressed since the current version in use.

Updates

• [04-13] “Data Binding Rules Vulnerability CVE-2022-22968” follow-up blog post published, related to the “disallowedFields” from the Suggested Workarounds
• [04-08] Snyk announces an additional attack vector for Glassfish and Payara. See also related Payara, upcoming release announcement
• [04-04] Updated Am I Impacted with improved description for deployment requirements
• [04-01] Updated Am I Impacted with additional notes
• [04-01] Updated Suggested Workarounds section for Apache Tomcat upgrades and Java 8 downgrades
• [04-01] “Mitigation Alternative” follow-up blog post published, announcing Apache Tomcat releases versions 10.0.20, 9.0.62, and 8.5.78 that close the attack vector on Tomcat’s side
• [03-31] Spring Boot 2.6.6 is available
• [03-31] Spring Boot 2.5.12 is available
• [03-31] CVE-2022-22965 is published
• [03-31] Added section “Misconceptions”
• [03-31] Added section “Am I Impacted”
• [03-31] Fix minor issue in the workaround for adding disallowedFields
• [03-31] Spring Framework 5.3.18 and 5.2.20 are available

On behalf of everyone involved, I’m pleased to announce the availability of the sixth and final milestone of Spring for GraphQL on the way to 1.0. Our next stop is RC1 in 4 weeks, followed by the GA on May 17.

GraphQL Client

A GraphQL client is something we identified as a goal quite early on. It’s issue number 10 from 336 at present in the issue tracker, but we viewed testing support as higher priority and so the GraphQL Tester came first and has been available from the start.

The Tester did prove valuable and popular, but we knew we had to fully explore the client before 1.0 as the two are closely related but have slightly different perspectives, and we wanted to make sure they’re aligned with each other.

The Spring Framework 5.3.14 and 5.2.19 releases on December 16 included fixes for CVE-2021-22060 and are a follow-up to CVE-2021-22096, to address additional types of input that can cause the issue. As the Spring Boot releases 2.6.2 and 2.5.8 picking up these Spring Framework versions were due the day before Christmas and given the medium severity, we postponed the announcement until after the new year, to avoid disclosure during a period when many take time off. Please, upgrade to those latest maintenance releases.

The recently released Spring Boot 2.5.6 and 2.4.12 releases contain fixes for the following security vulnerabilities:

• CVE-2021-22096 for the Spring Framework
• CVE-2021-22047 for Spring Data REST
• CVE-2021-22097 for Spring AMQP

In addition, Spring Cloud OpenFeign has released versions 3.0.5 and 2.2.10, based on the same Spring Boot versions, and containing a fix for the following security vulnerability:

• CVE-2021-22044 for Spring Cloud OpenFeign

Please, review the reports and upgrade!

Following the Spring GraphQL project announcement and the availability of a 1.0 milestone, this blog post aims to provide more details.

Introduction

If you’re looking to get started, please head over to our reference documentation and read the “Boot Starter” section, or run the samples.

If you don’t know much about GraphQL, there are plenty of good resources. You can start at graphql.org/learn.

GraphQL is widely adopted and in “Early Majority” based on the InfoQ Architecture Trends for 2020. It provides an alternative to REST APIs that is more focused on data, and provides a schema and a query language for clients to use. The appeal from a client perspective is clear in this State of JavaScript report. You can read GitHub’s story on why it uses GraphQL.

Guest Author: Andi Marek, GraphQL Java founder

I am very happy to announce the creation of the Spring GraphQL project and the availability of an initial milestone towards a 1.0 release. The project integrates GraphQL Java and Spring and was developed in collaboration between both teams.

Today is GraphQL Java’s 6th birthday! One fundamental decision I made from the start was to leave any HTTP and IO aspects as a separate concern. GraphQL Java has always been “just” an engine to execute GraphQL requests. The decision has paid off but the obvious downside is the need to create your own HTTP adapter for real world usage.

The recent Spring Framework 5.3 M1 release announcement mentions “Spring MVC comes with PathPattern parsing for efficient URL matching”. This post expands on that with more context and detail.

Overview

In Spring applications AntPathMatcher is used to identify classpath, file system, remote, and other resources in Spring configuration. It has also been used in Spring MVC to match URL paths. Over time the use of patterns in web applications grew in number and syntax with AntPathMatcher evolving to meet those needs but some pain points remain without a solution:

The following CVE reports were published today:

• CVE-2020-5403 affecting Reactor Netty HttpServer 0.9.3 and 0.9.4.
• CVE-2020-5404 affecting Reactor Netty HttpClient for all 0.8.x and 0.9.x versions in applications where the automatic following of redirects is explicitly enabled.

The fixes are in Reactor Netty 0.9.5 and 0.8.16. If using the reactor-bom, you can upgrade to Dysprosium-SR5 or Californium-SR16.

Reactor Netty is used internally in many frameworks including Spring WebFlux and its WebClient. If you have a Spring Boot application, you can upgrade to Spring Boot 2.2.5 or 2.1.13.