What happened
In 2018 the Drupal team patched a flaw in how core handled certain request data. The data could carry instructions that Drupal would act on, which meant an unauthenticated visitor could run code on the server.
The advisory was blunt about the severity. Within days a public exploit appeared, and attackers started taking over sites at scale.
How form input ran code
Drupal builds pages from nested structures, and some request data was allowed to feed into those structures without being cleaned first. Crafted input reached a place where it was treated as instructions rather than text.
No login, no special access. Just a request shaped the right way to a normal endpoint.
Why unauthenticated RCE is the worst kind
Most serious bugs need some foothold first. Unauthenticated remote code execution needs nothing. Anyone who can reach the site can take it over, which makes it perfect for automated, internet-wide attacks.
Sites that did not patch within the first days were often compromised before their owners even saw the advisory.
How it unfolded
- Mar 28, 2018Drupal ships the patch with a high-severity advisory.
- Apr 2018A public exploit lands and mass exploitation begins within days.
- 2018 onwardCompromised, unpatched Drupal sites keep surfacing for a long time.
Where buggy.run fitsUnauthenticated remote code execution on a public endpoint is the exact thing an attacker scans for, and the exact thing worth checking before they do.
buggy.run walks your public surface and probes it the way an attacker would, so an endpoint that does something it should never do is surfaced rather than waiting to be found in the wild.
What to take away
- Patch CMS core the day a critical advisory lands. The window is measured in days.
- Sanitize all request input, including the parts frameworks parse for you.
- Keep your public attack surface as small as possible.
- Watch for web shells and unexpected files after any critical CMS flaw.
