CVE-2026-63102: 
rConfig vulnerability analysis and mitigation

CVE-2026-63102 is a privilege escalation vulnerability in rConfig Core before version 8.2.8 that allows authenticated users to assign arbitrary roles — including the Admin role — to any account via the Users API. The flaw exists in the StoreUserRequest handler, which previously only checked whether the caller was logged in, without validating the submitted role value against an allowlist or verifying that the acting user held admin privileges. It was published on July 20, 2026, and affects only rConfig v8 Core; rConfig Pro and Enterprise editions are not affected. The vulnerability carries a CVSS v3.1 base score of 5.4 (Medium) and a CVSS v4.0 base score of 5.3 (Medium) (Github Advisory, Feedly).

The root cause is classified as CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes). In the vulnerable code, StoreUserRequest::authorize() returned true as long as the caller was authenticated (auth()->check()), and the role validation rule only required the field to be present ('role' => 'required') without restricting its value. This allowed any authenticated user to submit role=Admin in a POST to /api/users (user creation) or a PATCH to /api/users/{id} (profile update), causing the User model to mass-assign the Admin role directly. The fix, introduced in commit 84822f4, added an in:Admin,User allowlist to the validation rule and updated authorize() to require the acting user to already hold the Admin role before granting it to any account (rConfig PR #325, rConfig Commit).

Successful exploitation allows any authenticated user — including low-privileged accounts — to elevate themselves or any other account to the Admin role, gaining unrestricted access to privileged features and administrative functionality within rConfig Core. This includes access to sensitive network device configuration data managed by rConfig, the ability to create or modify other user accounts, and access to privileged interfaces such as the Horizon queue dashboard. There is no direct availability impact, but the confidentiality and integrity of managed network configurations and user data are at risk (Github Advisory, Feedly).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.246% (16th percentile), indicating a low near-term exploitation probability. Exploitation requires a valid authenticated session but no special privileges beyond a standard user account, making it low-complexity once access is obtained (Github Advisory, Feedly).

1. Obtain authenticated access: Log in to the rConfig Core instance with any valid user account (standard User role is sufficient).
2. Identify the Users API endpoint: Confirm the target is running rConfig v8 Core before 8.2.8 by reviewing version information accessible post-login.
3. Craft a privilege escalation request for self-elevation: Send a PATCH request to /api/users/{your_user_id} with a JSON body including "role": "Admin" along with required fields (name, email, password, repeat_password).
4. Alternatively, create a new Admin account: Send a POST request to /api/users with "role": "Admin" and valid user details to mint a new administrator account.
5. Confirm privilege escalation: Log in with the modified or newly created account and verify access to admin-only features such as the Horizon dashboard or user management functions.
6. Leverage admin access: Use the newly granted Admin role to access sensitive network device configurations, manage other user accounts, or further pivot within the rConfig environment (rConfig PR #325, rConfig Commit).

• Network/Logs: HTTP POST requests to /api/users or PATCH requests to /api/users/{id} from non-admin authenticated sessions containing "role": "Admin" in the request body.
• Logs: Application logs showing successful user creation or update events where the resulting user record has role=Admin but the acting user was not previously an administrator.
• Database: Unexpected entries in the users table where role is set to Admin for accounts that should not hold that privilege; audit user creation timestamps against known administrative activity.
• Application Behavior: Non-admin users accessing the Horizon dashboard (/horizon) or other admin-restricted endpoints without a prior legitimate role change by an administrator.

Update rConfig Core to version 8.2.8 or later, which introduces allowlist validation (in:Admin,User) on the role field and requires the acting user to already hold the Admin role before granting it to any account (rConfig Release). After upgrading, audit all existing user accounts in the users table for unauthorized role=Admin assignments and revert any that were not legitimately granted. As an interim measure if immediate upgrade is not possible, restrict API access to the /api/users endpoint to trusted administrator accounts only via network-level controls or application firewall rules (Github Advisory).