> If you want an auto-update, why not do this with an automatic CI/CD type pipeline that's triggered on new WP versions?

One reason is because WP updates often need database upgrades too. I've been updating using `wp-cli` which can be run via cron -- but I've yet to sort what to do when WP/a plugin needs the 'Upgrade database tables' button clicked.

A CI/CD pipeline would be nice, especially with a verification stage that confirmed the website hadn't changed post-update (yesterday, updating a plugin lost data. Sore point)

>With the frequency that WP sites get attacked, leaving a system in place where an attacker that gets access and can write files that will be executed is just asking for problems.

I do see your point, but wordpress just isn't designed to work that way. And, if you did go through all the hoops to make wordpress okay without write access to files, it still has write access to the database.

I do have other mitigations in place, and feel like the risk profile is fine for what these sites do (informational only).

I'd be happier if the auto update was working as it should though.

But in this case, an auto-updating install would be protected, while a non-updated version would now have the website over-written...

My point is, a publicly facing web application should not have permissions to update it's own code. The possibility of the application being compromised and then having the application modified to support further system compromise it too great.

Well, that's how WP works so we're stuck with it. On the plus side, it makes for a great plugin experience for non-technical users.

Having done WP installs where the only web-user writable area was for uploads (and that is configured to not execute anything), I will have to dispute your assertion. The fact that the vast majority of WP sites are web-user writable is just inertia and/or bad security practices.

You can disable the file write features of WP and remove the online application upgrade feature. This leaves you using your code repo and build system as the proper path to upgrading the code. This allows you to vet any code change to your site, which you should be doing anyway.

Yes, you can do that, but you're fighting the way it is designed.

You mentioned the uploads directory, but there are very common plugins that need write access to other files. Almost every caching plugin for wordpress, as one example.

You also have to replicate the functionality to do upgrades for plugins, themes, and core WP, including ones that need database upgrades.

It's just a risk management decision. In my case, all the hoops to make the filesystem read-only aren't worth it. Retaining the built-in upgrade functionality is of higher value. We have offsite backups and file integrity scanning, and will fall back if needed. If the sites were, say, e-commerce sites, I would have made a different decision.

Upgrades can be a single "composer update" and then committing the composer.lock file. Mine are a bit more as I review changes between versions as well. I am very careful about what plugins I use for this very reason honestly. If it's not well-behaved enough and requires the ability to write outside of uploads then it's not used.