Last week, we announced the discovery of Spring4Shell — a remote code execution (RCE) vulnerability in older versions of the spring-beans package. In our blog post Spring4Shell: The zero-day RCE in the Spring Framework explained, we showed how an old Tomcat exploit for CVE-2010-1622 became relevant again. Due to the nature of the problem, we expected that additional payloads could be created beyond this known Tomcat exploit.
Several vulnerabilities for Java Spring framework have been disclosed in the last hours and classified as similar as the vulnerability that caused the Log4Shell incident at the end of 2021. However, as of the publishing of this report, the still ongoing disclosures and events on these vulnerabilities suggest they are not as severe as their predecessor.
Application Programming Interface (API) attacks are set to become one of the most prevalent cyberattacks with a broad target range. By nature, APIs expose application logic and sensitive data such as personally identifiable information (PII), causing APIs to become a target for attackers. In 2019, Gartner predicted that API hacks would become the most common form of cyberattacks in 2022. So how can teams stay ahead of API attacks?
At the end of March 2022, two critical vulnerabilities (CVE-2022-22963 and CVE-2022-22965) were discovered in different components of VMware Spring. Spring is a popular framework focused on facilitating the development of Java applications, including cloud-based apps, eliminating the need for additional code or concerns related to server requirements.
With more than 38 percent of our customers impacted by the recently discovered Spring4 Shell zero-day vulnerability and more than 33 percent of impacted organizations having already remediated (removed) some or all their vulnerable libraries, I have been involved in many conversations over this incident.
