RuoYi 4.8.3 Role-Based Privilege Escalation Vulnerability and POC

Vulnerability Overview Vulnerability Name: RuoYi 4.8.3 Role Management Privilege Escalation Vulnerability Affected Product: RuoYi (monolithic edition, Spring Boot + Apache Shiro) Vulnerability Type: Privilege Escalation CWE: CWE-863 (Incorrect Authorization) CWE-269 (Improper Privilege Management) Vulnerability Cause: RuoYi stores role permission keys as editable strings and splits them into Shiro roles at the comma delimiter. The role editing path does not prevent ordinary roles from assigning the reserved name to the , and the uniqueness check is based on the raw string rather than the resulting token, leading to its use as an authorization identity later. Consequently, the user is not bound to the administrator role ID 1, nor are wildcard permissions for user ID 1 forged. This represents a boundary omission between the comma-based parsing of and reserved role names, allowing ordinary roles to forge protected admin Shiro role tokens. Impact Scope Affected Versions: 4.8.3 Test Commit: 7995a83e04e1a88aaea5a8a7c50570dffcb145e0 Fixed Version: Unknown Impact Description: Low-privileged authenticated users can bypass the boundary to create attacker-selected tables in the application's MySQL database, leaving generator metadata in . This constitutes unauthorized database schema writing and role privilege bypass. Remediation Remediation Status: Unknown; the comma splitting of has not been addressed. Remediation Suggestions: Prohibit ordinary roles from assigning the reserved name to the . Uniqueness checks should be performed based on the token rather than the raw string. Bind users to administrator role ID 1, or enforce wildcard permissions for user ID 1. POC Code Vulnerability Location Primary Vulnerability Location: POST /system/role/authDataScope parameter Secondary/Proof-of-Concept Vulnerability Location: POST /tool/gen/createTable (@RequiresRoles("admin")) Reproduction Steps 1. The repository HEAD must equal the fixed SHA, and the current commit's ruoyi-admin JAR must be built using Maven. 2. Start a new MySQL 8.0 container with sql/ry_20200319.sql. 3. Start the real ruoyi-admin application container. 4. Log in as ry/admin123 and confirm that create-table is denied before the role key change. 5. Change the role key via the real /system/role/authDataScope endpoint. 6. Open a new login session, invoke the real /tool/gen/createTable, and query the tables and gen_table metadata in MySQL. 7. Delete all tables and metadata created by the PoC, then remove the temporary containers. Vulnerability Exploitation Prerequisites A valid low-privilege account is required. The account must have the permission and must pass the data scope check for the target ordinary role. The repository already contains SQL meeting the following criteria: Role 2 is 'common', User 2 (ry) is bound to Role 2, and Role 2 is linked to plus the code generation menu. The product defaults to Shiro role-based authorization. exists in the product code and is protected by the admin role. Verification uses local MySQL initialized with the bundled SQL. When captcha is enabled by default, the main verification is conducted via . This issue does not depend on captcha configuration. Description RuoYi 4.8.3 (commit 7995a83e04e1a88aaea5a8a7c50570dffcb145e0) allows authenticated ordinary users to change their role key from to via POST /system/role/authDataScope. Upon new login, Shiro treats the user as having the admin role. This is sufficient to bypass at POST /tool/gen/createTable and create tables in the application's MySQL database. This issue is reachable by default with the bundled account. Local Docker verification reproduced the control denial, role key mutation, and post-login DDL write. The same SHA in an independent sub-checkout reproduced the same results.

Goal Reached Thanks to every supporter — we hit 100%!

RuoYi 4.8.3 Role-Based Privilege Escalation Vulnerability and POC

More from this source