The biggest problem with WordPress security isn't WordPress itself, it's with WordPress' extension APIs.
You extend WordPress by writing "themes" and "plugins". Themes are supposed to change how the site looks, while plugins are supposed to change how the site works. But in practice, there's no isolation of capabilities in either case, so it's entirely possible for a plugin to do theme-like stuff and a theme to do plugin-like stuff. Users don't understand this, so they think things like "oh, it's safe to install, it's just a theme."
Worse, there's no isolation between code that comes in via either of these extension mechanisms and WordPress itself. As far as the server is concerned it's all just a big bag of PHP that runs with the same privileges. So a malicious theme or plugin has a lot of scope to do Very Bad Things once it's convinced a user to install it. Users don't understand how the attack surface increases as your installed plugins/themes increase, so they install tons of stuff, sometimes just because "oh this looks fun!"
I don't know how you untangle all this, unfortunately, especially in a system that needs to run well in commodity shared hosting. The only real defense is to be extremely judicious in what extensions you choose to install.
Couldn't some kind of PHP level sandboxing be used to isolate plugins and themes? So for example a theme would not be able to spawn OS processes, access DB connection or create a new one, read and modify HTTP headers.
Comments
The biggest problem with WordPress security isn't WordPress itself, it's with WordPress' extension APIs.
You extend WordPress by writing "themes" and "plugins". Themes are supposed to change how the site looks, while plugins are supposed to change how the site works. But in practice, there's no isolation of capabilities in either case, so it's entirely possible for a plugin to do theme-like stuff and a theme to do plugin-like stuff. Users don't understand this, so they think things like "oh, it's safe to install, it's just a theme."
Worse, there's no isolation between code that comes in via either of these extension mechanisms and WordPress itself. As far as the server is concerned it's all just a big bag of PHP that runs with the same privileges. So a malicious theme or plugin has a lot of scope to do Very Bad Things once it's convinced a user to install it. Users don't understand how the attack surface increases as your installed plugins/themes increase, so they install tons of stuff, sometimes just because "oh this looks fun!"
I don't know how you untangle all this, unfortunately, especially in a system that needs to run well in commodity shared hosting. The only real defense is to be extremely judicious in what extensions you choose to install.
Couldn't some kind of PHP level sandboxing be used to isolate plugins and themes? So for example a theme would not be able to spawn OS processes, access DB connection or create a new one, read and modify HTTP headers.