One morning, I woke up, grabbed my coffee, and checked my website and to my shock, I nearly spit my coffee. My WordPress site was completely blank.
No homepage. No content. Just the White Screen of Death (WSOD).
My first thoughts were a mix of confusion and panic. Did my hosting provider suspend my site? Did I accidentally mess up some files? Was my site hacked? As a WordPress site owner, this was my worst nightmare. A downed site means losing visitors, revenue, and reputation. Not knowing what had happened overnight made things even worse.
I use Wordfence Security to monitor my site, so I quickly tried to access wp-admin to investigate. But that was blank too!
It seemed like a dead end. My latest backup was a week old, meaning restoring it would erase my newest content and updates. Instead of jumping to a backup restore, I decided to troubleshoot and fix the issue manually.
What did I do to debug the error?
But first, we must know what is debugging?
Debugging – Debugging an error means finding and fixing the problem in a program or website that is causing it to malfunction. It involves identifying the issue, understanding what caused it, and then applying a solution to make things work correctly again.
Enabling Debug Mode In WordPress
Since no error messages were appearing, I knew the first step was to enable WP_DEBUG mode to reveal any hidden errors.
How to Enable WP_DEBUG Mode in WordPress
- Log in to your hosting panel (cPanel, Plesk, or your hosting file manager) or use FTP/SFTP.
- Navigate to your WordPress root directory (usually public_html).
- Locate and open the wp-config.php file.
- Find the line that says:
define(‘WP_DEBUG’, false);
- Change false to true or add the following code if it’s missing:
define(‘WP_DEBUG’, true);
- Save the file and refresh your website.
After enabling debugging, I refreshed my site and finally saw an error message. It pointed to a specific plugin that was causing a 500 Internal Server Error.
To fix it, I accessed my WordPress files via File Manager. Navigated to the wp-content/plugins/ directory. Found the suspected plugin folder and renamed it to: [Plugin-Disabled]. Reloaded my site, and voilà! I could finally access wp-admin again.
With dashboard access restored, I went to Wordfence Security logs to check what happened.
The infected files included:
- wp-settings.php
- wp-blog-header.php
- index.php
These are essential WordPress files, and any corruption can break the entire site.
The malware was obfuscated, so it was easily distinguishable from the legitimate code. I manually removed the suspicious code, ensuring the files were clean.
After cleaning the malware, I noticed that the compromised plugin was outdated. A new critical security patch had been released, but I hadn’t updated it. I immediately updated the compromised plugin and made sure all other outdated plugins and themes were up to date as well.
Re-Coring WordPress (Replacing Core Files)
Even after cleaning the infection, I was skeptical. What if the attacker left a backdoor?
To ensure my WordPress installation was completely clean, I decided to replace my WordPress core files.
How to Replace WordPress Core Files Safely:
- Check Your WordPress Version:
- Go to wp-includes/version.php and check your version.
- You can also find it inside WordPress Dashboard (if accessible), by clicking on the WordPress logo from the top left corner of the screen.
- Download a Fresh Copy of WordPress:
- Visit WordPress.org and download the latest version.
- Extract & Replace Core Files:
- Extract the ZIP file on your computer.
- DO NOT upload the wp-config.php file and wp-content folder (to avoid overwriting themes/plugins).
- Upload and replace everything else via FTP/File Manager.
- Recheck Site Functionality:
- Ensure everything is working fine.
Extra Steps to Prevent Future Attacks
- Set Up a Web Application Firewall (WAF)
A WAF blocks malicious traffic before it reaches your site. I recommend using Sucuri’s Website Firewall to protect against future attacks. - Use Two-Factor Authentication (2FA)
Enabling 2FA on wp-admin ensures that even if an attacker steals your password, they can’t log in without your second authentication method. - Regular Backups
Always maintain regular backups so that you can restore your site to a safe checkpoint in case there’s some unusual activity and you lose your site content.
Conclusion: What I Learned from This Nightmare?
This incident taught me a lot about website security. Regular backups are essential. If my last backup had been yesterday instead of a week ago, I wouldn’t have worried about losing data. Keeping plugins and themes updated is non-negotiable. The malware entered through an outdated plugin that had a known security flaw, and I should have enabled automatic updates for critical plugins.
Malware can hide in core files. Attackers often target wp-settings.php, index.php, and other core WordPress files. Running security scans with Wordfence, MalCare, or Sucuri SiteCheck can help detect threats early. A firewall could have prevented this attack before it happened. If I had a WAF in place, this whole incident might have been avoided.
Now, my website is secure again, and I’ve taken the right steps to prevent this nightmare from happening again.
Stay tuned to Malvirus for regular updates on website security, malware removal, and best practices!
