Opened 7 years ago
Last modified 10 days ago
#46744 assigned enhancement
Prevent default_role being set to dangerous values
| Reported by: | dd32 | Owned by: | johnbillion |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.2 |
| Component: | Options, Meta APIs | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
Description
A number of vulnerabilities have occurred in plugins which allow setting arbitrary options, similar to #46705 I think it's worth preventing default_role being set to administrator while users_can_register is enabled.
I'd suggest it being implemented as a run-time filter on the default_role value so that plugins can disable the functionality (plus some UI magic), but basically:
function filter_default_role( $default_role ) {
// $users_can_register = ....
if ( $users_can_register && get_role( $default_role )->has_cap( 'manage_options' /* or other cap deemed useful, `publish_posts` could also be used */ ) ) {
$default_role = 'subscriber';
}
return $default_role;
}
#46705 may render this invalid, but this would protect against an options-overwrite bug having much more impact (where a bot overwrites the above values, gets an administrator account, adds PHP to theme files or installs malicious plugins, etc).
Change History (4)
#2
@
7 years ago
- Keywords close removed
- Milestone Awaiting Review
- Resolution → duplicate
- Status new → closed
I think that's fair, @kraftbj.
@dd32 feel free to reopen if you feel this is inaccurate. Otherwise, please add any additional thoughts to #43936.
#3
@
10 days ago
- Milestone → 7.2
- Resolution duplicate
- Status closed → reopened
Reopening per https://core.trac.wordpress.org/ticket/43936#comment:87 .
Let's harden this further with enforcement at the code level.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
I'd consider this a duplicate of #43936.