Admin and Site Enhancements (ASE)
Privilege Escalation
Admin and Site Enhancements (ASE) Pro
Privilege Escalation
This blog post is about the Admin and Site Enhancements (ASE) free and pro plugin vulnerability. If you’re an Admin and Site Enhancements (ASE) user, please update the plugin to at least version 7.6.3.
If you are a Patchstack customer, you are protected from this vulnerability already, and no further action is required from you.
For plugin developers, we have security audit services and Enterprise API for hosting companies.
About the Admin and Site Enhancements (ASE) Plugin
The plugin Admin and Site Enhancements (ASE) which has over 100,000 active installations, is one of the admin workflow enhancement plugins in the WordPress ecosystem.
This plugin helps users to easily enhance various admin workflows and site aspects while replacing multiple plugins doing it.
The security vulnerability
Both the free and pro version of the plugin (version 7.6.2.1 and below) suffers from a privilege escalation vulnerability. The vulnerability occurred due to broken logic on the “View Admin as Role” feature where a user can recover their previous role. For example, when a user is initially given an Administrator role and then the role is downgraded to a Subscriber role, the user in this case is able to recover their previous role which is Administrator if the “View Admin as Role” feature is enabled on the plugin. The vulnerability is fixed on version 7.6.3 on both the free and pro versions and has been tracked with CVE-2025-24648 and CVE-2024-43333.
First, let’s check out the “View Admin as Role” feature, which is not enabled by default. Administrators need to enable the feature on the option.
If an administrator, for example, views the site as a Subscriber role, then the original role value of Administrator is stored on _asenha_view_admin_as_original_roles user metadata:
public function role_switcher_to_view_admin_as() {
$current_user = wp_get_current_user();
$current_user_role_slugs = $current_user->roles; // indexed array of current user role slug(s)
$current_user_username = $current_user->user_login;
$options = get_option( ASENHA_SLUG_U, array() );
$options['viewing_admin_as_role_are'] = array();
if ( isset( $_REQUEST['action'] ) && isset( $_REQUEST['role'] ) && isset( $_REQUEST['nonce'] ) ) {
$action = sanitize_text_field( $_REQUEST['action'] );
$new_role = sanitize_text_field( $_REQUEST['role'] );
$nonce = sanitize_text_field( $_REQUEST['nonce'] );
if ( 'switch_role_to' === $action ) {
// Check nonce validity and role existence
$wp_roles = array_keys( wp_roles()->roles ); // indexed array of all WP roles
if ( ! wp_verify_nonce( $nonce, 'asenha_view_admin_as_' . $new_role ) || ! in_array( $new_role, $wp_roles ) ) {
return; // cancel role switching
}
// Get original roles (before role switching) of the current user
$original_role_slugs = get_user_meta( get_current_user_id(), '_asenha_view_admin_as_original_roles', true );
// Store original user role(s) before switching it to another role
if ( empty( $original_role_slugs ) ) {
update_user_meta( get_current_user_id(), '_asenha_view_admin_as_original_roles', $current_user_role_slugs );
}
------------------ CUT HERE ------------------There is also a process to reset the role back:
------------------ CUT HERE ------------------
} elseif ( isset( $_REQUEST['reset-for'] ) ) {
$reset_for_username = sanitize_text_field( $_REQUEST['reset-for'] );
$options = get_option( ASENHA_SLUG_U, array() );
$usernames = $options['viewing_admin_as_role_are'];
if ( ! empty( $reset_for_username ) ) {
if ( in_array( $reset_for_username, $usernames ) ) {
$current_user = get_user_by( 'login', $reset_for_username );
$current_user_role_slugs = $current_user->roles; // indexed array of current user role slug(s)
// Remove all current roles from current user.
foreach ( $current_user_role_slugs as $current_role_slug ) {
$current_user->remove_role( $current_role_slug );
}
// Get original roles (before role switching) of the current user
$original_role_slugs = get_user_meta( $current_user->ID, '_asenha_view_admin_as_original_roles', true );
// Add the original roles to the current user
foreach ( $original_role_slugs as $original_role_slug ) {
$current_user->add_role( $original_role_slug );
}
// Mark that the user has switched back to an administrator role
update_user_meta( $current_user->ID, '_asenha_viewing_admin_as', 'administrator' );
// Remove current user's username from stored usernames.
foreach ( $usernames as $key => $username ) {
if ( $reset_for_username == $username ) {
unset( $usernames[$key] );
}
}
$options['viewing_admin_as_role_are'] = $usernames;
update_option( ASENHA_SLUG_U, $options, true );
------------------ CUT HERE ------------------Since there is no proper check on the process, including a nonce check, users are able to reset the role of any user. In this case, any authenticated users are able to recover back their previous configured role that was already configured via _asenha_view_admin_as_original_roles user meta.
The patch
The vendor patched the issue by adding a function hook to delete the _asenha_view_admin_as_original_roles user meta if there is a profile update on the user (for example, the role is changed). The patch can be seen here.
Conclusion
It is always crucial to ensure that a user’s permission check is not solely reliant on nonce. In case the nonce is leaked somewhere, any user has access to sensitive actions and functions. Along with the nonce check, a strong permission check is important to ensure vulnerability like this one is not introduced in the codebase.
Want to learn more about finding and fixing vulnerabilities?
Explore our Academy to master the art of finding and patching vulnerabilities within the WordPress ecosystem. Dive deep into detailed guides on various vulnerability types, from discovery tactics for researchers to robust fixes for developers. Join us and contribute to our growing knowledge base.
Timeline
Help us make the Internet a safer place
Making the WordPress ecosystem more secure is a team effort, and we believe that plugin developers and security researchers should work together.
- If you’re a plugin developer, join our mVDP program that makes it easier to report, manage and address vulnerabilities in your software.
- If you’re a security researcher, join Patchstack Alliance to report vulnerabilities & earn rewards.
