Most usage of Wordpress today are definably not blogs, but full blown websites with many functionalities not found on a blogging software.
I don't know what the dynamics are for WordPress plugin developers to write this much vulnerable code, but WordPress itself has had very few vulnerabilities over the years. Even still, the vulnerabilities this plugin exploits have CVE numbers starting with 2016 and 2019.
I'd say that you can use WordPress for websites perfectly fine as long as you maintain your web server platform like any web server platform: with regular security updates and migration or mitigation plans if those updates are breaking anything. Running a website under your own control is not the one-time setup that many WordPress hosting sites promise customers. It usually doesn't take much time to hit the update button, but if you can't spend an hour a week/month making sure your website is still up to date, you shouldn't host your own stuff. Pay someone to manage it for you instead.
I think it’s a microcosm of the larger PHP problem: it’s a language and environment which is really easy to get started with, but requires significant skill and experience to use safely. The core developers of both have made some improvements but the community culture still has room to go and there’s a huge discoverability / training gap for all of the people who are just getting started — WordPress is incredibly popular so there’s a constant stream of people who just want to change their site and haven’t thought about all of the different angles for attack.
More importantly, however, note that I mentioned the cultural components: people learn bad habits from all of the old tutorials and tons of low-quality code floating around, and there isn't a culture of aggressively correcting that. The half-life on that stuff is a lot longer than the time it'll take to get people to upgrade to PHP 8, especially when more people got some Facebook-style “move fast and break things” ideas without the “… use linters and write tons of tests so you can ship that often” part.
- WordPress's documentation for plugin development is not great, especially for new plugin developers. Somebody recently posted a link on HN to a small WP plugin they had developed, and it took only a few minutes to spot several things that were a bit wrong with their plugin. It wasn't their fault; the only way to know these things are wrong is by having some trial-and-error experience with the platform. There are a variety of plugin templates floating around, many of them aren't kept up to date, and none of them are designed to guide new plugin developers through all of the process.
- WP core largely allows plugin developers to do whatever they want. There are no built-in guardrails or restrictions on how to do things like handle user input or file uploads. You can choose to use WP's APIs, or ignore them and roll your own. Because of the first issue, developers often roll their own.
- The WP ecosystem is highly commercialized. WP site owners are conditioned to pay for features, and developers are incentivized to build plugins as cheaply as possible and charge for them.
- Stock out-of-the-box WP is basically just a blogging engine. Any other feature you might want to add gets delivered as a separate plugin. Because of the commercialization aspect, it's more common to install 5 different plugins to handle 5 features, rather than one "suite" plugin.
- It's really easy to install a plugin. There's a store. You enter a search term and click "install". Non-technical site owners do this all the time. In an ideal world, that would be really cool, but the downside is that they have no ability to evaluate the quality or safety of different plugins.
- So, most WP sites end up looking like an accreting disk of plugins. I've seen sites with nearly a hundred plugins installed.
- WP has some pretty good auto-update features baked in -- critical updates can be automatically installed and regular automatic updates can be enabled -- but a busted update can still break a site, and because of the commercialization of plugins, license and renewal problems can prevent security updates from getting installed. Because of the a la carte aspect of the WP ecosystem, dependencies can creep in that cause complications with updates. Every agency I've worked with that has WP sites has got some stale or broken updates on one or more of their sites. I've yet to see an agency that has everything fully up to date; it takes dedicated effort to do that, and once the development phase of a site is over and done with, site owners and agencies/developers don't want to continue sinking a ton of money into maintenance. They want fire-and-forget.
- WP has entirely ignored all of the modern changes to PHP development. There's no built-in support for composer. WP is PHP 8-compatible, but doesn't take advantage of its features. Because every WP database contains a hairy mix of configuration, content, and sometimes code, you can't do proper branch development for entire WP sites. There was a project that tried to drag WP kicking and screaming into modern branch development (https://versionpress.com/), but the release of Gutenberg forced these developers to start over and they walked away. This is exactly the sort of problem WP core should be addressing, but they aren't interested.
- This all means that the most talented developers largely want nothing to do with WordPress. Well-managed development processes are extremely painful, there's money in it but the money's better elsewhere, maintenance is a drag, and you too often have to troubleshoot some other plugin developer's conflict with your code.
- Last but not least, there's a "code review" process involved in uploading a WP plugin to their plugin repository, but it's not great. They have some really misguided notions of "security". I worked on a project that integrated a modern code editor into a plugin, which would have been a step in the right direction for managing one aspect of a WP site. (You often need a way to deploy small bits of custom code on a per-page or per-category basis, and managing these little bits of code with existing tooling is terrible.) This update got rejected by WP's security team. We had a lot of back-and-forth about it; their position was that having a modern code editor embedded in the site makes it less secure. They couldn't explain how it was different from any other of the built-in customizations available to site administrators, they just didn't like the idea of it. A plain text box for snippets? Sure! Copy-and-paste random stuff you find on the web? Sure! Using WP core's built-in editor for the functions.php file? Sure! Embedding CodeMirror? No way!
Altogether, it's a really big mess and I don't foresee it ever getting better. WP core can't make any of the big changes that would be needed to address some of these because it would cause too much friction with users, agencies, and the rotten plugin ecosystem.
I've had an arms-length relationship with WP for years, essentially seeing it as a valuable tool for non-savvy people to quickly and cheaply DIY a website, but WP is actively hostile towards modern development practices and after my last exchange with their review team I gave up on the platform for good. Dealing with WordPress hurts my soul every time. I'd rather do anything else.
I took over a site - woocommerce install - with ... 68 plugins. When I've mentioned that over the years it's almost always met with "no, that's not right - no one does that - you don't know what you're talking about - they did it wrong"... etc.
Thanks for reiterating this. When 'redir ssl' and 'log visitor' and 'Fedex' and 'ups' and 'usps' and 'shrink image' functionality are all externalized to different vendors, the 'modularity' of a system requires trusting dozens of disparate development processes, greatly increasing the potential for security problems.
Akismet, WordFence or iThemes "Security", Contact Form 7 (and its extensions), WooCommerce (and its pile of extensions), one (or more!) page builders, WP Super Cache, Yoast (and related), a sidebar widget, a chat widget, a Google Tag Manager widget, social media plugins...
The M&A approach to WP development is often, "it's broken, let's see if we can fix it by installing a plugin..."
The reliance on plugins to do a lot of heavy lifting (admittedly, a lot of these stray far from the original blog engine WP provides) but that is because WP is used as more than a blog now, more than a CMS, it's like a core with a myriad of swiss army knife appendages.
1. Random person who doesn't know anything about computers has stumbled their way into having a wordpress site
2. This person wants their site to do something special
3. This person can't find it online
4. This person decides not to give up and cobbles something together using random decade old examples from online
5. This person decides to share their work on the wordpress plugin store
6. Many wordpress sites get hacked
The core WordPress is one of the most secure software in the world: there are thousands of people trying all the time to find exploits and the codebase is public. Go take a look at what CMS whitehouse.gov (one of the highest-profile hacking targets out there) is using.
While I believe the core is reasonably secure, lots of plugins and webhosts aren't. Simply making the website code read-only would take care of a lot of issues, but then your auto-update won't work.
I've had a few customer's sites on WP for decades without any hacks. But I also carefully restrict their plug-ins, and disable PHP in any of the upload directories.
Anyone with any ability to write a little PHP would be far far better off building their site in a CMS like ProcessWire [1], which has a very small core, but a extremely powerful content (PHP) API [2], which means you can replicate pretty much everything you have in Wordpress and Drupal with a few API calls in your templates.
This means you build your listing and presentation-logic custom made with the minimal amount of code needed, and the attack vector shrinks to pretty much nothing, as long as you don't voluntarily do something stupid.