The Core Reinstall Myth: Why Overwriting WordPress Never Cleans a Hack

A frantic agency founder called me on a Tuesday morning last October. His team had spent eighteen hours straight "fixing" a compromised client site. Their playbook was the same one you read in every generic, surface-level wordpress tutorial across the internet: pull down a fresh wordpress download from the official repo, blow away wp-admin and wp-includes, overwrite the core files, and update every plugin to the wordpress latest version.

They high-fived, invoiced the client, and went to sleep. Nine hours later, Google Chrome flagged the site as deceptive. The rogue redirects were back.

I see this exact sequence twice a month at GuardLabs. It stems from a fundamental misunderstanding of how modern malware operates. Reinstalling core gives developers a warm feeling of productivity, but in real incident response, it is the equivalent of repainting a wall to put out a fire behind the drywall.

Attackers Do Not Care About Your Core Files

Attackers figured out years ago that altering core WordPress files is amateur hour. Core files get audited by scanners like Wordfence. Core files get wiped during regular updates. If a threat actor wants persistent access, the last place they put their primary payload is inside wp-includes/formatting.php.

They live in the dark corners. They inject obfuscated loaders into the uploads directory, disguising PHP scripts as image headers. I once found a full web shell nested inside a forged SVG of the wordpress logo sitting directly inside /wp-content/uploads/2023/04/. The image rendered fine in the browser, but an executed POST request with a specific cookie triggered an eval() string tucked inside an XML comment.

Wiping core does nothing to touch that. And if you blindly copy your uploads folder over to a new server without inspecting every single non-media extension, you just migrated the attacker along with your media library.

The Real Battleground: Plugins and the Database

Over 90% of breaches we remediate enter through vulnerable wordpress plugins. It is rarely WordPress core that fails; it is the sprawling web of third-party code layered on top of it. A typical target is wordpress elementor setups coupled with five or six unvetted third-party addon packs. A single unauthenticated arbitrary file upload flaw in an abandoned addon gives an attacker the keys to the kingdom.

Once inside, they establish persistence in places file-replacement never touches:

First, the database. Attackers routinely inject serialized payloads into the wp_options table under autoloaded keys like recently_activated_plugins or obscure transients. When WordPress boots, that code executes before your theme or security plugins even initialize.

Second, rogue administrative accounts created directly via SQL queries, often hidden from the user table in the dashboard through simple hook injections in a must-use (MU) plugin that your FTP client never highlighted.

Third, rogue system cron jobs. If the web server permissions were sloppy, the exploit might have dropped a rootkit or a cron task directly on the Linux host. You can delete the entire webroot and rebuild it from scratch; thirty minutes later, the Linux cron pulls the backdoor right back down from a remote command-and-control server.

How We Actually Clean an Infection

When panic sets in, non-technical site owners start searching everything from absolute basics like wordpress was ist das to desperate queries for a static wordpress alternative. But WordPress itself is not inherently broken. The remediation protocol just has to be forensic, not hopeful.

We do not clean sites in place on the live server. That is a guaranteed way to miss something while alerting the attacker that you are onto them. Our process is strict:

1. Complete Isolation. We take an encrypted snapshot of the entire filesystem and database, kill public web traffic, and pull the environment down locally. Running the infected site inside an isolated wordpress docker container lets us inspect network traffic, track rogue outbound curls, and detonate files safely without risking production infrastructure or server IPs.

2. Checksum Verification. We write automated scripts to compare every installed component against official repository checksums. Whether you audit manually or wire local inspection through a wordpress mcp setup to run AST (Abstract Syntax Tree) queries across suspect PHP files, every line of code that diverges from clean upstream repositories gets quarantined.

3. Database Sanitization. We inspect all autoloaded rows in wp_options, scan for base64 strings and suspicious hex encodings, audit the wp_users and wp_usermeta tables for stealth roles, and drop malicious triggers.

4. Sealing the Entry Vector. A cleanup without root-cause analysis is a waste of time. We parse server access logs around the timestamp of the earliest infected file to pinpoint the exact POST request that breached the system. Until that vulnerability is patched, the site stays offline.

Stop wasting time reinstalling core files and hoping the nightmare goes away. If you are dealing with a reinfection loop or want a battle-tested protocol to clean a compromised site permanently, review our методика восстановления взломанного WordPress-сайта to see the exact isolation, audit, and hardening pipeline we deploy for client incidents.