Many wonder how WordPress can be vulnerable to attack despite its popularity and following. Others are completely unaware of the risk. Analysis.
What is a vulnerability?
WordPress is programmed using the PHP language.
PHP code is used to create "dynamic" sites. In other words, content is generated on each page by a PHP program. A dynamic site also enables interaction with visitors. In technical terms, it enables requests to be received and processed.
This strength is also a weakness in that it can leave room for unwanted interactions, enabling a website to be hacked.
This is known as a "security flaw" or "vulnerability".
PHP vulnerabilities
Vulnerabilities in PHP code can have various causes.
Here are a few common examples.
- Unvalidated input: When PHP code accepts user data, such as a form or query, without proper validation, it can be vulnerable to malicious code injection attacks.
- Excessive permissions: Assigning excessive permissions to files and users can enable unauthorized manipulation attacks.
- Poor error handling: Revealing sensitive information in error messages can give attackers clues to further exploit the system.
In addition, there may be vulnerabilities in PHP. The PHP executor itself sometimes contains security holes if not kept up to date. (see image)
Other vulnerabilities not directly linked to PHP, such as XSS vulnerabilities, are also common. These allow malicious code to be executed.
Let's see how this works in practice for WordPress.
WordPress website vulnerabilities
Security vulnerabilities in WordPress
WordPress is a robust content management system, but it includes nearly a million lines of PHP code (924,096 lines currently).
WordPress is also 59,772 plugins and 11,378 themes available on wordpress.org. Millions more lines of code available for installation on your site.
This wealth of code creates fertile ground for security flaws. The more you multiply the code, the more you multiply the risk. So, every day, new vulnerabilities are discovered. They can be found in the core of WordPress, but also in installed themes and plugins.
Detecting, correcting and revealing vulnerabilities
If a party detects a flaw (an individual developer, a "white hat", an organization specializing in security), it notifies the developers of the script containing the flaw.
If the developers are reactive, they correct the flaw and publish the patch.
Then, typically 30 to 90 days after its discovery, the security flaw is publicly disclosed. On the one hand, to give credit for the discovery to the whistle-blower, and on the other, to warn script users of the risk involved in failing to update.
Current flaw not corrected
WordPress currently features a uncorrected flaw since version 6.1.1 (i.e. several months ago). This allows a website to be used to execute requests to other targets. It can be mitigated by blocking access to xmlrpc.php and disabling WordPress pingbacks (which was done on all the sites I manage even before this flaw was detected).
When is WordPress vulnerable and what can you do about it?
Vulnerabilities revealed
When a vulnerability is revealed, all installations with the vulnerable script are inherently affected. If this is the case, hackers are likely to exploit the flaw.
There are two types of vulnerabilities:
- Your site contains a script (WordPress, plugin, theme) with a known vulnerability that has not been corrected by the developers. Development of this script may have been abandoned. In this case, you should disable the script or replace it with a non-vulnerable script that is better monitored by its developers.
- Your site is out of date. You haven't corrected the security flaw. You need to update your site as regularly as possible, and make sure you don't have any obsolete scripts (which could potentially put you in the same situation down the line).
Zero-day vulnerabilities
Sometimes, hackers will find a vulnerability before it is revealed and then corrected. They will exploit it directly. This is known as a zero-day vulnerability.
The more popular a script is, the more likely it is that hackers will look for zero-day vulnerabilities in it. It's rare, but it happens.
Here's another reason to design simple sites: the more popular plugins you multiply, the more vulnerable your WordPress site becomes. Not just to zero-day vulnerabilities, but to vulnerabilities in general.
To protect against 0-day vulnerabilities, the server hosting your site needs to be secure. This can be achieved by blocking suspicious requests from hackers using an application firewall. Then block attacking IPs with fail2ban, for example. This is not generally the case with shared hosting packages. With the exception ofHaiSoft with whom I've pushed these security measures, which has greatly reduced the number of hacks. But this can lead to false positives: Requests blocked when they are legitimate, especially with WordPress builders (Elementor, Divi, WP-Bakery and others). The technical support required is then higher, which is why most service providers don't implement this type of security. Security is always more complex than no security.
Despite all the security measures in place, it's important to bear in mind that some hacker requests can slip through the net. There is no such thing as zero risk, and anyone who claims otherwise is either ignorant or a liar.
So, since perfect security doesn't exist, assume that your site could be hacked tomorrow. If this happens, what do you do? You'd better have an up-to-date, easily restorable backup that's not stored on your site.
Conclusion
Hacking doesn't just happen to other people. On a regular basis, owners of WordPress sites come to me with a problem. hacked website to repair.
Every computer system is potentially vulnerable, including your WordPress site. The challenge is to minimize the risks of hacking by applying all preventive measures. This starts with an up-to-date, secure server capable of blocking attacks. It also means regularly monitoring your WordPress site, updating it as often as possible, constantly checking for known security vulnerabilities, and taking swift action in the event of a problem. In all cases, an automated, external, independent backup of your site must be carried out on a daily basis. This is precisely the set of services you'll find in my Webmastering WordPress.
If your site is important to your business, don't wait to be hacked, be proactive and have your site checked by a WordPress security audit or go directly to my Webmastering.
Leave a Reply