Two critical flaws in Drupal's core let attackers take over unpatched sites, and attacks followed within days. Here's what that means for any business still running an old or unsupported content management system.
When most businesses hear about a website security flaw, it's in an add-on: a plugin, a theme, an extra module. Those matter, but they only affect the sites that use that particular add-on, and you can often remove it.
Drupalgeddon was a different kind of problem. The name was given to critical flaws in the core of Drupal, a widely used content management system (the software many organisations use to run their websites). The core is the part every Drupal site runs. When the core has a serious flaw, every site on an affected version is exposed, however carefully it was built.
Drupal has had two famous examples, in 2014 and 2018. In both cases, Drupal's security team acted quickly and published fixes. In both cases, large numbers of sites were still caught, because they weren't updated in time. For any business running an older website platform, these incidents are a useful lesson in how quickly a core flaw turns into real attacks, and in what happens once a platform stops receiving fixes at all.
When the foundation of your website has a crack
Think of a website platform as a building. Add-ons are the furniture and fittings. The core is the foundation. A problem with one piece of furniture is contained. A crack in the foundation affects everything built on top of it.
In March 2018, Drupal fixed a flaw known as Drupalgeddon 2 (CVE-2018-7600). The US National Vulnerability Database (NVD) rates it 9.8 out of 10, and says it affected sites "with default or common module configurations". In plain terms, an attacker anywhere on the internet could make an affected site carry out their own instructions, without needing a username or password. Drupal treated it so seriously that it announced the fix a week in advance, warning that exploits "might be developed within hours or days" of the release.
That warning proved accurate. On 12 April, publicly available attack code appeared online, and the SANS Internet Storm Center, which monitors internet attacks, saw the first matching attack the next day. Its monitoring systems recorded attackers installing cryptocurrency-mining software, which uses a victim's server to make money for the attacker, and backdoors that let them come back later.
A month after the first fix, Drupal fixed a related flaw (CVE-2018-7602) and confirmed that both were "being exploited in the wild". The second fix only worked on sites that already had the first, so sites that had skipped the March update were further behind. The US Cybersecurity and Infrastructure Security Agency (CISA) lists both flaws in its catalogue of vulnerabilities known to be exploited, and as of 23 October 2026 marks both as known to be used in ransomware campaigns.
The original Drupalgeddon, in 2014 (CVE-2014-3704), was even starker. Two weeks after releasing a fix, Drupal's security team told site owners to assume that every Drupal 7 website "was compromised unless updated or patched" within seven hours of the announcement. It also warned that updating alone "will not remove backdoors".
What could go wrong for your business
A flaw like this gives an attacker control of the server behind your website, not just its pages. The consequences depend on what that server holds and connects to, but realistic risks include:
- Data exposure. Customer records, enquiry forms, account details and anything else the site stores or can reach.
- Hidden misuse of your server. In 2018, attackers installed crypto-mining software. A site can keep working while its server is quietly used for someone else's profit.
- Backdoors that outlast the fix. Both incidents left hidden access points that survived the update. A site that was updated late may still be compromised today.
- Ransomware. CISA marks both 2018 flaws as known to be used in ransomware campaigns. That doesn't mean every affected site was hit, but it shows how far the damage can go.
- Downtime and recovery costs. Cleaning up a compromised site usually means investigation, rebuilding from a known clean copy and changing passwords, often under pressure.
- Lost trust. Customers and partners rarely distinguish between "our platform had a flaw" and "our business was careless".
Could your website be next?
Attackers rarely choose their victims one by one. They use automated tools to scan large numbers of websites for known flaws, and attack wherever they find one. A core flaw suits this well, because one technique works against every unpatched site on an affected version. Drupal's 2014 warning shows how short the window can be: seven hours.
That's why being a small business, or having a low-profile website, isn't protection on its own. Scanners don't check how important a site is before they try it. They check whether it responds the way a vulnerable site would.
Equally, never having had an incident isn't proof of safety. The 2014 and 2018 attacks could leave backdoors behind with no obvious sign on the site itself. A site can look perfectly normal while someone else still has access.
None of this means every Drupal site is compromised, or that an attack is certain. It means your exposure depends on which version you run and how quickly it has been kept up to date, not on how well known your business is.
Why legacy PHP applications deserve attention
Drupal's security team handled both incidents well: clear warnings, fast fixes, and even fixes for some versions it had officially stopped supporting. The damage came from sites that couldn't, or didn't, take those fixes in time.
That's the pattern with ageing applications. A site stuck on an old version, carrying custom changes to its core or relying on modules nobody maintains any more, often can't be updated on the day a fix appears. Each skipped update makes the next one harder.
The bigger risk is time. Drupal's security team announced that Drupal 7 would reach its end of life on 5 January 2025, and said "This will be the final extension." Since then, Drupal 7 sites have had no official security fixes. Drupal's release schedule also states that Drupal 10 reaches end of life on 9 December 2026. When the next serious core flaw is found in either version, there will be no official fix for it.
This isn't a problem with PHP as a language, or with Drupal itself. Current, well-maintained Drupal sites receive fixes, and every platform, Node.js included, has had serious flaws in its core. The issue is a platform that no longer receives updates, or a site that can't take them.
What this means for your organisation
If your website runs on Drupal 7, Drupal 10 or another older content management system, a few questions are worth answering now, before the next critical flaw makes them urgent:
- Which version of the platform does your site run, and when does its security support end?
- If the site was running in 2014 or 2018, was it updated quickly, and has anyone checked it for leftover backdoors since?
- Could your team apply an urgent fix within days, or would custom changes and old modules slow it down?
- If the platform is out of support, what is the plan for the next five years?
The answers tell you how exposed you are, and whether the right path is extended support, an upgrade or a rebuild. For Drupal 7 in particular, moving to a current version is usually closer to a rebuild than a simple upgrade, which makes it a natural moment to reconsider the platform as a whole.
Recommended next step
Don't wait for the next "geddon" to find out where your website stands. Our free Legacy PHP assessment looks at the platform version your site runs, its modules, hosting and update history, so you can see how exposed you are to core flaws like these and what your options are before support runs out.
From there, our team can talk you through the choices. For some organisations, that means extended support or a planned upgrade. For others, especially those already facing a rebuild, a move to a modern Node.js stack may be a good fit, depending on what the site does and where the business is heading. No platform is secure by default, Node.js included, but one that is supported and kept current means you get a fix when the next serious flaw arrives.
Free Legacy PHP Risk Assessment
Running Drupal 7, an older Drupal 8 to 10 site or another PHP CMS? We'll review your core version, modules, hosting and update history, and tell you plainly where you're exposed and what your options are, from extended support to a planned migration.
