How to Recover a Hacked Drupal Site (2026 Guide)

The notification arrived at 3 AM. Or a client called saying the site was showing strange content. Or Google Search Console flagged the domain as dangerous.

However you found out, you're now dealing with a compromised Drupal site and a list of questions: what happened, how bad is it, and what do you do first?

This guide covers the recovery process in the order it needs to happen. The instinct to immediately restore and move on is exactly how sites end up re-hacked two weeks later.

Step 1: Take the Site Offline Immediately

The first move is to take the site down. Not later, not after you've investigated — now.

Put the site into maintenance mode from the Drupal admin interface, or contact your hosting provider to take it offline. Two things are happening on a compromised site that make speed critical: visitors are potentially being exposed to malicious code, and the attacker may still have active access.

If the attacker has locked you out of the admin interface, contact your hosting provider directly. They can take the site offline at the server level.

Step 2: Make a Forensic Copy Before Touching Anything

This is the step most people skip. Don't.

Before you restore a backup, before you delete files, before you change anything — make a complete copy of the compromised site as it currently exists. Files and database. Store it somewhere separate from your regular backups.

This copy is your evidence. It tells you what the attacker changed, what backdoors they left, how they got in. Without it, you can clean the infection and restore the site and have no idea whether the vulnerability still exists. That's how sites get re-hacked.

Step 3: Notify Your Hosting Provider

Contact your hosting provider and tell them what happened. They have server-level logs that your Drupal admin interface doesn't show — IP addresses, access patterns, file modification timestamps. That information is critical to understanding how the attacker got in.

Step 4: Change Every Password

• Drupal admin account passwords

• Hosting control panel (cPanel, Plesk, or equivalent)

• FTP and SFTP account passwords

• Database passwords

• Email accounts associated with the site

Then check the Drupal user list for accounts that shouldn't be there. Attackers frequently create new admin accounts as a backdoor. Any unrecognized account with elevated permissions should be blocked and investigated.

Step 5: Identify the Infection

There are several places malicious code typically lives:

Modified core and module files

Compare your current files against known-good copies from Drupal.org. The Hacked! module automates this comparison. Any file that differs from the official release is suspect.

Database content

Attackers often inject code into the database rather than the file system. Search for eval(), base64_decode(), and document.write() across all tables — especially body fields of nodes, blocks, and user profiles.

Backdoor files

Attackers leave backdoor files to maintain access after cleanup. Check upload directories, temp directories, and anywhere file write permissions exist. These are often disguised to look like legitimate Drupal files.

Admin interface content

Check blocks, views, and custom PHP code added through the admin interface. The PHP filter module in older Drupal versions allowed code execution through the admin UI — a common attack vector on Drupal 7 sites.

Step 6: Clean or Restore

Option A: Restore from a clean backup

If you have a backup from before the compromise and are confident about when the attack occurred, restoration is faster and more reliable than manual cleaning. After restoring, apply all security patches immediately — restoring to an unpatched state means restoring to the vulnerability that allowed the attack.

Option B: Manual cleanup

Replace all Drupal core files with clean downloads from Drupal.org. Do the same for contributed modules. Clean the database manually, reviewing every table for injected content. If the infection is widespread, restoration from an older backup with content migrated forward is usually faster.

Step 7: Find and Close the Entry Point

This is the step that prevents re-infection. Check your hosting access logs for unusual patterns around the time of compromise:

• Requests to admin paths from unexpected IP addresses

• File upload requests to directories that shouldn't accept uploads

• Successful authentication from unusual locations

• Requests to known exploit paths for your Drupal version

For Drupal 7 sites: the entry point is almost always an unpatched vulnerability. Drupal 7 has had no security patches since January 5, 2025. Every vulnerability found after that date is permanently open. Recovery from this attack is not the end of the story — migration is.

Step 8: Harden Before Going Back Online

• Update Drupal core and all contributed modules to latest versions

• Remove unused, unmaintained, or unsupported modules

• Review file permissions — web server shouldn't write to directories it doesn't need

• Enable two-factor authentication on admin accounts

• Configure automated security update notifications

