10 Website Hacking Methods That Put Your Site at Risk in 2025

Website attacks are rarely random. Most compromises happen through a small set of known methods that bots and attackers use every day. Understanding where the openings are — and how attackers find them — is the first step to closing them before they become an emergency.

According to Patchstack's 2025 WordPress security report, over 7,900 new vulnerabilities were disclosed in the WordPress ecosystem in 2024 alone. The vast majority were in plugins. But the attack methods themselves are remarkably consistent year to year. This guide breaks down the ten most common website hacking methods affecting WordPress businesses in 2025, what they look like in practice, and the specific defences that matter most.

1. Vulnerable Plugins and Themes

Outdated plugins and themes are the single biggest entry point for WordPress compromises. Patchstack's data shows that 96% of reported WordPress vulnerabilities in 2024 were found in plugins — not WordPress core. Attackers do not manually search for vulnerable sites. They run automated scans across millions of URLs, matching version numbers against public vulnerability databases. When they find a match, exploitation can happen within hours of a CVE being published.

The risk is not limited to obscure plugins. Some of the most exploited vulnerabilities in recent years have been in widely used plugins with hundreds of thousands of active installs — precisely because their popularity makes mass exploitation more rewarding.

Reduce the risk: Remove plugins you are not actively using. Update maintained plugins quickly — ideally within 48 hours of a security release. Test updates in staging before pushing to production. Prioritise plugins based on install count, public vulnerability history, and how much privileged access they have.

2. Brute Force Login Attacks

Automated bots continuously hammer WordPress login pages — /wp-login.php and xmlrpc.php — trying thousands of username and password combinations per hour. Most of these attacks are not targeted at a specific site. They run against any WordPress URL they find, probing for weak credentials like admin / password123 or common combinations scraped from previous breaches.

A successful brute force attack gives the attacker full admin access — no plugin vulnerability required. From there, they can install malicious plugins, create backdoor admin users, inject code into theme files, or redirect visitors to phishing pages.

Reduce the risk: Enforce strong, unique passwords for all user accounts. Enable two-factor authentication for admin and editor roles. Rate-limit or block repeated failed login attempts using a security plugin or server-level firewall. Consider moving or hiding the default login URL. Block XML-RPC if you are not using it.

3. Credential Stuffing

Credential stuffing is different from brute force. Instead of guessing passwords, attackers use leaked username and password pairs from previous data breaches — billions of which are available on dark web markets and paste sites. They test these known credentials against your WordPress login. If any member of your team reused a password from a breached service, your site can be compromised without any software vulnerability at all.

This attack is particularly dangerous because standard security tools do not always catch it. The login attempt uses a real, valid-looking credential. It does not trigger brute force limits. The access looks legitimate until the attacker acts.

Reduce the risk: Unique passwords for every account — especially admin users — is the primary defence. Two-factor authentication makes credential stuffing nearly impossible even with a valid password. Have-I-Been-Pwned integration or tools that flag known-compromised passwords at login can add a further layer.

4. SQL Injection

SQL injection exploits poorly sanitised form inputs, URL parameters, or plugin functions to run malicious commands directly against your database. An attacker who can inject SQL commands can extract all stored data — user records, customer data, order history, credentials — or modify database contents entirely.

WordPress itself handles database interaction safely in most cases. But plugins and themes that use custom queries without proper sanitisation create the opening. Contact forms, search fields, booking systems, and custom post types built with insufficiently validated inputs are the most common targets.

Reduce the risk: Keep plugins updated — most SQL injection vulnerabilities in WordPress are patched in newer versions. Use a web application firewall (WAF) that blocks common injection signatures at the network level. Remove or replace plugins with known injection vulnerabilities. If your business requires custom WordPress development, require proper use of WordPress's prepared statement functions.

5. Cross-Site Scripting (XSS)

XSS attacks inject malicious JavaScript into a page so that it executes in visitors' browsers rather than on the server. Stored XSS (the most dangerous variant) persists in the database and runs every time the affected page loads. Reflected XSS requires a crafted URL to trigger. Both can lead to session cookie theft, visitor redirection to phishing pages, malicious popup overlays, or silent form-jacking that captures what users type — including payment details.

For WooCommerce stores in particular, XSS vulnerabilities that reach checkout pages represent a direct payment security risk. Attackers have used this vector to skim card numbers at scale from vulnerable stores.

Reduce the risk: Update plugins that handle user input or display dynamic content. Apply a strong Content Security Policy (CSP) header to limit which scripts can execute. Use a WAF with XSS filtering rules. Audit any custom theme or plugin code that outputs user-controlled data without escaping it.

6. Backdoors Hidden After Initial Access

This is the attack method that turns a one-time breach into an ongoing problem. After gaining initial access through any of the other methods, sophisticated attackers do not simply deface the site and leave. They plant persistence mechanisms — hidden PHP shells in upload directories, rogue admin users with obfuscated usernames, malicious cron jobs that re-infect the site on a schedule, or encoded payloads buried in the database.

A cleanup that removes visible malware but misses the backdoor will result in reinfection — often within hours. This is why many businesses report being "cleaned" by a plugin and then hacked again the following week. The backdoor was never found.

