Last week, I discovered that my personal website was showing a blank page. What followed was a deep investigation that uncovered a full server compromise, all because of a single pirated WordPress plugin on a different website hosted on the same server.

I'm sharing this story because I want other developers and website owners to learn from my mistake. If you run multiple websites on shared hosting, please read this carefully.

The Symptoms It started innocently, my Laravel-based personal website at bishalsingh.com.np suddenly stopped loading. Just a blank white page. No error messages, no clues.

When I dug into the Laravel error logs, I found:

Cannot assign array to property Filament\Notifications\Livewire\Notifications::$isFilamentNotificationsComponent of type bool This looked like a simple package compatibility issue. But it was just the tip of the iceberg.

The Discovery While investigating, I found a suspiciously named file: c1ca9de231f3.php. That's not a file I created. Files with random hex names are a classic sign of webshells - backdoor scripts that give attackers remote access to your server.

I searched deeper and found malware scattered across my entire server:

c1ca9de231f3.php - planted in 5 different directories txets.php and 0a77bcdfc3.php - in the public directory Fake duplicate directories (images/images/, routes/routes/) containing hidden cache.php and index.php files My .htaccess files had been replaced with WordPress-style rewrite rules In total, I found over 15 malicious files spread across both my Laravel project and WordPress site.

The Root Cause: A Pirated WordPress Plugin The attacker got in through a pirated (nulled) version of Elementor Pro installed on a WordPress site hosted on the same cPanel account.

Here's how it worked:

The nulled Elementor Pro plugin came pre loaded with a backdoor Automated bots scan the internet for these backdoors constantly Once they found it, they had code execution on my server On shared hosting, all sites run under the same Linux user The attacker could read and write files across all my websites The attack chain was devastatingly simple:

Pirated WordPress plugin (with hidden backdoor) → Automated bot finds and exploits it → Full file system access as my cPanel user → Malware planted across ALL websites on the account → .htaccess files replaced, database credentials exposed → Complete server compromise What the Attacker Did With full server access, the attacker:

Planted webshells in multiple directories for persistent access Replaced .htaccess files to break my Laravel site and potentially redirect traffic Modified WordPress core files (functions.php, plugin.php, etc.), eventually breaking WordPress itself Changed database passwords, locking me out of phpMyAdmin Injected JavaScript interceptors that captured all WebSocket, fetch, and XHR traffic from visitors' browsers Created duplicate directories (routes/routes/, images/images/) to hide malicious files where nobody would look Locked file permissions on modified files to prevent easy cleanup The Cleanup Recovery took several steps:

Identified all malicious files and deleted them Restored the correct Laravel .htaccess rules Re-downloaded clean WordPress core files (after fixing permissions the attacker had locked) Changed all passwords -> WordPress admin, database users, cPanel Deleted the pirated Elementor Pro plugin Updated all remaining plugins and WordPress core Fixed file permissions across the entire server Lessons Learned

1. Never Use Pirated/Nulled Plugins or Themes This is the single most important takeaway. Nulled plugins are the #1 attack vector for WordPress sites. They save you $50 but can cost you everything. If you can't afford a premium plugin, use a free alternative.

2. Don't Host Multiple Sites on the Same cPanel Account On shared hosting, all your sites share the same Linux user. One compromised site means all sites are compromised. Either:

Use separate cPanel accounts per site Move critical sites to their own VPS Use platforms like Laravel Forge, Railway, or Vercel for isolation 3. Never Use "admin" as Your Username My WordPress admin username was literally admin. This is the first username that brute-force bots try. Always use a unique username.

4. Set APP_DEBUG=false in Production With debug mode on, anyone who triggers an error can see your database credentials, file paths, API keys, and full stack traces displayed on screen.

5. Keep Everything Updated Outdated WordPress plugins, themes, and PHP packages all have known vulnerabilities that automated scanners exploit daily.

6. Monitor Your Server Set up basic monitoring => even a simple uptime check would have alerted me to this issue sooner. Tools like UptimeRobot (free), Oh Dear, or Laravel's built-in health checks can notify you immediately when something breaks.

For Developers: Quick Security Checklist No pirated plugins or themes anywhere on your server Unique, strong passwords for all admin accounts APP_DEBUG=false on all production environments File permissions: directories at 755, files at 644 Different hosting accounts or VPS for different projects Regular updates for all dependencies Uptime and error monitoring configured Regular backups (that you've tested restoring) Final Thoughts It's easy to think "it won't happen to me" - I certainly did. I'm a developer who builds security features for other applications, yet my own server was compromised through the most basic attack vector: a pirated plugin.

The internet is full of automated bots scanning for vulnerabilities 24/7. Security isn't optional, and shortcuts always have a cost.

If you're running WordPress on shared hosting right now, please take 10 minutes to audit your plugins. Delete anything you didn't install from an official source. It might just save you from going through what I did.

Stay safe out there. 🛡️