Drupalgeddon 2: This Time, the System Worked

The sequel arrived on March 28. SA-CORE-2018-002, promptly nicknamed Drupalgeddon 2. A remote-code-execution flaw in Drupal’s core request handling, severe enough to span Drupal 6, 7, and 8 at once and to earn the project’s highest risk score.

Readers of the 2014 file know the stakes of that sentence. Unauthenticated. Wormable. Every unpatched install a candidate for full compromise.

But this month is not a rerun of 2014’s grim chronicle, because one thing was different, and the difference is the story. The Drupal security team pre-announced the advisory a full week in advance. A public service announcement on March 21 said, in effect: a highly critical core update lands March 28 in a stated time window. Have your people at the window. Clear your change calendars now.

No details that could aid attackers. Just the date, the severity, and the instruction to be ready. It was the security-release process redesigned around the central lesson of 2014. The race between patch and exploit is decided by preparation, not talent. This month the industry got to watch a controlled test of whether preparation, given notice, actually wins. It does. This time, the system worked, and the post-mortem of a working system is a better genre than the alternative, so let us write it properly.

What the week of notice changed, measurably

Walk the timeline as our own bench experienced it.

March 21: the PSA lands, and preparation becomes schedulable. Maintenance windows booked. On-call assignments confirmed. Staging servers readied. Client communications drafted with a blank for the version number.

March 28: the advisory and patch publish in the announced window. Teams that staged resources applied, tested, and verified within hours. Ours included, across every covered install in the maintenance book. Mostly before the first proof-of-concept analyses appeared publicly.

The weeks after: exploitation ramped as the flaw was reverse-engineered into working attacks. Within roughly two weeks, mass exploitation was underway. The compromise reports that piled up drew their victims overwhelmingly from the population the PSA never reached. Mostly cryptomining payloads, the era’s cash-out of choice, harvesting server capacity from the unpatched. The unmaintained tier.

Compare 2014’s physiology. Then, exploitation began within hours of an unannounced advisory, and the difference between patched-in-hours and compromised was luck and heroics. The PSA converted that lottery into a calendar event, and the teams that treated it as one experienced the sequel as procedure.

The mechanism deserves naming, because it generalizes. Advance notice moves the race’s starting line from the moment of disclosure to the moment of preparation. Preparation is the only leg of the race that institutions actually control.

The victims’ profile, unchanged and diagnostic

The compromise population repeats 2014’s with an exactness that should end the debate about what web security actually is.

The harvested installs were, overwhelmingly: the abandoned microsites still resolving years after their campaigns closed. The departmental installs procured outside governance and orphaned by turnover. The ‘temporary’ properties running half a decade past their events. The sites whose maintenance contracts lapsed or never existed.

Not, note, the sites with modest budgets and diligent calendars, which patched fine. Patching within a pre-announced window is not expensive and requires no elite talent. It requires knowing the install exists, having someone assigned, and treating the PSA as the calendar item it was.

The diagnosis we have been sharpening across WannaCry, the first Drupalgeddon, and now the sequel is ready to be stated plainly. It is a management claim, not a technical one. Security failures at institutional scale are management failures with technical symptoms.

The technical symptom this month was a request-handling flaw. The failures were absent inventories, unowned properties, and ungoverned long tails. No patch exists for those except governance itself. The site census. The retirement habit that closes expired properties instead of abandoning them. The maintenance coverage without gaps. The response process that moves in hours. The 2014 playbook, in other words, validated by rerun, with the pre-announcement as the one truly new page.

The checklist, updated for the PSA era

• Subscribe, institutionally. The security announcement channels for every platform in your site, routed to a staffed destination rather than a former employee’s inbox. The PSA model only works for organizations that receive the PSA.

• Treat pre-announcements as booked windows. When a security team says ‘be ready Wednesday,’ the correct response is calendared staffing, staged environments, and pre-drafted communications. This month demonstrated the payoff. The cost is an afternoon’s planning. The return was measured in this April’s compromise statistics.

• Audit the long tail this quarter. The census, again and always. Every install, owner, and version, with the orphans either adopted into coverage or retired on schedule. April’s harvest was gathered exclusively from this tier, and yours is either listed or vulnerable.

• Verify, don’t assume, post-patch. The sequel’s long exploitation tail included installs patched after compromise. Patched over an intruder already resident. Sites that patched late owe themselves the compromise check the incident-response practice prescribes. Unexpected files, users, and scheduled tasks.

What changed in security practice

The category note, because we have now written both endings and the contrast is the education.

The 2014 post was a chronicle of a race most participants did not know they were running. Hours to patch, no warning, and a long tail of quiet compromises that surfaced for months.

The 2018 post is a chronicle of a drill. Warning issued, windows booked, patches applied. The exploitation wave broke mostly against organizations that had, in every sense that matters, already left the building.

The difference was not better luck or better attackers. It was a security team that redesigned its process around how institutions actually fail, and institutions that met the redesign halfway.

That is the whole model we have argued for years, demonstrated end to end. The defenders publish the calendar. The governed sites keep it. The ungoverned tier absorbs the consequences with statistical reliability.

Choose your tier. It is, and has always been, a choice made in budget meetings and org charts rather than in code. Which is why this post, like its 2014 predecessor, is addressed to the people who run things and not only the people who patch them. The next advisory is already scheduled somewhere. Be the site with people at the window.