{"id":11414,"date":"2022-04-01T11:29:14","date_gmt":"2022-04-01T10:29:14","guid":{"rendered":"https:\/\/42crdev.prexihost.com\/?p=11414"},"modified":"2022-09-24T14:04:54","modified_gmt":"2022-09-24T13:04:54","slug":"lessons-learned-from-the-spring4shell-vulnerability","status":"publish","type":"post","link":"https:\/\/staging2022.42crunch.com\/lessons-learned-from-the-spring4shell-vulnerability\/","title":{"rendered":"Lessons learned from the Spring4Shell vulnerability"},"content":{"rendered":"

Recently we published an article on the log4shell vulnerability<\/a> targeting log4j<\/i>, in which we explained how APIs can be protected against injection attacks with a positive security model, and how 42Crunch easily enables such a model. Now, it\u2019s time for the Spring4Shell<\/i> (CVE-2022-22965) vulnerability, targeting the Spring framework, commonly used to build APIs. What can we learn from this vulnerability?<\/p>\n

Diving into Spring4Shell<\/i><\/h4>\n

The Spring team has published an article<\/a> explaining the preconditions necessary for exploitation, and a workaround to prevent exploitation when upgrading the framework to 5.3.18 or 5.2.20 is not an option.<\/p>\n

The conditions they list for exploitation are the following :<\/p>\n