What happened
In March 2022 a flaw nicknamed Spring4Shell showed that Spring's data binding could be pushed beyond its intended job. Under the right conditions, an attacker could set internal properties and write a file of their choice to the server.
Write the right file to the right place, and you have a web shell: a small script that lets you send commands and get answers back.
How binding became a write primitive
Spring maps request parameters onto object fields automatically. That is great until the mapping can reach fields that control the runtime rather than your data.
By walking the object graph through crafted parameter names, an attacker reached configuration that let them control where output was written. They used it to drop a shell, then called it.
Why convenience features bite
Automatic binding saves developers from writing boilerplate. It also means user input can touch far more of your objects than you intended, and the boundary is easy to misjudge.
Spring4Shell needed specific conditions to work, but where they were met, a single request was the whole exploit.
How it unfolded
- Mar 2022Details leak ahead of a coordinated release. Exploitation starts quickly.
- Mar 31, 2022Spring confirms the flaw and ships fixed versions.
- Apr 2022Scanners and botnets fold the exploit into their toolkits.
Where buggy.run fitsDangerous binding shows up when you send parameters the developer never expected and watch what changes.
buggy.run fuzzes your endpoints with unexpected inputs and reads the results, so a parameter that quietly writes a file or shifts behavior is the kind of thing it flags.
What to take away
- Patch Spring promptly and track which services use it.
- Constrain data binding with allow-lists so input cannot reach sensitive fields.
- Watch for unexpected files appearing in web-served directories.
- Run app processes with the least privilege they need.
