This weakness occurs when a user is assigned to the wrong group or role, causing them to receive permissions they shouldn't have or lose permissions they need…
This weakness occurs when a user is assigned to the wrong group or role, causing them to receive permissions they shouldn't have or lose permissions they need. It's a logic flaw in access control that can lead to privilege escalation, unauthorized data access, or denial of service. Unlike injection or authentication bypasses, this vulnerability lives in the business logic that decides *who belongs where*.
Group membership is typically determined during user creation, account updates, or role-assignment workflows. The vulnerability arises when the code that assigns groups fails to validate the request properly, uses incorrect conditional logic, trusts unvalidated user input to determine group membership, or applies group changes inconsistently across different code paths. For example, a registration form might allow users to select their own role, or an admin panel might fail to check whether the person making the assignment has permission to do so. In some cases, default group assignments are applied incorrectly, or group membership is cached and never refreshed when it should be.
A user placed in an admin group gains access to sensitive settings, user data, or system configuration they should never see. Conversely, a user incorrectly removed from a required group may lose legitimate access to their own data or critical functions. In multi-tenant systems, incorrect group placement can expose one customer's data to another. The impact ranges from privilege escalation (a regular user becoming an administrator) to data breaches (a user gaining access to financial records or personal information) to operational disruption (legitimate users locked out of necessary features).
def register_user(username, email, password, role_input):
user = User(username=username, email=email)
user.set_password(password)
# Directly trusts user-supplied role input
user.group = Group.objects.get(name=role_input)
user.save()
return userWhy it's vulnerable:
The code accepts a role_input parameter directly from the request and assigns the user to that group without validation. An attacker can register with role_input="admin" and gain administrative privileges.
def register_user(username, email, password):
user = User(username=username, email=email)
user.set_password(password)
# Always assign new users to a default, unprivileged group
default_group = Group.objects.get(name="standard_user")
user.group = default_group
user.save()
return userfunction update_user_group($user_id, $new_group) {
global $wpdb;
// No check that current user has permission to change groups
$wpdb->update(
$wpdb->users,
array('user_group' => $new_group),
array('ID' => $user_id)
);
}
// Called directly from $_POST without validation
if ($_POST['action'] === 'change_group') {
update_user_group($_POST['user_id'], $_POST['new_group']);
}Why it's vulnerable:
The function trusts the new_group parameter and doesn't verify that the caller has permission to assign groups. Any logged-in user can promote themselves or others to any group.
function update_user_group($user_id, $new_group) {
global $wpdb;
// Verify caller is an admin
if (!current_user_can('manage_users')) {
return new WP_Error('unauthorized', 'You do not have permission to change user groups.');
}
// Validate new_group against a whitelist of allowed groups
$allowed_groups = array('subscriber', 'contributor', 'editor');
if (!in_array($new_group, $allowed_groups, true)) {
return new WP_Error('invalid_group', 'Invalid group specified.');
}
$wpdb->update(
$wpdb->users,
array('user_group' => $new_group),
array('ID' => $user_id)
);
}
if ($_POST['action'] === 'change_group') {
update_user_group($_POST['user_id'], $_POST['new_group']);
}manage_users or equivalent permission before allowing any change.
Check your user and group tables for unexpected memberships — for example, regular users in admin groups, or users in groups they should not belong to based on their role or department. Review access logs for unusual activity by users who recently had their group changed, or for group-change operations performed by users who shouldn't have that permission. If you notice users reporting access to features or data they shouldn't have, or conversely, legitimate users suddenly locked out of their own data, investigate recent group assignments.
