3v-Hosting Blog
10 min read
WordPress isn’t just a blogging platform; it’s a kind of foundation upon which a vast portion of the internet rests today - from simple landing pages to high-traffic online stores and even internal corporate services. In fact, it is precisely this versatility that makes it convenient and popular. But versatility has a significant downside - vulnerability. After all, the more extension points a product includes - such as plugins, themes, custom code, and so on - the more potential vulnerabilities can arise, through which an attacker can gain access to the system.
In practice, it’s not WordPress itself that gets hacked, but a specific installation containing, for example, an outdated plugin, a poorly written form, or an accessible entry point that was forgotten after release. Even if the server is configured nearly perfectly, the site remains vulnerable.
In this article, we’ll try to figure out which WordPress vulnerabilities are most common, where to look for them in a real project, and why relying on a single security plugin usually leads to a false sense of security. So, let’s get started.
The reason why WordPress sites are attacked more often than others is quite simple - it’s their sheer volume. As of early 2026, WordPress powers about 43.5% of all websites on the internet, which represents an overwhelming market share of all CMS platforms, given their total number. And so, attacking it becomes profitable, since a single well-chosen exploit can work on thousands of sites.
But it’s not just about the popularity of the core itself. Since the WordPress ecosystem is, in essence, built on plugins and themes that are often developed by third-party teams, installing such plugins is akin to installing packages from unverified repositories in Linux - it seems convenient, but it’s very risky.
As a result, most WordPress security issues arise not from the core, but from:
To begin building adequate protection, we must first understand the model of incoming threats. A common mistake among most website owners is the belief that an attack is a targeted, one-off event aimed specifically at them or their site. In practice, it’s much simpler and at the same time more dangerous, since most WordPress sites get hacked not because someone specifically targeted you, but because you were caught in a mass scan.
The problem is that thousands of automated systems constantly scan the Internet looking for vulnerable sites. Just look at the logs of a newly launched server, and you’ll see hundreds or thousands of requests that are essentially scans of your server.
These automated systems don’t analyze your business or examine the content on your site - they’re only interested in specific signatures, such as a plugin version, an open endpoint, or a weak password. If you’ve made a mistake and it just so happens that your site has vulnerabilities, an attack on your site is launched automatically. And once the attack is successful, the information is provided to the attacker for manual processing.
As a result, in 90% of cases, your site is attacked not by a human, but simply by a script.
Main types of attackers:
/wp-login.php;
It’s also important to understand the motivation, since in most cases the goal of an attack isn’t hacking for the sake of hacking, but rather monetization or gaining some other benefit. This could include:
This means that securing a WordPress site isn’t a battle against the stereotypical hooded hacker, but a battle against a constant background stream of automated attacks that never stops. We’ll start from there.
To effectively identify issues, you need at least a general understanding of where they typically arise. It’s important not just to memorize the names of specific vulnerabilities, but rather to visualize how they might manifest within your project - for example, through forms, plugins, file uploads, or errors in data processing logic.
Practice shows that most known vulnerabilities aren’t rocket science, but rather common flaws in your code or server configuration that recur from project to project and are well-known among hackers. That’s precisely why they can be predicted and, if desired, patched before attackers exploit them.
Now let’s break down the main types of vulnerabilities most commonly found on WordPress sites.
A classic scenario where a plugin or form on the site accepts user input and inserts it into an SQL query without filtering.
If the plugin developer did not use properly sanitized queries, an attacker could gain access to the database, steal, or destroy important data, such as user passwords.
XSS is a type of attack where an attacker can inject malicious JavaScript into your website’s pages.
This is also a fairly simple scenario in which a user opens a page on your site and their browser executes malicious code, which can lead to the theft of data, cookies, sessions, or the redirection of traffic to phishing sites.
If your website has a file upload form, it is also a potential entry point.
Without file type validation, an attacker can upload a PHP script and execute it on the server - this is a full-fledged RCE attack.
Even perfect code won’t save you if you’re using outdated versions of plugins and components in which vulnerabilities have long been discovered and documented.
Bots automatically find such sites, after which attackers proceed to hack them.
Brute-force attacks, or simply trying every possible username and password combination, are perhaps the most common type of attack, as they are straightforward and can be carried out with the simplest of tools. The standard entry point for such attacks is, of course, the login page /wp-login.php.
The main mistakes website owners make are:
Let’s summarize all this information in a simple table for clarity.
| Vulnerability Type | Where It Occurs | What the Attacker Gains | Risk Level |
|---|---|---|---|
| SQL Injection | forms, plugins | database access | critical |
| XSS | comments, input fields | cookies, sessions | high |
| File Upload | upload forms | code execution | critical |
| Outdated Plugins | any extensions | full control | critical |
| Brute Force | wp-login.php | admin access | high |
Searching for vulnerabilities in WordPress should not be a one-time event, but rather a process - a systematic approach with clear logic. What matters here is not so much the number of tools, but the correct sequence of actions and an understanding of exactly where problems most often arise.
To simplify, any check should boil down to three levels:
Most vulnerabilities are on the surface and can be detected without a complex audit if you systematically go through these layers.
Start with the simple and obvious:
This basic set covers most of the real-world issues encountered in production.
If you need to quickly understand the actual state of affairs, you can conduct a quick audit. But don’t be fooled - it doesn’t replace a full-scale audit; it simply gives a good overview of the site’s status.
Check the WordPress version:
wp core version
List of installed plugins:
wp plugin list
Pay special attention to plugins without updates, unknown or forgotten extensions, as well as disabled but not deleted plugins.
Vulnerability scan using WPScan:
wpscan --url https://example.com --enumerate vp
This will immediately identify known issues in plugins and themes.
Uploads directory analysis:
ls -la wp-content/uploads/
The presence of .php files, executable scripts, or other unusual subdirectories in this directory may be suspicious.
Checking file permissions:
find . -type f -perm 777
Files with 777 permissions are a common cause of system compromise, and their presence is a major red flag.
Alongside an internal audit, it’s important to understand how the site appears “from the outside.” Bots often don’t analyze your entire project but target standard entry points, such as:
/wp-login.php - frequently subjected to brute-force attacks;/xmlrpc.php - can be used to launch mass attacks and pingback abuse;/wp-json/ - allows access to the REST API;/wp-content/plugins/ - search for vulnerable plugins;/wp-admin/ - access to the site’s admin panel.
If these URLs are accessible without restrictions, your site is already being scanned regularly. The fact that a site is being scanned is a perfectly normal situation on the internet, but it requires monitoring. And the best practices for this are access restriction, logging, and monitoring.
So, remember that vulnerability scanning is not a one-time event, but a regular process that should be integrated into your site’s maintenance. After all, even a simple checklist run once a week is more beneficial than a thorough audit that is never performed.
Now that we understand the essence of the problem, we can turn to automation. Specialized scanners speed up the process and help identify common issues, but they all operate based on templates - that is, they search for known signatures, check standard entry points, and compare versions against databases of known vulnerabilities. Therefore, if you don’t understand exactly what’s going on under the hood, it’s easy to either miss a problem or get a false sense of security.
That’s why these tools should be viewed more as assistants or a way to speed up the process, but by no means as the sole source of truth.
There are dozens of solutions in the security ecosystem, but in practice, a limited set is most commonly used:
Each of them covers its own niche. But when it comes to the day-to-day administration of WordPress sites, not all of them are equally useful. And in most cases, one tool delivers the best results - the one that “understands” WordPress and its ecosystem best, since it’s specifically designed for it. Let’s talk about it in more detail.
Over the past few years, WPScan has effectively become the standard for auditing WordPress sites.
Its features include:
It’s quite simple to use. Let’s look at a few examples.
wpscan --url https://example.com
wpscan --url https://example.com --enumerate vp
wpscan --url https://example.com --enumerate u
wpscan --url https://example.com --api-token YOUR_TOKEN
IMPORTANT!
WPScan searches for known vulnerabilities, and if your site contains custom code with errors, it unfortunately won’t find them.
As we’ve discussed many times, security isn’t a one-time configuration but a systematic process. However, there is a list of measures that, when implemented, will allow you to at least somewhat secure your site before conducting a full-scale audit. Here they are:
xmlrpc.php (if you don’t need it);/wp-login.php;wp-config.php above the webroot;
This alone will significantly improve your site’s security. Server security is a separate matter, and we recommend you read this article on the subject.
Can WordPress be secured using only plugins?
No. Plugins are just one layer of protection. They can block some common attacks, but they do not solve problems with outdated components, vulnerable code, or incorrect server configuration. Without infrastructure monitoring and regular audits, their effectiveness is limited.
How dangerous is xmlrpc.php?
It is very often used for attacks if not restricted. It makes it easy to carry out mass brute-force attacks and DDoS-like requests. If the functionality is not used (e.g., mobile apps or integrations), it is best to disable it or restrict access.
Should wp-admin be hidden?
Hiding it does not provide complete protection, but it reduces noise from bots and automated attacks. It is more of an additional measure that reduces the number of login attempts, but it does not replace 2FA, IP-based access restrictions, and server-level protection.
Which is more important - the server or the CMS?
Both levels. But the CMS is most often the target of hacks because it is closer to the user and more likely to contain errors. At the same time, a weak server configuration can exacerbate the consequences - for example, by allowing uploaded malicious code to execute.
Is it enough to simply update WordPress regularly?
Updates are critically important, but they are not enough. Vulnerabilities often remain in disabled or forgotten plugins, custom code, and configuration. Updates are certainly the foundation, but they are not a comprehensive security strategy.
Will a WAF or Cloudflare fully protect the site?
No. A WAF reduces the number of automated attacks and filters traffic, but it does not eliminate vulnerabilities in the code. And if there is a vulnerable plugin on the site, it can still be exploited.
Should access to wp-login.php be restricted?
Yes. This is one of the most frequently targeted points. IP restrictions, rate limiting, or using fail2ban significantly reduce the risk of brute-force attacks and lessen the load on the server.
So, vulnerabilities in WordPress are not a coincidence or some rare exception, but rather a natural consequence of its architecture, since flexibility, extensibility, and a vast ecosystem inevitably create numerous problematic entry points. The problem lies not in the CMS itself, but in how it is used and maintained.
Unfortunately, most vulnerabilities are not unique and therefore do not require complex attacks. These are common mistakes, such as outdated plugins, open entry points, weak authentication, and excessive access rights. They can and should be identified in advance, even with a basic audit or tools like WPScan.
The key factor is your approach to security, because WordPress security isn’t built around a single plugin or a one-time configuration. It’s a process that includes monitoring updates, regularly checking the site, analyzing logs, limiting entry points, and basic automation. Infrastructure plays a distinct role here, as even if the site itself is compromised, properly configured isolation will prevent the attack from spreading further into the server.
When WordPress is viewed as part of an IT system rather than as a “standalone site,” predictability and manageability emerge. Ultimately, the goal is not to make the site unhackable, but to reduce the likelihood of an attack, limit the consequences, and detect the problem - preferably before it escalates into an incident.
If you’re looking for hosting for your WordPress site, our VPS servers in Ukraine and the Netherlands are an excellent solution. And our highly qualified support team is here to help with any questions you may have.
The landscape of search engine optimization (SEO) has undergone a seismic shift in recent years, ushered in by the dawn of artificial intelligence (AI). At the ...
Random Access Memory, or RAM, is a type of computer memory that can be read and written to randomly. This means that the processor can access any byte of data i...
You will find the complete technical guide to building your own Discord bot from scratch here. This in-depth article will thoroughly guide you through every ste...
Step-by-step guide to setting up WireGuard on a VPS: installation, key generation, server and client configuration, launching the VPN, and troubleshooting commo...
What is High Availability infrastructure? Principles of fault-tolerant architecture, elimination of SPOF, failover, data replication, and monitoring. How to bui...
How to choose a VPS for a Telegram bot: CPU, RAM, and disk requirements, webhook or polling, security, monitoring, and scaling without unnecessary costs.