Reduce the risk: Treat malware cleanup as a root-cause investigation, not just a visible file cleanup. After any incident, change all credentials, audit user accounts, check cron jobs, scan upload directories for PHP files, and review the database for injected content. Professional incident response that includes post-cleanup hardening is far more reliable than plugin-only cleanup.

7. File Upload Abuse

WordPress and many plugins accept file uploads — profile pictures, documents, media attachments. If file validation is weak, an attacker can upload a PHP file disguised as an image. Once on the server, that file becomes an executable web shell — a direct command interface into the hosting environment. From there, the attacker can read and modify any file the web server can access.

File upload vulnerabilities are particularly common in form builder plugins, LMS platforms, community features, and portfolio systems. They often go undetected because the upload appears to succeed normally from the user interface.

Reduce the risk: Restrict permitted file types to only what is genuinely needed. Block PHP execution inside the uploads directory at the server or WAF level — this single measure stops most file upload exploitation even if a malicious file gets through. Keep plugins that handle uploads updated and audit the specific upload directories for unexpected PHP files.

8. Hosting-Level or Account-Level Access

Some attackers bypass WordPress entirely. If hosting credentials, cPanel access, FTP login details, or SSH keys are compromised — through phishing, credential stuffing against the hosting provider, or weak account passwords — the attacker gains direct filesystem access. They can read, modify, or replace any file on the server. WordPress security settings, plugins, and WAFs provide no protection at this level.

Shared hosting environments introduce additional risk: a vulnerability in one site on the server can sometimes be used to access files belonging to neighbouring sites (cross-site contamination), particularly when hosting accounts are not properly isolated.

Reduce the risk: Use unique, strong credentials for every hosting account and control panel. Enable two-factor authentication on hosting accounts where available. Rotate credentials after any incident or suspected breach. Limit FTP/SSH access to specific IP addresses. Consider managed WordPress hosting that provides stronger account isolation and security monitoring at the infrastructure level.

9. Misconfigured Permissions and Server Rules

Overly permissive file permissions make exploitation easier. Files that should be read-only — like wp-config.php — being world-writable mean that an attacker who gains any level of access can modify core configuration, database credentials, or secret keys. Similarly, missing or incorrect server configuration (no .htaccess protections, directory listing enabled, debug mode left on in production) can expose information that helps attackers plan more targeted attacks.

Reduce the risk: Review and harden file permissions after setup and after any incident. Disable directory listing. Protect wp-config.php and .htaccess from direct access. Disable XML-RPC if unused. Turn off WordPress debug mode in production environments. These changes do not require ongoing work — they are one-time hardening tasks that reduce the attack surface permanently.

10. Delayed Detection

This is arguably the most commercially damaging item on this list. Many websites stay compromised for weeks — sometimes months — because no one is watching closely enough to notice. During that window, the attacker uses the site to send spam, host phishing pages, redirect visitors, skim payment data, or mine cryptocurrency. Google eventually detects the malicious content and blacklists the domain. Hosting providers flag it and suspend the account. Visitors start seeing browser security warnings.

By the time the compromise is discovered, the damage extends well beyond the site itself: revenue loss, blacklist removal overhead, potential GDPR notification obligations, and a reputational hit that takes months to recover from. A site blacklisted by Google typically loses 95% of organic traffic overnight.

Reduce the risk: Implement continuous monitoring: uptime monitoring, malware scanning, file integrity checking, blacklist status monitoring, and alerting on unexpected changes. A monitoring stack that detects compromise within hours — rather than weeks — reduces both the technical remediation cost and the commercial damage significantly.

What happens after a WordPress site is compromised

Understanding the typical attacker workflow after gaining access helps clarify why proper incident response matters as much as prevention.

1. Initial reconnaissance. The attacker maps the site — identifying the WordPress version, active plugins, user accounts, file structure, and what data is stored.
2. Privilege escalation. If access was gained at a lower privilege level (subscriber, contributor), they attempt to escalate to admin access.
3. Persistence installation. Backdoors, rogue admin accounts, or scheduled reinfection tasks are planted before doing anything visible.
4. Monetisation or further exploitation. Depending on the attacker's goal: spam relay, redirect injection, phishing page hosting, credential harvesting, SEO spam, or ransomware deployment.
5. Lateral movement. On shared hosting, the attacker may attempt to access neighbouring sites or escalate server-level access.

A proper incident response should address all five stages — not just stage four. Sites that are "cleaned" without closing the original access vector and removing persistence mechanisms are almost always reinfected.

Warning signs your site may already be compromised

• Unexpected admin users appearing in WordPress user list
• Google Search Console showing URLs you did not create (spam injection)
• Visitors being redirected to other sites — often only on mobile or from search engine clicks
• Hosting provider flagging unusual outbound email volume or resource usage spikes
• Browser security warnings appearing for your domain
• Site appearing on Google Safe Browsing or other blacklists
• Files in the uploads directory with .php extensions
• Unexplained changes to wp-config.php, functions.php, or .htaccess