Drupalgeddon2: What It Still Teaches About Legacy Platform Patching

On March 28, 2018, the Drupal security team disclosed SA-CORE-2018-002 — a highly critical remote code execution vulnerability affecting Drupal 7.x before 7.58 and Drupal 8.x before 8.3.9/8.4.6/8.5.1. It became known as Drupalgeddon2, and it's still one of the clearest real-world examples of why patching timelines matter more than most site owners assume.

How the vulnerability actually worked

Drupalgeddon2 lived in Drupal's Form API, specifically its "renderable arrays" system — the mechanism Drupal uses to build and render form output. The vulnerability existed because input passed through form submissions and AJAX requests wasn't sufficiently sanitized before being processed by the renderable array system.

In practice, attackers targeted specific public-facing endpoints — user/register on Drupal 8 sites, user/password on Drupal 7 sites — and crafted requests that injected malicious parameters into the render array processing pipeline. Because Drupal's render system can invoke PHP callbacks based on array structure, a sufficiently crafted payload could reach functions capable of executing arbitrary code, including direct shell command execution via PHP's passthru.

Why this spread as fast as it did

Three factors combined to make this especially dangerous, and all three are still relevant to any legacy platform today:

• No authentication required. The vulnerable endpoints were publicly accessible — no login, no prior access needed. Any site running an affected version was exposed to the open internet by default.
• The exploit was quickly automated. Proof-of-concept code became public shortly after disclosure, and mass-scanning tools incorporated it within days, turning a manual research finding into an automated attack that could hit every exposed Drupal site on the internet simultaneously.
• Patching lagged disclosure by weeks on many sites. Sites that hadn't patched by early April were caught in the same automated sweep as sites that never patched at all — the two-week gap between advisory and mass exploitation was, for many site owners, not enough time to notice, test, and deploy the fix.

What this means if you're running an older Drupal (or any legacy PHP platform) today

Drupalgeddon2 is seven years old at this point, and any current Drupal install should be well past the affected versions. But the pattern it demonstrated — a critical, unauthenticated, remotely exploitable vulnerability in core software, weaponized within weeks — repeats on a regular cycle across every major PHP platform. It's exactly why our PHP code audit process starts with what's actually running (core version, patch level, dependency freshness) before looking at application code at all: the runtime version is a bigger risk factor than most individual code-level findings, because it determines whether a known, automated, publicly-available exploit already works against you on day one.

If you're on Drupal 7 specifically, this ties directly into the Drupal 7 end-of-life situation — D7 no longer receives official Security Team advisories at all, which means the next Drupalgeddon-class vulnerability in D7 core would have no official patch coming, only what D7ES vendors choose to backport.