If you’re running a WordPress site, you’re running a target. That’s not meant to scare you — it’s just reality. WordPress powers over 40% of the web, which makes it the single most attractive platform for automated attacks. I’ve spent years scanning WordPress installations through security tools, and the same vulnerabilities keep appearing across thousands of sites. The good news is that most common WordPress security vulnerabilities are entirely preventable once you know what to look for.
This article walks you through the ten issues I encounter most often, along with practical fixes for each one.
1. Outdated Core, Themes, and Plugins
This tops every list for a reason. Roughly 60% of compromised WordPress sites I’ve analyzed were running outdated software at the time of the breach. When WordPress pushes a security update, attackers reverse-engineer the patch within hours and start scanning for sites that haven’t applied it yet.
I remember a case where a client’s e-commerce site got compromised because they were two minor versions behind on core. The vulnerability was publicly documented and patched — they just hadn’t clicked “update.” That’s literally all it took.
Enable automatic updates for minor releases and security patches. For major updates, test on staging first, but don’t sit on them longer than a week. Plugin vulnerabilities alone account for a massive share of WordPress breaches, so keep those current too.
2. Weak Login Credentials and Missing 2FA
It might sound obvious, but “admin / password123” is still shockingly common. Brute force attacks are fully automated — bots cycle through millions of credential combinations around the clock. If your login page is unprotected, it’s a matter of time.
Use a password manager. Generate passwords of at least 16 characters with mixed case, numbers, and symbols. Change the default “admin” username to something unique. And enable two-factor authentication — this single step blocks virtually all brute force attacks, even if your password somehow leaks.
3. SSL/TLS Misconfigurations
Here’s a myth that needs busting: “I installed an SSL certificate, so my site is secure.” Not even close. I regularly find sites where the certificate is valid but the configuration is a mess — mixed content warnings, outdated TLS versions still enabled, missing HSTS headers.
A common scenario: a site migrates to HTTPS but some images and scripts still load over HTTP. The browser throws mixed content warnings, and the actual encryption becomes inconsistent. Run a proper SSL/TLS analysis to catch these issues. Anything below TLS 1.2 should be disabled at this point.
4. SQL Injection Vulnerabilities
SQL injection attacks remain one of the most dangerous threats to any WordPress site that uses custom code or poorly maintained plugins. Attackers manipulate database queries through unsanitized user inputs — search fields, contact forms, URL parameters — and gain direct access to your data.
Always use prepared statements in custom code. WordPress provides $wpdb->prepare() for exactly this purpose. For third-party plugins, stick to well-maintained ones with regular update cycles. Run automated vulnerability scanning that specifically tests your input fields for injection flaws.
5. Cross-Site Scripting (XSS)
XSS vulnerabilities let attackers inject malicious JavaScript into your pages, which then executes in your visitors’ browsers. The impact ranges from stolen session cookies to full-blown phishing redirects served from your own domain.
Another myth worth killing: “XSS only affects big sites.” Automated scanners don’t care about your traffic numbers. If your contact form or comment section doesn’t sanitize input, you’re a target. Use WordPress’s built-in escaping functions — esc_html(), esc_attr(), wp_kses() — and never trust user input, period.
6. File Upload Vulnerabilities
Contact forms and media uploaders are convenient — and dangerous if misconfigured. Attackers disguise malicious PHP files as harmless images, upload them through your forms, and execute them to gain shell access. I’ve seen entire servers compromised through a single file upload vulnerability in a forgotten plugin.
Restrict upload types to exactly what’s needed. Validate on the server side — client-side checks are trivially bypassed. Add php_flag engine off to your uploads directory .htaccess to block PHP execution. Better yet, store uploads outside your web root entirely.
7. Insecure XML-RPC Interface
WordPress’s XML-RPC interface allows remote connections, which sounds useful until you realize it’s one of the most exploited entry points. Attackers use it for amplified brute force attacks — a single XML-RPC request can test hundreds of passwords at once, completely bypassing rate limiters on wp-login.php.
If you don’t use mobile apps or remote publishing tools that depend on XML-RPC, disable it. A simple .htaccess rule can block all XML-RPC requests. If you do need it, restrict access by IP whitelist.
8. Missing Security Headers
This one flies under the radar but it shouldn’t. Missing or misconfigured security headers like CSP, HSTS, and X-Frame-Options leave your site exposed to clickjacking, MIME sniffing, and various injection attacks.
Add these to your Apache configuration or .htaccess:
X-Content-Type-Options: nosniff — prevents MIME type sniffing.
X-Frame-Options: SAMEORIGIN — blocks clickjacking attempts.
Content-Security-Policy — controls which resources can load on your pages.
Strict-Transport-Security — enforces HTTPS connections.
Ten minutes of configuration eliminates an entire class of attacks.
9. Exposed Sensitive Files and Directory Listing
When directory listing is enabled, anyone can browse your file structure and potentially access configuration backups, database dumps, or log files. I’ve found exposed wp-config.php backup files — wp-config.php.bak sitting right there in the webroot — on production sites more often than I’d like to admit.
Add Options -Indexes to your .htaccess. Remove or protect readme.html, license.txt, and any backup files. Block direct access to wp-includes and wp-content/debug.log. Low effort, high impact.
10. No Security Monitoring or Scanning
Here’s the vulnerability that enables all the others: not watching. Without active monitoring, a breach can go undetected for weeks or months. Attackers inject backdoors, add spam pages for SEO poisoning, or quietly exfiltrate data — all while your site looks perfectly normal on the surface.
Set up file integrity monitoring to catch unexpected changes to core files. Implement activity logging so you know who did what and when. Most importantly, run automated security scans daily. A comprehensive scan that checks for OWASP vulnerabilities, malware, misconfigurations, and outdated components catches problems before they become incidents.
Frequently Asked Questions
How often should I update WordPress and its plugins?
Apply security patches immediately — within 24 hours of release. For major updates, test on staging first, but don’t delay more than a week or two. The window between a patch release and active exploitation keeps shrinking.
Is a security plugin enough to protect my WordPress site?
A security plugin is one layer, not the whole solution. You still need strong credentials, two-factor authentication, proper server configuration, regular updates, and ongoing vulnerability scanning. Security works in layers — no single tool covers everything.
What should I do first if my WordPress site gets hacked?
Take the site offline immediately to prevent further damage. Change all passwords — WordPress admin, database, FTP, hosting panel. Restore from a clean backup if available. Then scan thoroughly for backdoors, because attackers almost always leave multiple entry points. Finally, identify how they got in and fix that specific vulnerability before going live again.
Most WordPress security breaches are still caused by basics: outdated software, weak passwords, missing headers, and lack of monitoring. Take an hour to audit your site against this list. The sites that get compromised are usually the ones where someone assumed everything was fine and stopped paying attention.