• Verify backups are working and stored offsite

Step 9: Check Google Search Console

If Google flagged your site, log into Search Console, check the Security Issues section, and submit a review request after confirming the site is clean. The safe browsing warning typically clears within 1 to 3 days after review. Search ranking recovery can take weeks to months.

A Note on Drupal 7 Specifically

Drupal 7 reached end of life January 5, 2025. No security patches since that date. Every vulnerability found after is permanently open — no fix is coming.

In May 2026, CISA flagged a critical Drupal vulnerability. Within 24 hours, Imperva tracked 15,000 attacks against 6,000 Drupal sites. Supported sites patched. Drupal 7 sites had nothing to apply.

Recovering and returning to exactly the previous state is a temporary measure. Migration is the only sustainable path.

Common Questions — Answered Directly

How do I know if my Drupal site has been hacked?

Common signs: unexpected redirects to unfamiliar domains, content you didn't add, Google Search Console flagging security issues, your hosting provider sending a malware notification, admin users you don't recognize, or a sudden drop in search traffic. Many compromised sites appear completely normal to visitors while serving malicious code to search engine crawlers — which is why regular security scans matter more than a visual check.

How do hackers get into Drupal sites?

The most common entry points in 2026 are unpatched vulnerabilities in contributed modules, weak or reused admin passwords, compromised FTP credentials, PHP file upload vulnerabilities in older themes, and SQL injection on sites running unsupported Drupal versions. Sites on Drupal 7 are particularly exposed — no security patches since January 5, 2025, meaning every vulnerability found since remains permanently open.

Should I restore from backup or clean a hacked Drupal site manually?

Restore from backup if you have a clean copy from before the compromise. Manual cleanup is necessary when no clean backup exists or recent content must be preserved. In both cases, identify and close the entry point before going back online — restoring without doing this means the site will be re-hacked.

How do I remove malware from a Drupal database?

Open your database admin panel (PHPMyAdmin or Adminer) and search for common malicious patterns: eval(), base64_decode(), document.write(), and iframe tags with external sources. Check body fields of nodes, blocks, and user profiles. If the infection is widespread, restoration from a clean backup is more reliable than manual database cleaning.

How long does it take Google to remove a hacked site warning?

After cleanup and a Search Console review request, the safe browsing warning typically clears within 1 to 3 days. Search ranking recovery from the security flag can take weeks to months, depending on how long the site was compromised.

Can a Drupal 7 site be made secure without migrating?

Temporarily, but not sustainably. Drupal 7 has had no security patches since January 5, 2025. Any vulnerability found after that date is permanently open — no patch is coming. Commercial long-term support providers offer Drupal 7 core patches beyond EOL, but contributed module coverage is inconsistent. Migration to a supported Drupal version is the only sustainable path.

What Drupal modules help prevent hacking?

The most useful security modules for Drupal in 2026: Security Review (automated configuration checks), Upgrade Status (flags modules without security coverage), Login Security (rate-limits brute force attempts), and Password Policy (enforces strong password requirements). Keeping core and all contributed modules updated is more effective than any individual security module.

How long does Drupal hack recovery take?

A straightforward infection with a clean recent backup: 4 to 8 hours. A complex infection requiring manual database cleaning and backdoor hunting: 1 to 3 days. Recovery from a hack where the Drupal version is end-of-life and migration is required: 6 to 16 weeks for a mid-size site.

Drupal Hack Recovery Checklist — Quick Reference

• Take site offline immediately

• Make forensic copy of all files and database BEFORE cleaning

• Notify hosting provider — request server-level access logs

• Change all passwords: admin, hosting, FTP, database, email

• Check for unauthorized admin accounts in Drupal user list

• Scan files using Hacked! module vs Drupal.org originals

• Search database for eval(), base64_decode(), iframe injections

• Hunt for backdoor files in upload and temp directories

• Restore from clean backup OR replace all core and module files

• Identify and close the entry point using hosting access logs

• Apply all security patches before going back online

• Submit review request to Google Search Console if flagged

• Set up automated backup, scanning, and patch notifications

Get help now → drupalify.com/contact