Why WordPress Sites Get Hacked: 7 Most Common Vulnerabilities

WordPress is the most popular content management system in the world, powering over 40% of all websites. That popularity makes it the single largest target for automated attacks. Every day, bots scan millions of WordPress installations looking for known vulnerabilities, weak credentials, and misconfigured servers.

The good news is that the vast majority of successful attacks exploit a small number of well-understood vulnerabilities. Fix these seven issues, and you eliminate the entry points that account for over 95% of WordPress compromises. This is not theoretical advice; these are the exact vulnerabilities we encounter repeatedly in our hacked website recovery work for UK businesses.

1. Outdated Plugins and Themes: The Number One Attack Vector

How It Works

Plugins and themes are third-party code that runs with the same permissions as WordPress core. When a security vulnerability is discovered in a plugin, the developer issues a patch and publishes an update. At the same moment, the vulnerability details become public knowledge, and automated exploit tools are updated within hours.

If your site is still running the vulnerable version when those scanning tools arrive, the attack is automated and instant. There is no human attacker sitting at a keyboard; it is a bot that has already scanned thousands of sites and will exploit every one it finds.

Why It Is So Common

Many site owners install plugins and forget about them. Plugins that are no longer actively maintained stop receiving security patches entirely, but they remain installed and active on thousands of sites. The average WordPress site runs between 20 and 30 plugins. Each one is a potential entry point.

The Fix

• Enable automatic updates for all plugins and themes. WordPress supports this natively from version 5.5 onward.
• Remove every plugin you are not actively using. Deactivated plugins can still be exploited if the vulnerable files exist on the server.
• Audit plugins quarterly. Check the last update date for each plugin. If a plugin has not been updated in 12 months, find an alternative that is actively maintained.
• Subscribe to a vulnerability alert service like WPScan or Patchstack to receive immediate notifications when a plugin you use is affected.

2. Weak Passwords and Lack of Two-Factor Authentication

How It Works

Credential-based attacks come in two forms. Brute-force attacks systematically try password combinations against your login page. Credential stuffing uses username-password pairs leaked from breaches on other platforms, banking on the fact that many people reuse passwords across services.

Both attacks are fully automated. A brute-force bot can attempt thousands of password combinations per minute against a standard WordPress login page. If your admin password is anything common, short, or reused from another site, it will eventually be guessed.

Why It Is So Common

Despite years of security awareness campaigns, weak passwords remain endemic. Common patterns include using the business name, the word "admin", or simple combinations like "Password123". The default WordPress username of "admin" makes the problem worse by giving attackers half the credential pair for free.

The Fix

• Enforce passwords of at least 16 characters with a mix of character types. Use a password manager to generate and store them.
• Mandate two-factor authentication (2FA) for every account with editor-level access or above. TOTP-based apps like Google Authenticator are more secure than SMS codes.
• Never use "admin" as a username. Create a unique administrative username and delete the default admin account.
• Limit login attempts to five per ten-minute window. This stops brute-force attacks without affecting legitimate users.
• Change the default login URL. Moving /wp-login.php to a custom path dramatically reduces automated bot traffic.

3. Insecure Hosting Environments

How It Works

Your hosting environment is the foundation your WordPress site sits on. If the server is misconfigured, running outdated software, or sharing resources with compromised neighbour sites, no amount of WordPress-level security will protect you.

On cheap shared hosting, a vulnerability in one site on the server can allow an attacker to traverse to other accounts. Outdated PHP versions (anything below 8.1 in 2026) contain known security vulnerabilities that are no longer patched. Missing server-level protections like a web application firewall leave your site exposed to attacks that could be blocked before they reach WordPress.

Why It Is So Common

Hosting is often chosen on price alone. The cheapest shared hosting plans pack hundreds of sites onto a single server with minimal isolation between accounts. Site owners rarely check their PHP version, server software versions, or hosting security configuration after the initial setup.

The Fix

