Most attacked, sure. Most exploited? You get out of it what you put into it. If you work to make it more secure, it will stay more secure, popular or not.

WordPress is a software design from the early 2000's - and not a particularly good example. Even back then there were more secure designs.

Take QMail for example. A simple design, it had security baked in from the start, and remains one of the most secure software packages in history. This exploit would have been prevented if WordPress had followed QMail's security designs. Enforced data flow, avoidance of parsing, eliminating untrusted code, and eliminating bugs by choosing code paths with fewer variables, would've all prevented this bug.

DJB wrote a paper on QMail[1] to try to explain what worked and what was unnecessary. Anyone implementing new software (and wants it to be secure) should consider these [and other] design points. Popular software doesn't have to be bad software. [1] https://cr.yp.to/qmail/qmailsec-20071101.pdf

That's bad designs for you. Assume that just because it's widely visible, must mean it has exploits. (this is the only point on that list I'll call "that's bad logic" on).

And it's very extensible. With that power and flexibility come exploits

How many times has Google been hacked? It's not zero, but just because something is popular doesn't mean it has to get exploited. Repeatedly.

Yes and Wordpress is a pile of garbage.

WordPress’s security model is distilled insanity, concentrated vulnerability. You’re supposed to give your site write access to its code, which turns almost any vulnerability into complete and persistent site takeover. Not to mention how many things will store code in the database and execute it from there, and how much of its design is fragile as anything, and how many plugins, often popular ones, do obviously dumb things that would not have been possible in most ecosystems.

Drupal (also popular in governments and such), by contrast, will check that it can’t write to anything but its designated file uploads directory, and complain if it can, and has careful guidance around avoiding letting uploads be accidentally executable too. The blast radius of the typical vulnerability, and the possibility of persistent takeover, is drastically reduced.

It’s possible to use C correctly, but in practice using it invites security problems, because it’s frightfully easy to make subtle but disastrous mistakes, even for experts, so there are reasons why people are moving to safe languages.

WordPress is that kind of bad. It has always been bad, though it’s somewhat less bad than it used to be. Some of its badness is a part of how it got popular.

Yeah, I agree that with the right expertise you can keep WordPress safe, and the White House is a good example of that. But the problem is the WP ecosystem and defaults push people without that expertise to install plugins and themes, and "if you know what you're doing" is the exception, not the rule for its user base

> If you know what you're doing, WordPress fine.

Probably true, but for whatever reason Wordpress seems to attract an awful lot of people that do not know what they are doing

I think the problem is of another nature:

People who _don't_ know what they are doing are using WP for every project, that they touch, because it is all they know. Given WPs database design, the assumptions baked into that, and the complications resulting from that, make anything other than a posts and pages website a PITA.

This in turn requires one to install shitty plugins, or spend time developing a minimalistic solution to each new challenge. With every plugin the attack surface grows, and the vast majority of larger WP sites is this cobbled together mess of WP plugins, having some WP expert trying to make them all work together without stepping on each other's toes, while hopelessly falling behind on updates, because updates could, and _will_ break things.

People only knowing PHP and WP, try to use WP as a sledgehammer, not realizing that hammer actually being made out of glass. Very few plugins are actually minimalistic, no-bloat, safe, well-developed. Lots of those plugins are 80% marketing fluff and wanting to make a business out of worse than mediocre code bases. That's also due to many people in that community being exactly those, who don't know anything but WP.

Even normal core WP updates can break the legality of ones site. I have had that at some point, where after some WP update it started loading emojis from a friggin third party, to replace the unicode symbol I had used. I was furious, because this needs to be part of the data protection policies/statements. One does not simply load a third party shit, replacing what the dev actually put there, which was just a unicode symbol. That's an idiotic thing to do. If I wanted third-party emojis, I would have included them myself.

Finally, some big pages run on WP says not much, given the catastrophic state of many websites. whitehouse.gov is laughably badly made. Another complete failure. The first thing I see that it loads Google tags manager. A government site loading shit.

    fonts.googleapis.com
    googletagmanager.com
    gstatic.com
    parsely.com

All this crap. And this is only what is loaded right out of the box. I haven't even allowed their shitty scripts to run yet.

And the navigation font is tiiiny. What a horrendous design.

When I click on some navigation link, it wants to go to:

    https://www.whitehouse.gov/wp-content/uploads/2026/01/Wide_Site_Primary_02.mp4

lol. From nav directly to some mp4 video?? Not a URL of a page, which then would display the video, but a URL directly to a video? Good that my noscript blocked media on that domain!

If it is a prime example, then it is a prime example of a very shitty made website, by people, who don't know what they should be doing.

So all this shows is one can make a shitty site using WP. Great. I am sure one can also make a not shitty site using WP. Like you say, _"If you know what you are doing ..."_. Just that most WP people don't. They don't know how to not make a mess, or choose the short-term easy way out, and install tons of shitty plugins. Many of them just have to put things up once initially and are paid, or hold the hand open for some maintenance fee they extract, required only due to how badly made these WP sites are.

It seems the most common issue of them all is an exposed .env file by that measure.

Yep I see this at work pretty regularly - a SpringBoot log file full of requests for all sorts of things (mostly WordPress but I think some IIS as well).

Not success rate per request though.

Joomla makes WP look like Fort Knox.

A tale as old as time... I made money by outsourcing to third party labour to a much cheaper country than my own, using a third party low code theme builder and third party plugins I didn't vet. All of my customers got hacked.

This is the problem WordPress faces - it's powerful enough for people to get stuff done on a shoestring. But the professionals who want to do things on a shoestring are also likely cutting corners elsewhere (hosting, backups, security, etc). In many cases there's money changing hands and it's easier to blame WordPress than poor decision making.

I have more sympathy for those building with it on a shoestring for personal/charitable projects who may lack the skills/experience to follow https://developer.wordpress.org/advanced-administration/secu.... They're probably better off on Wix or Squarespace.

WP won by having a very simple but flexible admin page.

Drupal admin was not for humans back then.

Wordpress wasn't even first, Movable Type was the big thing before it.

This! My customers love that they can call and email me to update their websites, not having to remember usernames, passwords and how the publish interface works. Wordpess or static does not really matter in many cases.

To be clear, those are CVEs in the tooling, not in the generated static sites. Not great, but very different from this WordPress CVE

I have full control over the inputs for hugo and the output is pure static HTML. It's better if there are no CVEs but I really don't sweat these. My Hugo template runs 100% pure CSS and no JS.

This seems like a really good example of Base CVSS scores not telling us much on their own.

For the Wordpress RCE (nominally CVSS 9.2), it looks like many standard deployments of WordPress would be affected, barring extra mitigations. But in the case of these Hugo ones (9.3), it looks like very specific circumstances (anti-mitigations, if you will) are needed. E.g. running arbitrary builds of untrusted user content without a sandbox; running it in a GitHub workflow against PRs from untrusted contributors, etc.

I had the same itch when I ported my personal blog from WordPress to Astro. I built a fully customisable self-hosted comment system called Discuss. It's got a dashboard and tokenized UI customisation. Pretty light weight too. It's available here - https://github.com/karthikeyankc/discuss . Do give it a spin or fork it. Would love to hear your feedback.

I think you can render Disqus on static websites, but Disqus is its own piece of crap so not sure you'd want to.

Yes! https://comments.purecommons.org/