Table of Contents
- Why WordPress Sites Get Hacked in 2026
- What You’ll Need Before You Start Hardening
- Step 1: Lock Down Access With Two-Factor Authentication
- Step 2: Choose the Best WordPress Security Plugins
- Step 3: How to Scan WordPress Site for Malware
- Step 4: Harden Core, Database, and File Permissions
- Step 5: How to Fix a Hacked WordPress Site
- Advanced Protection: Headless WordPress, Automated Auditing, and Supply Chain Security
- Frequently Asked Questions
Last Updated: September 14, 2026
Why WordPress Sites Get Hacked in 2026
WordPress powers a huge share of the web, and that popularity makes it a permanent target. According to HideMyWP Ghost’s 2025-2026 security data, 11,334 new WordPress vulnerabilities were recorded in 2025, a 42% year-on-year increase. Roughly 13,000 WordPress sites are compromised every day, which works out to about 4.7 million sites a year.
At Designworks NW, LLC, we’ve maintained or serviced over 200 websites, and the pattern behind most breaches is consistent: an outdated plugin, a weak admin password, or a login page left open to bots.
Below, we’ll show you exactly how to protect WordPress site from hackers with a five-step process you can run this week, plus a recovery protocol for the day something slips through.
The Numbers Behind the Surge
Attacks on WordPress rose 28% in 2026 compared to 2025, driven largely by a jump in SQL injections and zero-day exploits, according to Imran Ahmed’s 2026 WordPress security analysis on LinkedIn Pulse. AI-driven components now feature in roughly 45% of attacks, which explains why scanning tools flag more false negatives than they used to.
Here’s the part most guides skip: 43% of WordPress vulnerabilities can be exploited without any authentication at all, per Colorlib’s WordPress hacking statistics. You don’t need a stolen password to be a target. You need an unpatched plugin.
Traditional web application firewalls block only about 12% of WordPress-specific attacks on their own. Relying on a WAF as your only defense leaves the vast majority of known attack patterns unaddressed.
What You’ll Need Before You Start Hardening
Gather these first:
- Administrator access to your WordPress dashboard and hosting control panel
- A current full backup (files and database), stored off-server
- SFTP or file manager access for
wp-config.phpedits - A password manager for rotating credentials
- A 60-90 minute maintenance window
One caveat: if your site runs custom plugins or a heavily modified theme, test changes on staging first. A hardening step that breaks checkout costs more than the vulnerability it closes.
Step 1: Lock Down Access With Two-Factor Authentication
Two-factor authentication is the single highest-return change you can make, because it neutralizes the most common attack vector outright. Research cited by [Dev.to’s 2026 WordPress security(/2026/08/wordpress-security-best-practices-2026/) roundup | dev.to] estimates basic hygiene like strong access controls and regular updates stops more than 90% of attacks.
How to Enable Two-Factor Authentication on WordPress
- Install a 2FA plugin (Wordfence Login Security, WP 2FA, or Google Authenticator for WP all work).
- Enforce 2FA for every Administrator and Editor account, not just your own.
- Use an authenticator app rather than SMS, which is vulnerable to SIM swapping.
- Store backup codes offline.
- Apply least privilege: downgrade anyone who doesn’t need admin rights to Editor or Author.
A common mistake is enforcing 2FA only on the main admin account. Attackers enumerate usernames and hit the weakest privileged login they can find.
Step 2: Choose the Best WordPress Security Plugins
The best WordPress security plugins combine firewall, malware scanning, and login protection in one package, because juggling separate tools creates gaps. Wordfence, Sucuri Security, and Solid Security are the most widely deployed.
| Plugin | Core Strength | Best For |
|---|---|---|
| Wordfence | Endpoint firewall + live threat feed | Sites wanting active IP blocking |
| Sucuri Security | Remote scanning + CDN-level WAF | Sites behind a proxy or CDN |
| Solid Security | Strong login hardening + 2FA | Small teams wanting simplicity |
A properly configured firewall blocks 95% of known threats out of the box, according to Wordfence’s Q1 2026 Threat Intelligence Report. The catch is “properly configured.” Default settings on any of these plugins leave real gaps, so budget time to tune rules after install.
Run only one security plugin with a firewall. Two firewalls fighting over the same request cycle causes false positives that lock out legitimate customers, which is a support nightmare during a sale.
Step 3: How to Scan WordPress Site for Malware
Scanning for malware means comparing core files, themes, and plugins against known-good versions and checking for injected code. Run a full scan monthly at minimum, and immediately after any plugin update.
Most security plugins include a scanner, but results need interpretation. Watch for modified core files, unfamiliar admin users, and unexpected scheduled tasks. A backdoor often hides as a harmless-looking PHP file in your uploads folder, so scan timestamps, not just names.
For a second opinion, run an external scan through a service like Sucuri’s site checker, different engines catch different signatures, and one clean result doesn’t guarantee a clean site.
Step 4: Harden Core, Database, and File Permissions
Hardening means reducing what an attacker can reach if they get in, the layer that buys you time when prevention fails. It breaks into four jobs: core and plugin hygiene, database hardening, file-system permissions, and the WAF in front of it all.
Update Core, Plugins, and Themes, Then Delete What You Don’t Use
Vulnerability patching is the cheapest security work you will ever do, most breaches come from an outdated plugin, not a clever exploit. Two rules cover the bulk:
- Enable automatic minor core updates (they ship security fixes only) and apply major releases within a week of a stable point release.
- Delete inactive plugins and themes entirely. Deactivated code still sits on disk, still gets flagged by scanners, and still executes if an attacker can reach it directly. Deactivation is not removal.
If your host offers staging, push updates there first when a plugin touches checkout, forms, or membership logic.
Database Hardening: Prefix, User Privileges, and Remote Access
Four changes close most of the database attack surface:
- Change the table prefix from the default
wp_to something unique. This defeats the automated SQL injection payloads that assume the default, the majority of what hits a typical site. - Use a dedicated database user with only the privileges WordPress needs (
SELECT,INSERT,UPDATE,DELETE). Never run WordPress asroot. - Disable remote database access unless your host requires it. If your database is reachable from the public internet, it will be probed.
- Rotate the database password whenever you rotate admin credentials, and update
wp-config.phpin the same window.
Changing the prefix on a live site requires updating $table_prefix in wp-config.php and renaming every table, do this on staging first, or use a plugin that renames atomically. A partial rename takes the site down.
wp-config.php: Move It, Lock It, and Add the Right Constants
wp-config.php holds your database credentials and authentication salts. Treat it as the most sensitive file on the install.
- Move it above the web root if your host allows it. WordPress looks one directory up automatically, and the file becomes unreachable by URL.
- Set permissions to 600 or 640 so only the owner (and the web server group, if required) can read it.
- Disable the built-in file editor with
define('DISALLOW_FILE_EDIT', true);. This removes the Appearance → Theme File Editor and Plugins → Plugin File Editor screens, a direct code-execution path if an admin account is compromised. - Disable file modifications during incidents with
define('DISALLOW_FILE_MODS', true);, a useful temporary lockdown, but it also blocks plugin and theme updates, so remove it once you are clean. - Force SSL in the admin with
define('FORCE_SSL_ADMIN', true);so credentials never travel over plain HTTP.
File Permissions and Directory Indexing
Permissions are where well-meaning guides cause outages. Safe defaults:
- Directories: 755. Files: 644. Never 777, not even temporarily, not even to “fix” an upload error.
wp-config.php: 600 or 640..htaccess: 644.wp-content/uploads: 755 for directories, 644 for files. If a plugin demands otherwise, that plugin is the problem.
Then turn off directory browsing. On Apache, add Options -Indexes to .htaccess; on Nginx, set autoindex off;. Without it, anyone can browse /wp-content/uploads/ and see every file you have ever uploaded, old backups, exported user lists, PDFs you assumed were private.
The Web Application Firewall Layer
A WAF inspects incoming requests and blocks known attack patterns before they reach WordPress. It is not a substitute for patching, but it buys you the window between disclosure and fix, exactly when most sites get hit.
Two deployment models matter:
- Endpoint WAF (a plugin like Wordfence or Solid Security) runs inside WordPress. It sees everything WordPress sees, including authenticated traffic, but cannot protect against a vulnerability in WordPress itself being exploited before the plugin loads.
- Cloud/DNS-level WAF (Sucuri, Cloudflare) sits in front of your server. It blocks attacks before they touch your host and absorbs volumetric traffic, but cannot inspect what happens after login.
Most hardened sites run one of each. The rule that matters: run only one firewall per layer. Two endpoint firewalls fighting over the same request cycle produce false positives that lock out legitimate customers.
Traditional signature-based web application firewalls block only a fraction of WordPress-specific attacks on their own, because most exploits now target plugin logic rather than known payload strings. Treat the WAF as a speed bump, not a wall. Patching is still the wall.
Verify, Don’t Assume
After hardening, confirm the changes took:
- Load
yoursite.com/wp-content/uploads/in a browser, you should get a 403, not a file list. - Try to reach
yoursite.com/wp-config.php, you should get a blank page or a 403, never source code. - Check that the Theme File Editor link is gone from the Appearance menu.
- Run a permissions audit through your host’s file manager or SFTP client and confirm nothing is 777.
A hardening pass you did not verify is one you cannot rely on.
Step 5: How to Fix a Hacked WordPress Site
Fixing a hacked WordPress site starts with containment, not cleanup. Take the site offline or into maintenance mode, then work through recovery in order.
Post-Hack Recovery Protocol
- Isolate. Put the site in maintenance mode and change all passwords, including hosting and database credentials.
- Snapshot. Take a forensic backup of the compromised state before you delete anything. You may need it to identify the entry point.
- Scan and remove. Run a full malware scan and remove malicious code, including backdoors hidden in uploads and inactive themes.
- Rebuild from clean sources. Reinstall WordPress core, themes, and plugins from official repositories rather than patching infected files.
- Close the entry point. Identify how they got in (outdated plugin, stolen credential, vulnerable theme) and fix it before restoring service.
- Restore and monitor. Restore clean content, then watch security logs daily for two weeks. Reinfection usually happens fast if the entry point remains open.
Advanced Protection: Headless WordPress, Automated Auditing, and Supply Chain Security
Three areas separate a hardened site from a well-defended one, and most guides skip all three. Each has concrete steps you can take this quarter.
Headless WordPress: New Attack Surface, New Rules
Headless WordPress moves the front end to a separate framework (Next.js, Astro, a mobile app) while WordPress serves content through the REST API or GraphQL. The public login page disappears, a genuine win, but the API becomes the new front door, frequently left unlocked.
The specific risks:
- Unauthenticated REST endpoints. By default,
/wp-json/wp/v2/userslists every author on the site, handing an attacker a ready-made username list for brute-force attempts. Restrict or disable user enumeration. - GraphQL introspection. If you run WPGraphQL, introspection is enabled by default in development and often left on in production, publishing your entire schema, every type, field, and mutation, to anyone who asks. Disable it in production.
- Token mismanagement. Headless setups authenticate with application passwords, JWT, or OAuth tokens. Long-lived tokens stored in client-side code are the equivalent of leaving your admin password in a public repo. Use short expirations, rotate on a schedule, and never ship a token to a browser that does not need it.
- CORS misconfiguration. A permissive
Access-Control-Allow-Origin: *on an authenticated endpoint lets any site make requests on behalf of a logged-in user. Restrict it to your known front-end origins. - The WordPress install itself is still there. Headless does not remove the admin, the plugin update cycle, or the database. Everything in Steps 1 through 4 still applies.
A practical baseline: require authentication on every endpoint returning anything other than published public content, disable introspection, restrict CORS to a known allowlist, and monitor API logs for unusual request volumes.
Automated Security Auditing vs. Manual Review
Manual audits happen once and get forgotten; automated ones catch the plugin vulnerability disclosed on a Tuesday while you’re on a client call.
What automation is good at:
- File-integrity monitoring, comparing core, theme, and plugin files against known-good checksums and alerting on any change. This catches a backdoor within hours instead of months.
- Vulnerability feeds, matching installed plugin versions against disclosed CVEs and notifying you the day a fix ships.
- Permission drift, flagging files that have crept to 777 or ownership that has changed.
- Uptime and login monitoring, alerting on unexpected admin logins, failed-login spikes, and sudden traffic shifts.
What automation misses:
- Logic flaws in custom code, which no scanner understands because it does not know what your code is supposed to do.
- Misconfigured integrations, an API key with more scope than it needs, a webhook pointing at a decommissioned endpoint.
- Stale accounts. A scanner sees a valid user; it does not know that person left the company eight months ago.
A workable cadence: automation runs continuously, you review alerts weekly, and you do a manual pass quarterly covering user accounts, integration scopes, and anything custom. Put it on the calendar, an audit that depends on remembering is not an audit.
Supply Chain Security: Vetting Plugins Before They Vet You
A single compromised plugin update can push malicious code to thousands of sites at once. It is the dominant pattern in large-scale WordPress compromises, and it bypasses every hardening step above because the code arrives through a trusted update channel.
What to check before installing any plugin or theme:
- Active installs and update history. A plugin with a large install base and a steady update cadence is lower risk than one with 200 installs and no release in two years. Abandoned plugins are the single most common source of unpatched vulnerabilities.
- Who maintains it. A plugin maintained by a company with a support desk and a security disclosure policy behaves differently from one maintained by an anonymous account with no contact information.
- What it actually does. Read the changelog. A plugin that suddenly adds “analytics” or “telemetry” in a minor release is worth a second look.
- Whether it needs the access it asks for. A contact-form plugin does not need
manage_options. If it requests capabilities far beyond its function, that is a signal. - Whether it is still on the repository. Plugins removed from the official directory for security reasons are a hard no, even if a third-party site still offers the download.
Two habits reduce supply-chain risk more than any single tool:
- Update on a delay, not on release day. Wait 24 to 72 hours after a plugin update ships before applying it to production, if it breaks something or ships malicious code, the community finds out first. Core security releases are the opposite: apply those immediately.
- Keep a plugin inventory. Know what you have installed, who maintains it, and when it was last updated. Most site owners cannot answer that about their own site, which is why a compromised plugin sits undetected for months.
Security is not a one-time setup. It is a maintenance schedule: monthly scans, weekly update review, a quarterly manual audit, and a plugin inventory you actually keep current. Automation handles the volume; you handle the judgment calls it cannot make.
Frequently Asked Questions
How can I make my WordPress website more secure?
Start with four moves: enable two-factor authentication for every admin account, install a reputable security plugin with a firewall and malware scanning, keep core, themes, and plugins updated, and set automated backups. Research from OsomStudio in 2026 found that basic security hygiene like regular updates and strong access controls stops more than 90% of attacks. Add a web application firewall and limit login attempts to block brute-force traffic before it reaches your login page.
How do you know if your WordPress site has been hacked?
Watch for sudden traffic drops, unfamiliar admin users, redirects to strange domains, Google warnings in search results, and unexpected plugin or file changes. Malware scanners like Wordfence or Sucuri flag suspicious code, backdoors, and modified core files. If you spot any of these, run a full scan immediately and check your security logs for unauthorized login attempts. Acting within hours limits damage, since attackers often install backdoors for repeat access.
What are the most common WordPress security vulnerabilities?
Plugin vulnerabilities top the list, followed by weak passwords, outdated core files, and missing two-factor authentication. In 2025, 11,334 new WordPress vulnerabilities were recorded, a 42% increase year over year, according to HideMyWP Ghost. Colorlib reports that 43% of these are exploitable without authentication, meaning attackers need no login to strike. SQL injection, cross-site scripting, and remote code execution remain the most exploited attack types.
Do I need a security plugin for my WordPress site?
Most small business sites benefit from one. A properly configured firewall blocks 95% of known threats out of the box, per Wordfence’s Q1 2026 Threat Intelligence Report. However, traditional WAFs alone block only 12% of WordPress-specific attacks, according to Colorlib, so pair a plugin with strong passwords, 2FA, and regular updates. Some enterprise teams harden WordPress without plugins to reduce overhead, but that approach demands server-level expertise most small businesses do not have in-house.
