Security

Drupal security in practice — what actually happens when you skip updates

Drupal security updates feel like tedious routine — until the day your site is compromised. Here is the real picture of what happens and how to protect yourself.

What attackers do with Drupal sites

A compromised Drupal site does not necessarily "break" — an attacker's goal is often not to destroy the site. The goals are:

Malware distribution — hidden code is added to the site that loads malware onto visitors' computers. The site works normally, the owner notices nothing — but Google notices and adds the site to its blacklist.

SEO spam — hidden pages are added advertising pharmaceuticals, gambling or other illegal content. Google indexes these pages under the site's domain. Result: the site's SEO reputation is damaged.

Botnet member — the compromised server is added to a botnet used to send spam or conduct DDoS attacks against other targets.

Data theft — user data, passwords, email addresses are extracted from the database.

Known Drupal vulnerabilities

Drupalgeddon (SA-CORE-2014-005) — SQL injection vulnerability in Drupal 7. Within hours of disclosure, mass automated exploitation began. Sites that did not update within 7 hours were considered likely compromised.

Drupalgeddon 2 (SA-CORE-2018-002) — Remote Code Execution. An attacker could execute code on the server without authentication. The Drupal Security Team unusually issued a patch even for Drupal 6 (already end-of-life) because the vulnerability was so critical.

SA-CORE-2020-007 — File upload vulnerability. A specially named file passed security checks and was executed on the server as PHP code.

All of these were publicly known vulnerabilities — attackers had automated tools scanning the internet for vulnerable sites.

The Drupal Security Team — how it works

The Drupal Security Team publishes security updates on Wednesdays at 16:00 UTC. This is a known schedule, which means:

  1. The security update is published
  2. Within hours, attackers analyse the update contents and build an exploit
  3. Automated scanners find vulnerable sites on the internet
  4. The attack begins

The time from update publication to first attack is often hours, not days.

Practical security management

Module update workflow:

  1. composer outdated --direct — shows packages needing updates
  2. Update in the test environment, verify critical workflows
  3. Deploy to production — ideally the same day the security update is released

Monitoring:

  • Subscribe to Drupal Security Advisory emails — the security@drupal.org list
  • Use drupal-check or the security_review module for regular checks
  • Log filesystem changes (fail2ban, OSSEC)

Access restrictions:

  • Put the admin URL (/admin, /user/login) behind IP restriction or change to non-standard path
  • Use two-factor authentication for admin accounts
  • Remove test accounts and unused modules

Backups:

  • Daily automated backup of database and files
  • Backups must be on a different server — if the server is compromised, backups must be untouched
  • Test backup restoration regularly

If the site is compromised

  1. Take the site offline — cut access before analysing the situation
  2. Do not just "clean" it — the attacker may have installed backdoors in multiple places
  3. Restore from a clean backup — ideally from before the compromise
  4. Update before going back online — restore to an updated Drupal, not the version that was hacked
  5. Review the logs — determine how access was gained

A security incident plan should be written before you need it, not during the incident. Read more about security incident planning.

If you want an overview of your site's security posture, we carry out Drupal security audits.

Kaido Toomingas Kaido Toomingas WebPro Company OÜ

Need Drupal help?

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.

Contact us