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.

> You’re supposed to give your site write access to its code

You do not need to. Its to help people who cannot manage an ssh login update. You can use the cli to update if you can. I am pretty sure big sites will not be doing their updates from the big site.

The problem with plugins is lack of a proper framework. Its very easy to do things like pass user inputs into a query by strong concatenation because you have to make in extra effort to not do so.

That said, its no guarantee. I have seen people do things like call exec on user inputs in Django.

> has careful guidance around avoiding letting uploads be accidentally executable too.

That should be the default, not something you need to take extra care over.