• Choose managed WordPress hosting from a provider that offers account isolation, automated backups, server-level firewalls, and malware scanning.
• Ensure PHP 8.2 or later is active. Check your hosting panel and upgrade if necessary. If your host does not support modern PHP, it is time to migrate.
• Verify server-level security features: WAF, DDoS protection, automatic OS patching, and intrusion detection should all be included or configurable.
• Use SFTP instead of FTP for file transfers. FTP transmits credentials in plain text, making them trivial to intercept.

4. Brute-Force Login Attacks

How It Works

Brute-force attacks specifically target the WordPress login mechanism. Standard bots hit /wp-login.php and /xmlrpc.php with high-volume login attempts. XML-RPC is particularly dangerous because the system.multicall method allows an attacker to try hundreds of passwords in a single HTTP request, bypassing many login-limiting protections.

Even when brute-force attacks do not succeed in gaining access, the volume of requests can overwhelm your server, causing performance degradation or downtime that affects legitimate visitors.

Why It Is So Common

The WordPress login page is at a predictable URL on every installation. Bots do not need to discover it; they already know where it is. XML-RPC is enabled by default on WordPress, providing a powerful amplification vector that many site owners are unaware of.

The Fix

• Disable XML-RPC entirely unless you specifically need it for the WordPress mobile app or Jetpack. Block it at the server level via .htaccess for maximum effectiveness.
• Implement rate limiting at both the server and application level. Fail2ban or similar tools at the server level, combined with a WordPress security plugin, provide layered protection.
• Use a web application firewall that identifies and blocks brute-force patterns before requests reach your server.
• Add CAPTCHA or bot detection to the login page. Modern CAPTCHA solutions add minimal friction for legitimate users while effectively blocking automated attempts.
• Consider IP-based allowlisting for the admin area if your team accesses the dashboard from predictable locations.

5. SQL Injection Vulnerabilities

How It Works

SQL injection occurs when an attacker inserts malicious database commands into input fields, URL parameters, or other data that the site passes directly to a database query without proper sanitisation. A successful SQL injection can extract the entire contents of your database, including user credentials, customer data, and content. It can also modify data, create new administrator accounts, or inject malicious content into your posts and pages.

WordPress core is well-protected against SQL injection through its prepared statements and sanitisation functions. However, plugins and custom themes frequently fail to sanitise database inputs correctly, creating injection points.

Why It Is So Common

Many plugin developers are not security specialists. They build features that work but do not follow security best practices for database interactions. Contact form plugins, search features, custom query builders, and any plugin that accepts and processes user input are common injection points.

The Fix

• Keep all plugins updated. SQL injection vulnerabilities in popular plugins are quickly patched once discovered.
• Use a WAF with SQL injection rules. A web application firewall can detect and block injection attempts in real time, protecting against both known and zero-day attacks.
• If you develop custom plugins or themes, always use WordPress's $wpdb->prepare() method for all database queries. Never concatenate user input directly into SQL strings.
• Restrict database user permissions. The WordPress database user should only have the minimum permissions required. It should never have access to other databases on the same server.
• Regularly audit your database for unexpected administrator accounts, suspicious content injections, or modified options that could indicate a past or ongoing attack.

6. Cross-Site Scripting (XSS) in Themes and Plugins

How It Works

Cross-site scripting attacks inject malicious JavaScript into your web pages. When a visitor loads the affected page, the script executes in their browser with full access to the page content, including cookies, session tokens, and form data.

There are two primary types. Stored XSS injects the script into your database (through a comment field, form submission, or vulnerable plugin), where it persists and affects every subsequent visitor. Reflected XSS embeds the script in a crafted URL that, when clicked, executes in the victim's browser.

XSS attacks can steal admin session cookies (granting the attacker full dashboard access), redirect visitors to phishing pages, inject crypto-mining scripts, or modify the visible content of your site.

Why It Is So Common

