Legacy Drupal Hacks: Drupalgeddon and What Came After

By Glenn Lyvers · Updated September 21, 2026 · 4 min read

Drupal's history includes several vulnerabilities severe enough to earn their own names and trigger mass exploitation within days of disclosure. If your site is on an old Drupal version, two questions matter: whether it was caught in one of those waves years ago and still carries the result, and what to do about a platform that is no longer receiving fixes.

What the named events were

The vulnerabilities that became known as Drupalgeddon were critical flaws allowing remote attackers to execute code on unpatched Drupal sites without authentication. The pattern each time was the same: a highly critical advisory published with a fix, automated exploitation at scale within hours to days, and a large population of sites compromised before their owners applied the patch.

The Drupal security team handled these well by the standards of the industry — advance notice, clear advisories, prompt fixes. The damage was concentrated entirely among sites that did not update quickly, which is a much larger group than it should be.

The problem with old Drupal today

Drupal 7 reached end of life and no longer receives community security support. That is the same structural position as any unsupported platform: newly discovered vulnerabilities will not be fixed, and the exploitable list only grows.

Extended commercial support arrangements exist for organisations that need them, and they are a legitimate option if migration genuinely cannot happen yet. What is not legitimate is running an unsupported version with no support arrangement and treating it as a stable situation, because it is a deteriorating one.

Checking whether you were already hit

This matters because a site compromised in one of these waves may have been carrying a backdoor for years without anyone noticing — these campaigns frequently installed persistence and then did something quiet and profitable like spam injection or cryptomining.

Look for PHP files in sites/default/files, which should contain no executable code at all. Compare core and contributed modules against clean copies of the same versions. Check the user list for accounts you did not create and review role permissions for quiet additions. Check for injected content in nodes and blocks, and check settings.php for appended code. My guide on hacked Drupal sites covers each of these, and timestamp forensics covers dating what you find.

When the compromise is years old

An old compromise is harder to investigate than a fresh one, and you should be realistic about that. Your access logs will have rotated away long ago, so the entry point may be unknowable beyond an informed guess. File timestamps may have been flattened by migrations or restores.

In that situation the practical approach shifts from investigation to rebuilding trust in the files: replace everything you can from clean sources, treat anything you cannot account for as hostile, sweep the database thoroughly, and rotate every credential on the assumption that all of them were exposed years ago. My guide on rotating credentials covers the full list.

The detail that catches people out

Drupal caches rendered output aggressively, and pages generated while the site was infected can keep being served from cache long after the source is clean. People clean a site, check it, see injected content still appearing and conclude the cleanup failed.

Clear all caches after cleaning, then verify. It is a small thing and it accounts for a disproportionate share of the confusion in Drupal cleanups.

Deciding what happens next

If the site still matters to your organisation, migrating to a supported Drupal version is the intended path, and it is a project rather than an afternoon. If it matters less than it used to, consider whether it needs to stay a Drupal site at all — a static export of a low-change site removes the entire attack surface permanently, which my guide on static sites touches on.

What I would avoid is cleaning an end-of-life site and considering the matter closed, because the platform will keep accumulating unpatched flaws whatever you do to the current infection. If you want the site checked properly first so you know what you are deciding about, that is work I take on — see the platforms I clean.

Common questions

What was Drupalgeddon?

The informal name given to critical Drupal vulnerabilities that allowed unauthenticated remote code execution on unpatched sites. Each disclosure was followed by mass automated exploitation within hours to days, compromising large numbers of sites whose owners had not yet applied the published fix.

Is Drupal 7 still safe to run?

It no longer receives community security support, so newly discovered vulnerabilities will not be fixed. Commercial extended support arrangements exist and are a reasonable option if migration cannot happen yet. Running it unsupported with no arrangement is a deteriorating position rather than a stable one.

How do I know if my site was compromised years ago?

Look for PHP files in sites/default/files, compare core and modules against clean copies, audit users and role permissions, check nodes and blocks for injected content, and read settings.php for appended code. Old compromises are often quiet — spam injection or mining rather than anything visible.

My logs are gone. Can I still find the entry point?

Often not definitively. With logs rotated away and timestamps possibly flattened by migrations, the honest answer may be an informed guess. In that case shift the effort to replacing everything you can from clean sources and rotating every credential on the assumption all were exposed.

Why does injected content still appear after I cleaned the site?

Very commonly it is the cache. Drupal caches rendered output aggressively, so pages generated while infected keep being served after the source is clean. Clear all caches after cleaning, then verify again before concluding anything went wrong.