[wp-trac] [WordPress Trac] #59109: Prevent plugins from creating admin accounts

WordPress Trac noreply at wordpress.org
Tue Aug 15 16:38:19 UTC 2023


#59109: Prevent plugins from creating admin accounts
--------------------------+------------------------------
 Reporter:  tspnet        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Plugins       |     Version:  6.3
 Severity:  normal        |  Resolution:
 Keywords:  close         |     Focuses:
--------------------------+------------------------------
Changes (by knutsp):

 * keywords:   => close


Comment:

 Plugins and themes extend WordPress, the main application. When loaded
 they become an integral part of the main appliaction in a single process.
 While some processing and internal data can be protected through soft
 barriers like encapsulation, like objects, anu part can access all
 resources, like files and the database, som no stored secrets. Being open
 source any software algorithm is free to investigate and simulate.

 WordPress explses interal and external APIs. The externals can easily be
 restericted ond no way to bypass. The internal APIs are only there to make
 it simpler do do things right. Any plugin or theme may access the database
 and the file system, either through a high level API (`create_user`), low
 level API (`$wpdb`) or more directly using PHP or loaded PHP extensions.

 Plugins and themes have to be **trusted**. If not trusted, do not install
 it. It is as simple and as brutal as that.

 So to do this, either
 1. An independet governing party/instance (process with an API), like
 wordpress.org, would have to confirm every user creation and/or user login
 and all hooks from the authentication process has to be removed.
 2. Plugins and themes has to be redefined as external applications running
 in isolated processes with very limited rights, and WordPress would have
 to be rewritten as an operating system, with own isolated processes.

 This looks like having to tear down both WordPress Core, the whole
 WordPress ecosystem, and rebiuld it from scratch, as flawed.

 Yes, the "flaw" is that the WordPress ecosystem is trust based. It puts a
 lot of responsibility on the site owner, depending on how secure the whole
 system and data must be, from chosing a web host, and depending on
 knowledge, inspection code, reading reviews by others users, trusting the
 plugin repo maintainers and the alert/suspension practices - and possibly
 installing the most trusted security plugin or subscribe to security
 reports.

 The success of WordPress is, among other factors, that it is trust based.
 We are a community and we create open source, that anyone can make better
 and share alike. This is not a practical choice. It's the very foundation.
 And it's very secure and trustworthy, or else half the web had crumbled
 down. And you can make is as secure as you like and have the skills to -
 no limit to what yiu can bould into it and around it.

 So, if insisting on paradigms like "zero trust" on all levels up to the
 user application, you can't use WordPress.

 As both points above is out of the question and no starters, some has to
 come up with a completely different approach, more in the line of the
 nature of WordPress. It could be so simple as special, externally
 triggered, alerts when a new, somewhat suspicious administrator account is
 detected. But I will probably doubt it cant't be circumvented by a smart
 programmer, and we are probabbly back at current status quite soon.

 Suggest wontfix.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59109#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list