XSS vulnerabilities arise from failing to sanitise output, meaning any data displayed on a page that originally came from user input. This includes comments, search results, form field values, URL parameters, and even post titles if they accept unfiltered HTML. Themes with page builders, form plugins, and social features are frequent sources.

The Fix

• Implement Content Security Policy (CSP) headers. CSP tells browsers which scripts are allowed to execute, blocking injected scripts even if they make it into your page markup.
• Keep themes and plugins updated. XSS vulnerabilities are among the most frequently patched issues in the WordPress ecosystem.
• Use WordPress escaping functions in any custom development: esc_html(), esc_attr(), esc_url(), and wp_kses() should be applied to all output.
• Disable HTML in comments or use a plugin that strips potentially dangerous markup.
• Deploy a WAF with XSS detection rules to block malicious payloads before they reach your application.

7. File Inclusion and Upload Vulnerabilities

How It Works

File inclusion vulnerabilities allow an attacker to include external files, such as a malicious PHP script hosted on their own server, into your WordPress execution flow. Local File Inclusion (LFI) lets them access files on your server, such as wp-config.php, which contains your database credentials. Remote File Inclusion (RFI) lets them execute arbitrary code from an external source.

Upload vulnerabilities exploit media upload functionality, contact form file attachment features, or any plugin that accepts file uploads. If the upload handler does not properly validate file types, an attacker can upload a PHP shell disguised as an image, then access it directly to execute commands on your server.

Why It Is So Common

WordPress is designed to let users upload media, and many plugins extend this with document uploads, CSV imports, and file attachment features. Each upload point is a potential vulnerability if the plugin does not rigorously validate file types, check MIME types, and prevent direct execution of uploaded files.

The Fix

• Disable PHP execution in the uploads directory. Add a .htaccess rule or Nginx configuration to prevent any PHP files from running within /wp-content/uploads/.
• Restrict allowed upload file types. WordPress filters uploads by default, but some plugins override these restrictions. Audit your upload configuration to ensure only necessary file types are permitted.
• Disable allow_url_include in PHP configuration. This server-level setting prevents remote file inclusion attacks entirely.
• Set proper file permissions. Uploaded files should never be executable. Directories should be 755 and files 644 at most.
• Monitor the uploads directory for unexpected PHP, JavaScript, or executable files. Automated file integrity monitoring catches malicious uploads quickly.

Bringing It All Together: A Layered Defence Strategy

No single measure addresses all seven vulnerabilities. Effective WordPress security requires a layered approach where each defence compensates for potential gaps in the others.

1. Update everything. Plugins, themes, and WordPress core should update automatically or be updated within 24 hours of a new release.
2. Enforce strong authentication. Complex passwords plus 2FA on all administrative accounts.
3. Choose quality hosting. Managed WordPress hosting with server-level security features.
4. Deploy a WAF. Block common attack patterns before they reach your application.
5. Monitor continuously. Daily malware scans, file integrity monitoring, and uptime checks.
6. Maintain backups. Automated daily backups stored off-site and tested regularly.
7. Audit periodically. A professional WordPress security audit catches issues that automated tools miss.

If you are unsure where your site stands on any of these vulnerabilities, a professional audit is the most efficient starting point. Our security audit service systematically evaluates every layer of your WordPress installation and provides a prioritised remediation plan.

What to Do If You Have Already Been Hacked

If your site is already compromised, the priority shifts from prevention to containment and recovery. Do not attempt to simply patch the vulnerability that was exploited; once an attacker has access, they typically install multiple backdoors to maintain persistence.

• Take a full backup immediately for forensic purposes.
• Put the site into maintenance mode to protect visitors and prevent further damage.
• Change all credentials: WordPress admin, database, FTP, hosting panel, and any connected services.
• Engage a professional hacked website recovery service to perform a thorough cleanup, or use our dedicated malware removal service for a guaranteed, fixed-fee resolution.

Once recovery is complete, implement the preventive measures described above and consider a security retainer that provides ongoing monitoring and rapid response to future threats.