Here’s a painful truth I’ve seen on real client sites: you can remove malware from files and still get reinfected. The second wave usually comes from the database—especially once the attacker keeps access via wp-config.php, weak user accounts, or sloppy permissions on your WordPress folders.
“Database-first security” is the fix. It means you secure the connection (wp-config.php), the people (WordPress users and roles), and the locks (file and database permissions) so attackers can’t quietly slip back in. If you’re cleaning a hacked WordPress site, this is the part people skip—and then they’re back to rebuilding.
As of 2026, most reinfection patterns still follow the same playbook: change a few database rows, create a backdoor admin, and keep the credentials working. Your job is to break that chain at the database level, not just in the theme folder.
What “Database-First Security” means for WordPress reinfection control
Database-first security is an approach where you secure WordPress in the order that attackers usually return: configuration → users → database and file permissions → then content cleanup.
WordPress runs on PHP and files, but your real “state” lives in the database. That includes user accounts, admin roles, plugin settings, and sometimes injected code that runs at page load. When a site gets reinfected after a cleanup, it often means the attacker didn’t only edit files—they also left a working path inside the database.
In my incident response work, I’ve found three “reinfect and repeat” causes more often than any others:
- wp-config.php is still usable by the old attacker or has readable secrets on the server.
- A malicious admin user was created (or an existing user’s role got changed) and admins aren’t checking the right places.
- Permissions are too open, so a hacked process can write new backdoors even after you delete the first files.
If you do only file cleanup, you’re playing whack-a-mole. If you do database-first security, you’re changing the rules.
Secure wp-config.php first: stop credential leaks and secret exposure
The fastest way to stop reinfection is to protect the keys and database details in wp-config.php before you touch plugins or themes.
wp-config.php is where WordPress stores important data like the database name, database user, and the table prefix. It also holds the authentication salts that help secure logins. If attackers can read it easily, they can plan attacks better. If they can change it, they can redirect WordPress to a different database or weaken protections.
Lock down wp-config.php permissions (and confirm they stay locked)
Correct permissions keep the file from being read or edited by the wrong users on the server.
Typical best practice (varies by hosting):
- wp-config.php permissions: 640 or 600
- Owner: the correct system user for your site (often your hosting account)
- Group: should not be broad, only what your web server needs
What I do after a cleanup: I check the permissions, then I check the ownership, then I check whether your hosting control panel is overwriting them. Some managed hosts reset permissions after updates. That’s good when it resets to secure defaults. It’s bad when it resets to “world-readable.”
Common mistake: people “fix” reinfection by changing wp-config.php permissions once, then they install a plugin that triggers a permission reset. You need a repeatable checklist.
Use unique database credentials and remove shared power
Your database account should have only the permissions WordPress needs—nothing extra.
Many hacked sites use the same database user across multiple WordPress installs, or they share credentials with staging, testing, and production. If one install gets hacked, the same database user can often be used to reach other sites.
In 2026, I recommend:
- Create a dedicated database user for this WordPress site.
- Grant only the required privileges (usually SELECT/INSERT/UPDATE/DELETE/CREATE/ALTER as needed by WordPress; your host can guide exact privileges).
- Rotate the database password after cleanup (and after any incident).
Database passwords are not “set and forget.” If your site gets hacked, rotate the password even if you think the damage is gone.
Confirm wp-config.php is not writable by the web server
If your web server can write to wp-config.php, you’re giving attackers a restore point.
“Writable” is where reinfection gets easy: the attacker can use a script to modify config settings or inject new values, then the site keeps running while the next payload is planted.
Check your file mode and ownership. If you’re on cPanel or similar, you can confirm via File Manager and then verify with SSH using ls -l. If you’re on locked-down hosting without SSH, ask support to check write access for the PHP user running your site.
If they push back, say this plainly: you need wp-config.php to be read-only for the web process.
Lock down WordPress users and roles to stop backdoor admins
Securing users stops the most common reinfection path: a backdoor account that still logs in after you delete the first files.
WordPress itself is simple: if an attacker has a valid login (or can create one), they can edit plugin files, install new plugins, change theme code, and update database settings. Reinfection doesn’t need fancy hacking. It just needs an account and working permissions.
Run a “user integrity” check: roles, creation dates, and last login
After a cleanup, I always verify user history like I’m looking for evidence, not convenience.
Check these things in Users > All Users:
- New accounts created during the suspected hack window
- Unexpected roles (authors and editors being promoted to administrator)
- Last login dates that don’t match your real activity
If you don’t see creation dates or last login easily, use a plugin like “WP Security Audit Log” or ask your host if they have login logs. Since we’re aiming for database-first security, look at the database too (more on that below).
Remove attackers safely: delete, then confirm database rows
Deleting an admin user from the WordPress dashboard is not always enough.
Some malware adds “ghost” entries: it creates an admin-like user or changes role data so the user looks fine in the UI but still has special capabilities. If you only delete the visible part, the underlying data can survive.
My process for high-confidence cleanup looks like this:
- Delete suspicious users from the WordPress admin UI.
- Rotate the site admin passwords (for everyone who needs access).
- Check the database tables for leftover role/capability entries.
- Re-check again after you restore a clean plugin/theme state.
This ties into your database-first approach: the “truth” lives in the database tables, not just the admin screen.
Reset authentication salts and force logout on every user
Auth salts are keys WordPress uses to secure sessions and login cookies.
If there was a real breach, change these values in wp-config.php. WordPress provides a generator for secure salts. Once changed, all existing login cookies stop working, which forces everyone to log in again.
Practical step: after salt reset, ask your users to log out and log back in. If you have an SSO plugin, make sure you understand how it handles sessions.
If your site uses caching, purge it after salt changes to avoid odd login loops.
Use MFA and limit who can install plugins
Two-factor authentication is not a cure-all, but it turns “stolen password” attacks into something much harder.
Turn on MFA for all administrators. Then reduce who gets admin rights. Many hacked sites happen because “whoever needed it” got an admin account “just for a bit.” That bit becomes permanent.
For small businesses, I like this rule: only one or two people should be administrators. Everyone else should be editors or authors with limited permissions.
Harden permissions and prevent write access that causes reinfection
Permissions are the difference between “cleanup works” and “cleanup gets undone overnight.”
Attackers often need a way to write files or change plugin/theme code. If your server permissions are too open, any PHP execution path (malicious or accidental) becomes dangerous.
Set safe file permissions for WordPress core, themes, and plugins
Here’s a practical, common target configuration (always confirm with your host, because setups differ):
| Location | Typical File Permission | Typical Directory Permission |
|---|---|---|
| wp-admin, wp-includes, wp-content | 644 | 755 |
| uploads | 644 | 755 (or host-specific) |
Why this matters: the web server should be able to read files it needs, and it should be able to write only where WordPress needs to write (like uploads). Core files and config should not be a write target.
What most people get wrong: they make everything 777 during a troubleshooting moment, then forget to change it back. That’s basically handing attackers a blank pen.
Disable dangerous PHP execution in upload folders
Uploads should never execute as PHP. If your server allows it, attackers can drop a .php file in uploads and run it.
Common ways to prevent this include:
- Using a web server rule (like Nginx/Apache config) to block PHP in
/wp-content/uploads - Using an .htaccess rule (Apache) that denies PHP execution in uploads
- Confirming with your host’s security guide
If your host uses Nginx plus a control panel, ask support to confirm “PHP execution disabled in uploads.” It’s not enough to assume.
Verify scheduled tasks (wp-cron) and server cron jobs
Attackers love scheduled jobs because they can replant files while you sleep.
Check:
- WordPress scheduled events in your admin area (if you have a security plugin that shows them)
- Your host’s server-level cron jobs
- Any code that calls suspicious URLs or base64 strings
If you see weird scheduled tasks after you think you cleaned everything, it’s a sign the reinfection mechanism is still alive—often tied to database settings or newly created admin accounts.
Database cleanup that actually stops reinfection: what to check
Database cleanup should be more than “delete suspicious files.” You need to check database tables for persistence.
During real malware removal engagements, I’ve seen reinfection come from a few repeat offenders: changed option values, injected code in post meta, and new admin capability entries.
Scan for changed options and suspicious values
WordPress stores many settings in the options table (often named wp_options, with your table prefix).
Look for:
- Unexpected values related to theme/plugin settings
- Options that store encoded scripts or remote URLs
- Changes in site URLs or rewrite rules (sometimes to redirect traffic)
Use a database tool you trust (like phpMyAdmin or Adminer). If you’re comfortable with it, run targeted queries using your table prefix. If you’re not, don’t guess—wrong deletes can break the site.
Check usermeta and capability tables for hidden power
When attackers want reinfection power, they change capabilities, not just visible roles.
Depending on your database prefix, key areas include:
- usermeta (stores capabilities and related metadata)
- users (lists accounts)
Common signs include:
- Unexpected capability strings
- A user ID that looks normal but has admin-like permissions
- Users created without a matching record in your admin audit trail
This is where database-first security earns its name. You’re verifying the “real authorization” state, not just what the UI shows.
Search for injected code in posts and postmeta
Malware often injects code into posts, pages, or meta fields so it runs when a page loads.
Search in tables like:
- posts (content fields)
- postmeta (custom fields)
Look for patterns like base64 blobs, obfuscated strings, or references to suspicious external domains. If your site shows spam content or redirects, this step becomes urgent.
Compare your database before/after using backups
If you have clean backups, a diff is gold.
In 2026, I strongly recommend keeping at least:
- A pre-incident database backup (even if it’s older)
- A backup made right after the site returns to normal
Then you can compare what changed. You don’t need to guess what’s malicious—you can prove what shifted during the attack window.
If you don’t have backups, create one now. Always.
People Also Ask: database-first security and reinfected WordPress sites
Why does my WordPress get reinfected after malware removal?
Your WordPress gets reinfected after malware removal when the attacker left persistence in the database, kept a backdoor account, or left a permission/path that still allows writing new files.
File cleanup alone doesn’t remove malicious database settings, role/capability changes, or scheduled tasks tied to options and usermeta. That’s why database-first security focuses on wp-config.php, users, and permissions first.
Can wp-config.php get hacked?
Yes. Attackers can edit wp-config.php if they get access to the server or if your file permissions allow it.
Less obvious: sometimes wp-config.php isn’t changed, but its secrets (like auth salts) are used to keep sessions alive. After a real incident, rotate salts and database passwords anyway.
What database table does WordPress use for users and roles?
WordPress stores users in the users table and role/capability details in the usermeta table (with your site’s table prefix).
If you’re doing database-first security, always check both. A user can look harmless in the UI but have capability entries that make them effectively an administrator.
How do I stop PHP execution in uploads?
You stop PHP execution in uploads by adding a server rule (Apache or Nginx) that denies PHP files in wp-content/uploads from running.
Then verify it with a test: upload a harmless test.php that prints a message and confirm it does not execute. If you don’t have access to server config, ask your host for the setting and confirmation.
Real-world scenario: the “cleaned files, still hacked” pattern I’ve seen
One time, a small business paid for a file cleanup and felt relieved… for 24 hours.
Then their contact pages started injecting hidden spam and a few visitors got redirected to sketchy pages. The theme and plugin files looked clean on the surface. When we checked the database-first angle, we found a new administrator created during the incident, plus a hidden option value that reloaded an injected snippet on page output.
We fixed it fast by doing three things in order:
- Locked down wp-config.php permissions and rotated database credentials.
- Removed the backdoor account and verified capability data in usermeta.
- Corrected folder permissions so uploads could not be used to drop executable code.
The lesson was clear: reinfection often happens because the “persistence layer” is in the database and permissions, not the files you deleted.
Step-by-step checklist: Database-first security for cleanup and prevention
Use this checklist during malware removal and prevention. It keeps you from missing the reinfection path.
Before you start (do this even if you’re in a rush)
- Create a full backup: database + files.
- Take the site offline or enable maintenance mode if you’re actively cleaning.
- Make sure you can still access the server (or at least phpMyAdmin) so you can validate changes.
Database-first hardening steps
- wp-config.php: set permissions (640 or 600), verify ownership, and rotate auth salts after the incident.
- Database credentials: rotate the database user password and confirm the database user is dedicated to this site.
- Users: audit admin accounts, delete suspicious users, reset passwords for legit admins, and force logout via salt change.
- Capabilities: verify usermeta for unexpected admin-like permissions.
- Permissions: set file/directory permissions back to safe values and confirm uploads cannot run PHP.
- Scheduling: review scheduled events and cron jobs for suspicious triggers tied to options or plugins.
- Re-scan: after changes, confirm no new files appear and no new admin users show up within the next few hours.
Tools and references that help (and the limits of each)
Security tools are useful, but they don’t replace database-first verification.
Security plugins for monitoring (good for early warning)
Plugins like Wordfence or similar scanners can detect known signatures, new admin users, and suspicious changes. They also help you spot the moment a new account appears. Still, I treat them as detection—not proof of full cleanup.
If the attacker uses a custom backdoor, the plugin may not catch it. That’s when database-first checks matter.
Database tools for verification (best for persistence)
phpMyAdmin/Adminer are common. They let you search for suspicious strings in your postmeta or options. They also let you verify what permissions and capabilities look like from the database’s point of view.
If you’re not comfortable running SQL queries, get help—but insist on checks in options, usermeta, and postmeta.
How this fits our wider WordPress Security and Malware Removal work
When we handle incident response, we don’t stop at “remove the malware.” We focus on the whole system: access, permissions, and reinfection prevention.
If you’re dealing with a current compromise, you’ll likely also need our guide on WordPress malware removal cleanup process. And if you’re trying to avoid the next incident, our WordPress hardening tips for small business sites pairs well with this database-first approach.
For real-world examples of how attackers persist, our hack case studies on reinfected sites show the exact failure points we see again and again.
Conclusion: stop reinfection by breaking the database persistence chain
Database-first security isn’t about being scary or technical. It’s about doing the checks that stop the “second wave” after cleanup.
If you want a simple takeaway: protect wp-config.php (permissions and secrets), audit and harden WordPress users (roles and capabilities), and lock down permissions so attackers can’t write new backdoors.
When you follow that order, you stop guessing. You fix the real reason reinfections happen—and your site stays clean long enough for your business to breathe again.
Featured image alt text (for your uploader): Database-First Security checklist securing wp-config.php and WordPress permissions to prevent reinfected sites