What is a vulnerability?<\/h2>\n\n\n\n
WordPress is programmed using the PHP language.
PHP code makes it possible 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.<\/p>\n\n\n\n
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\".<\/p>\n\n\n\n
PHP vulnerabilities<\/h3>\n\n\n\n\n![\"\"](\"https:\/\/www.lrob.fr\/wp-content\/uploads\/2023\/10\/new-php-logo.png\")
<\/figure>\n\n\n\nVulnerabilities in PHP code can have various causes.
Here are a few common examples.<\/p>\n<\/div>\n\n\n\n
\n- 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.<\/li>\n\n\n\n
- Excessive permissions: Assigning excessive permissions to files and users can enable unauthorized manipulation attacks.<\/li>\n\n\n\n
- Poor error handling: revealing sensitive information in error messages can give attackers clues to further exploit the system.<\/li>\n<\/ol>\n\n\n\n\n\n
In addition, there may be vulnerabilities in PHP. The PHP executor itself sometimes contains security holes if not kept up to date. (see image)<\/p>\n\n\n\n
Other vulnerabilities not directly linked to PHP, such as XSS vulnerabilities, are also common. These allow malicious code to be executed.<\/p>\n\n\n\n
Let's see how this works in practice for WordPress.<\/p>\n<\/div>\n\n\n\n![\"\"](\"https:\/\/www.lrob.fr\/wp-content\/uploads\/2023\/10\/php-supported-versions-1024x673.png\")
Source: Supported PHP versions<\/a><\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n\nWordPress website vulnerabilities<\/h2>\n\n\n\nSecurity vulnerabilities in WordPress<\/h3>\n\n\n\n\n![\"\"](\"https:\/\/www.lrob.fr\/wp-content\/uploads\/2022\/06\/icons8-wordpress-480-150x150.png\")
<\/figure>\n\n\n\nWordPress is a robust content management system, but it includes nearly a million lines of PHP code (924,096 lines<\/a> currently).
WordPress is also 59,772 plugins<\/a> and 11,378 themes<\/a> available on wordpress.org<\/a>. 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.<\/p>\n<\/div>\n\n\n\nDetecting, correcting and revealing vulnerabilities<\/h3>\n\n\n\n
If a party detects a flaw (an individual developer, a \"white hat\", a specialized security organization), it notifies the developers of the script containing the flaw.<\/p>\n\n\n\n
If the developers are reactive, they correct the flaw and publish the patch.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Current flaw not corrected<\/h4>\n\n\n\n
WordPress currently features a uncorrected flaw<\/a> since version 6.1.1 (i.e. several months ago). This allows you to use a website 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).<\/p>\n<\/div>\n\n\n\n\nWhen is WordPress vulnerable and what can you do about it?<\/h2>\n\n\n\nVulnerabilities revealed<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
There are two types of vulnerabilities:<\/p>\n\n\n\n
\n- 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.<\/li>\n\n\n\n
- 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).<\/li>\n<\/ul>\n\n\n\n
Zero-day vulnerabilities<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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<\/a> 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.<\/p>\n\n\n\nDespite 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.<\/p>\n\n\n\n
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.<\/p>\n<\/div>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
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<\/a>.<\/p>\n\n\n\nEvery 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<\/a>.<\/p>\n\n\n\nIf 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<\/a> or go directly to my Webmastering<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"Beaucoup se demandent comment WordPress peut \u00eatre vuln\u00e9rable aux attaques malgr\u00e9 sa popularit\u00e9 et son suivi. D’autres ignorent totalement le risque. Analyse. Qu’est-ce qu’une vuln\u00e9rabilit\u00e9 ? WordPress est programm\u00e9 avec le langage PHP.Le code PHP permet d’obtenir des sites \u00ab\u00a0dynamiques\u00a0\u00bb. C’est \u00e0 dire que le contenu est g\u00e9n\u00e9r\u00e9 \u00e0 chaque page par un programme PHP. […]<\/p>\n","protected":false},"author":1,"featured_media":3339,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24],"tags":[],"class_list":["post-3179","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-securite-wordpress"],"_links":{"self":[{"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/3179","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/comments?post=3179"}],"version-history":[{"count":33,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/3179\/revisions"}],"predecessor-version":[{"id":3371,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/3179\/revisions\/3371"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/media\/3339"}],"wp:attachment":[{"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/media?parent=3179"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/categories?post=3179"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/tags?post=3179"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
<\/figure>\n\n\n\nVulnerabilities in PHP code can have various causes.
Here are a few common examples.<\/p>\n<\/div>\n\n\n\n
- \n
- 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.<\/li>\n\n\n\n
- Excessive permissions: Assigning excessive permissions to files and users can enable unauthorized manipulation attacks.<\/li>\n\n\n\n
- Poor error handling: revealing sensitive information in error messages can give attackers clues to further exploit the system.<\/li>\n<\/ol>\n\n\n\n\n\n
In addition, there may be vulnerabilities in PHP. The PHP executor itself sometimes contains security holes if not kept up to date. (see image)<\/p>\n\n\n\n
Other vulnerabilities not directly linked to PHP, such as XSS vulnerabilities, are also common. These allow malicious code to be executed.<\/p>\n\n\n\n
Let's see how this works in practice for WordPress.<\/p>\n<\/div>\n\n\n\n
Source: Supported PHP versions<\/a><\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n \nWordPress website vulnerabilities<\/h2>\n\n\n\n
Security vulnerabilities in WordPress<\/h3>\n\n\n\n
\n<\/figure>\n\n\n\nWordPress is a robust content management system, but it includes nearly a million lines of PHP code (924,096 lines<\/a> currently).
WordPress is also 59,772 plugins<\/a> and 11,378 themes<\/a> available on wordpress.org<\/a>. 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.<\/p>\n<\/div>\n\n\n\nDetecting, correcting and revealing vulnerabilities<\/h3>\n\n\n\n
If a party detects a flaw (an individual developer, a \"white hat\", a specialized security organization), it notifies the developers of the script containing the flaw.<\/p>\n\n\n\n
If the developers are reactive, they correct the flaw and publish the patch.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Current flaw not corrected<\/h4>\n\n\n\n
WordPress currently features a uncorrected flaw<\/a> since version 6.1.1 (i.e. several months ago). This allows you to use a website 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).<\/p>\n<\/div>\n\n\n\n
\nWhen is WordPress vulnerable and what can you do about it?<\/h2>\n\n\n\n
Vulnerabilities revealed<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
There are two types of vulnerabilities:<\/p>\n\n\n\n
- \n
- 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.<\/li>\n\n\n\n
- 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).<\/li>\n<\/ul>\n\n\n\n
Zero-day vulnerabilities<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\nTo 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<\/a> 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n<\/div>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
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<\/a>.<\/p>\n\n\n\n
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<\/a>.<\/p>\n\n\n\n
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<\/a> or go directly to my Webmastering<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"
Beaucoup se demandent comment WordPress peut \u00eatre vuln\u00e9rable aux attaques malgr\u00e9 sa popularit\u00e9 et son suivi. D’autres ignorent totalement le risque. Analyse. Qu’est-ce qu’une vuln\u00e9rabilit\u00e9 ? WordPress est programm\u00e9 avec le langage PHP.Le code PHP permet d’obtenir des sites \u00ab\u00a0dynamiques\u00a0\u00bb. C’est \u00e0 dire que le contenu est g\u00e9n\u00e9r\u00e9 \u00e0 chaque page par un programme PHP. […]<\/p>\n","protected":false},"author":1,"featured_media":3339,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24],"tags":[],"class_list":["post-3179","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-securite-wordpress"],"_links":{"self":[{"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/3179","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/comments?post=3179"}],"version-history":[{"count":33,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/3179\/revisions"}],"predecessor-version":[{"id":3371,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/posts\/3179\/revisions\/3371"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/media\/3339"}],"wp:attachment":[{"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/media?parent=3179"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/categories?post=3179"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.lrob.fr\/en\/wp-json\/wp\/v2\/tags?post=3179"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}