CVE-2026-63102: rConfig Core Privilege Escalation Flaw

CVE-2026-63102 Overview

CVE-2026-63102 is a privilege escalation vulnerability in rConfig Core versions prior to 8.2.8. The flaw exists in the Users API, where the role field is accepted without allowlist validation or an admin-level authorization check. Authenticated users can submit an arbitrary role value during user creation or profile updates and have it mass-assigned directly to the User model. This lets a low-privileged account promote itself, or any other account, to Admin and gain access to privileged functionality. The vulnerability is tracked under [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes]. rConfig Pro and Enterprise editions are not affected.

Critical Impact
Any authenticated rConfig Core user can assign themselves the Admin role through the Users API, gaining full administrative access to the network configuration management platform.

Affected Products

rConfig Core versions prior to 8.2.8
rConfig Core Users API endpoint (user create and update)
Not affected: rConfig Pro and rConfig Enterprise

Discovery Timeline

2026-07-20 - CVE-2026-63102 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-63102

Vulnerability Analysis

The vulnerability resides in app/Http/Requests/StoreUserRequest.php, which handles validation and authorization for user create and update requests. The authorize() method previously returned true for any authenticated session, and the validation rules did not constrain the role field to a defined set of values. Because the controller mass-assigned request input to the User model, an attacker could set role=Admin on their own profile update request or when creating a new account. The result is horizontal-to-vertical privilege escalation from a standard authenticated user to an administrator without any additional workflow steps.

Root Cause

The root cause is a combination of missing input allowlisting and missing role-based authorization. The role field was trusted directly from client input and passed to Laravel's mass assignment on the User model. There was no check confirming the acting user held the Admin role before allowing an Admin value to be persisted. This pattern maps to [CWE-915], where dynamically determined object attributes are modified without adequate control.

Attack Vector

Exploitation requires only a valid low-privileged session on rConfig Core. An attacker sends an authenticated HTTP request to the Users API with role=Admin in the body, either while updating their own profile or while creating a new user. The server accepts the value and stores it, immediately elevating the target account. No user interaction is needed on the victim side, and the attack occurs over the network against the standard application interface.

php

     /**
      * Determine if the user is authorized to make this request.
      *
+     * Only an existing Admin may set or change a user's role to Admin, whether
+     * creating a new user, updating another user, or updating their own account.
+     * Any other requested role is left to the validation rules below.
+     *
      * @return bool
      */
     public function authorize()
     {
-        return auth()->check(); // returning true if user is logged in
+        $actingUser = $this->user();
+
+        if (! $actingUser) {
+            return false;
+        }
+
+        if ($this->input('role') !== 'Admin') {
+            return true;
+        }
+
+        return in_array($actingUser->role, ['Admin', 'admin'], true);
     }

Source: GitHub Commit 84822f4. The patch tightens authorize() so only existing administrators can assign the Admin role, and pairs this with allowlist validation on the role field.

Detection Methods for CVE-2026-63102

Indicators of Compromise

HTTP requests to Users API endpoints (POST /api/users, PUT /api/users/{id}, or profile update routes) containing a role parameter with the value Admin.
Unexpected changes to the role column in the users database table for accounts that were not previously administrators.
New Admin accounts created outside of the normal user provisioning workflow or by non-admin session identifiers.

Detection Strategies

Inspect web server and application logs for authenticated POST or PUT calls to user-management endpoints that include role in the request body.
Correlate the acting user's session identity with the resulting role change and alert when a non-admin session assigns the Admin role.
Baseline the frequency of role changes in rConfig and flag deviations, particularly self-service updates that elevate privilege.

Monitoring Recommendations

Enable audit logging on rConfig user management actions and forward logs to a centralized SIEM for retention and correlation.
Track authentication events immediately following role changes to detect attackers exercising newly gained administrative capabilities.
Monitor egress from the rConfig host for unusual configuration exports, since administrative access exposes stored network device credentials and configs.

How to Mitigate CVE-2026-63102

Immediate Actions Required

Upgrade rConfig Core to version 8.2.8 or later, which includes the fix in StoreUserRequest.
Audit all existing accounts in the users table and remove or downgrade any unexpected Admin role assignments.
Rotate credentials for network devices managed by rConfig if unauthorized administrative access is suspected, since configurations and credentials may have been exposed.

Patch Information

The fix is available in rConfig Core 8.2.8. See the GitHub Release Notes for core-8.2.8, the Pull Request 325, and the VulnCheck Security Advisory for full details. The patch restricts the role field to an allowlist and requires the acting user to already hold the Admin role before an Admin assignment is authorized.

Workarounds

Restrict network access to the rConfig web interface and Users API to trusted administrative networks until the upgrade is applied.
Disable self-service user account creation and profile role editing at the reverse proxy or WAF layer by blocking requests that contain a role field from non-admin sessions.
Review and reduce the number of authenticated accounts on rConfig Core to limit the pool of users who could exploit the flaw.

bash

# Example NGINX rule to block role-field tampering on user endpoints
# Place inside the server block fronting rConfig
location ~ ^/api/users {
    if ($request_method ~ ^(POST|PUT|PATCH)$) {
        # Reject requests containing a role parameter until patched
        if ($request_body ~* "\"role\"\s*:\s*\"Admin\"") {
            return 403;
        }
    }
    proxy_pass http://rconfig_backend;
}