Even though WordPress is a revolutionary CMS, the biggest strength that a common ecosystem being shared by a number of developers is also its weakness.
Every other day we see a plugin gets hacked, a backdoor entry was found leading to thousands of sites compromised. Its not about quality of Developers but the entire WP ecosystem is vulnerable if just one user/developer makes a mistake, it can expose a vulnerability in some other plugin which is not at fault.
If you just take a look at the news at what rate WordPress sites get hacked, you will be amazed. Here’s a short snapshot of what has been going on.
|Plugin name||Date||Size||Vulnerability reported|
|WooCommerce||July’21||5m||Personal information site site admin revealed including password.|
|June’21||5m||Non-Site Admin redirected. All protected content information can be accessed.|
|Feb’21||0.5m||By pass authentication & become site administrator.|
|Dec’20||5m||File Upload, web-shell & inject malicious scripts. Complete take over of site & Server|
|Dec’20||5m||Hackers can access password reset link and reset any user’s password.|
|Nov’20||5m||Bots can create accounts.|
|Oct’20||1m||SQL Injection & XSS attack from subscriber|
|All in one SEO||July’20||2m||Authenticated Contributor users can inject malicious scripts.|
|May’20||0.5m||Any logged in user can become site administrator,|
Now, WP runs hacker programs rewarding developers for finding hacks in WP but regular WP plugin developers can not afford to run programs like that.
These revealed hacks are published on several blogs which spreads this information to all hackers. The hackers can simply create and run programs which execute on any WordPress site looking for the chink in the armour. And once they are able to find a way in, the server is compromised. From our recent study understanding the nature of hack attempts on one of our clients, it seems the attacks are run automatically and attackers added a action on login_init capturing user’s cookie and sending to a third party site.
If you open the raw access logs of your server [ cpanel – raw access logs ] you can easily locate some entries which look like this :
In simple terms it means if you do not update plugins regularly your site can be potentially hacked. Further there are companies who are spending a huge amount to get those exploits first “before” others.
Practically there are several reasons why you may not put plugins on automatic update mode, because believe it or not every plugin update has the potential to crash the site entirely, because plugin updates are not tested in the innumerable plugin combinations available in WordPress.
Logged-in user Traffic & XSS Attacks
There are many ways a site can be attacked, WordPress is typically vulnerable to XSS attacks because of the plugin ecosystem and the entire authentication is managed via the login cookie. [ link ] . An XSS attack is a cross site scripting and the aim for most such attacks is to capture the logged in user’s authenticated Cookie. According to Open Web Application Security project XSS attacks rank #1 [ source ].
Now, as more and more plugins start using WordPress as a CMS system, new XSS vulnerabilities are exposed every day. Consider a typical Learning Management plugin or a membership plugin for WordPress where majority traffic is from logged in user. Logged in users have access to your sites and limited WordPress functionality even if you restrict WP admin access they still can perform and execute files in WordPress. In blogging sites, only 1 administrator logs in and generates 1 cookie, in membership plugin several users log in and generate cookies. Any one of these users can fall into the trap of clicking a malicious link, leading to expose of their session cookie to a hacker. So instead of 1 user, a membership / lms site is more vulnerable to such attemps. [ ithemes ].
As the traffic is from “logged in” users, they already have the cookie which leads to new type of vulnerability “Privilege escalation”, [a user can become a site administrator] and you’ll be amazed to see the scale of this vulnerability it was recently exposed in Contact form 7, GDPR compliance plugin [source] and in the past exposed in WooCommerce as well.
Big question : Do you want every user in your site to log into your WordPress ? Think again.
WordPress with current market share of 42% of all of internet faces more attacks than any other platform. The attacks will increase in future. If plugins and teams like WooCommerce, ContactForm7, Google site kit can leave security loopholes, there is no confirmation if your site is secure even when you are using plugins from reknown developers.
It might make sense to use a platform where the user only gets the information of what he/she needs and not logging into WordPress. The logged in user is decoupled from WordPress in a Headless CMS system, session less, cookie less login system.
Disclaimer : Self advertisement : VibeBP is one such platform where the logged in user information remains in the browser. The authentication happens via JWT token which is an entirely different login system compared to WordPress and you can chose not to store the tokens at all. JWT tokens can not be edited and become void for other user. Since everything runs in HeadLess, the users do not log into WordPress and are only able to perform tasks the API’s are designed to perform. That is a security which may be required in building long term projects on WordPress.