Home TechWriteUps WordPress Security
TechWriteUps

WordPress Security

3 min read

When WordPress Security Hits Home

I’ve built and managed multiple WordPress websites over the years, both for myself and for friends hosted under my domain. Everything was running smoothly until one day I noticed something unusual.

I couldn’t save my .htaccess file. Every time I updated it, the changes would reset.

At first, it felt like a minor configuration issue. But after spending hours troubleshooting, I enabled WP_DEBUG and quickly realized something more serious was going on. My files had been compromised.

This wasn’t the first time either. It was the second incident within the same year.

The Reality of Shared Hosting

I’m running these sites on shared hosting with SiteLock enabled. All of my own projects were fully updated and maintained, but not every site on the server followed the same discipline.

That’s where the risk comes in.

On shared environments, one vulnerable site can become an entry point that affects others. Even if your own codebase is clean, outdated plugins, themes, or weak credentials on another site can expose the entire environment.

WordPress Security: The Bigger Question

WordPress started as a blogging platform, but today it powers everything from portfolios to full-scale eCommerce systems.

With that level of adoption, security should be airtight by default.

Core directories like wp-admin and wp-includes are critical and should ideally have stronger built-in integrity checks. While WordPress does a lot right, it still relies heavily on developers and site owners to enforce best practices.

There’s no native, always-on file integrity monitoring out of the box, which feels like a gap for such a widely used CMS.

What Helped Me

To get things under control, I started using a security plugin like Wordfence and Anti Malware.

It helped with:

  • Monitoring file integrity
  • Checking folder permissions
  • Alerting me to suspicious changes

It didn’t magically solve everything, but it gave me visibility, which is critical when dealing with compromised environments.

Recovery Approach I Followed

Once I confirmed the breach, I took a clean rebuild approach:

  1. Deleted all core WordPress folders (wp-admin, wp-includes)
  2. Kept wp-content (themes, uploads) after reviewing it carefully
  3. Replaced core files with a fresh WordPress download
  4. Removed unused plugins and themes
  5. Reset permissions and credentials
  6. Updated everything immediately
  7. Disabled xmlrpc.php to reduce the attack surface
  8. Blocked public access to .git directories
  9. Implemented reCAPTCHA on login and forms
  10. Enabled login attempt limits and temporary bans on failures
  11. Reset all credentials (admin, database, FTP, hosting)
  12. Corrected file and folder permissions
  13. Used simple history to monitor changes in admin

This method ensured I wasn’t leaving any infected core files behind.

Key Takeaways

  • If something feels off in WordPress, it probably is
  • Shared hosting increases your exposure
  • Updates are necessary but not sufficient
  • File integrity monitoring is essential
  • One weak site can compromise others

Final Thoughts

WordPress itself isn’t inherently “insecure,” but its ecosystem can be.

The flexibility that makes it powerful also makes it vulnerable when not managed properly.

If you’re hosting multiple sites, especially for clients or friends, security becomes a shared responsibility. One outdated plugin or weak password can create a chain reaction.

Since then, I’ve made it a habit to actively monitor my environments instead of assuming everything is fine.

Because in WordPress, silence doesn’t always mean safety.