CVE-2024-54762

Executive Summary

CVE-2024-54762 is an authenticated SQL injection vulnerability identified in the Ruoyi management system, affecting version 4.7.9 and all prior releases. The flaw resides in the filterKeyword method, which fails to completely sanitize SQL injection keywords, allowing an authenticated user to manipulate backend database queries. Successful exploitation permits attackers to exfiltrate sensitive data, bypass authentication mechanisms, and potentially achieve remote code execution via database-specific features such as xp_cmdshell (on MSSQL) or into outfile (on MySQL). Enterprise environments utilizing Ruoyi as their administrative backend face significant risk of full database compromise, data breach, and lateral movement into adjacent IT infrastructure.

Technical Analysis

Vulnerability Mechanism

The vulnerability originates in Ruoyi's keyword filtering utility, specifically the filterKeyword method located in the common utility layer (typically com.ruoyi.common.utils.sql.SqlUtil). This method is responsible for stripping or neutralizing SQL control characters and keywords from user-supplied parameters before those parameters are concatenated into dynamic SQL statements. The intended purpose is to prevent SQL injection payloads from reaching the database layer.

However, the blacklist-based approach used in filterKeyword is incomplete. The filter regex pattern—historically defined as something like /(select|insert|update|delete|union|into|load_file|outfile)/i—does not account for:

1. Obfuscated keyword casing with inline comments: MySQL and MSSQL both allow SEL/**/ECT or SeLeCt to bypass case-sensitive regex checks.
2. Unicode or hex-encoded keywords: Databases may interpret hex-encoded strings when used with functions such as char() or 0x... literals.
3. Alternative keywords for the same operation: Functions like sys_exec(), udf calls, or information_schema queries are not filtered.
4. Nested subqueries with aliases: The filter may strip the first occurrence of a keyword but leave subsequent occurrences or allow mutation of a copy.

The vulnerable method is invoked in multiple modules including user management, role management, and log querying—wherever "search by keyword" UI fields are rendered. Because the application already requires a valid login, the attacker must possess at least low-privilege credentials (e.g., a default or guessed account) to reach the injection point.

Attack Surface

• Affected versions: Ruoyi ≤ 4.7.9 (up to and including 4.7.9; a patch was claimed for 4.7.10 and later).
• Authentication: Required (authenticated SQL injection). Attackers need a valid session—privilege escalation to admin may be possible from a standard user context.
• Injection points: Search/filter input fields tied to list views for users, roles, posts, jobs, and logs. The parameter is often keyword or filterKeyword passed via HTTP GET or POST.
• Database backend: MySQL, MSSQL, or Oracle (Ruoyi supports multiple). The impact scope differs per backend; MSSQL offers xp_cmdshell for RCE, MySQL offers INTO OUTFILE for web shell deployment.

Code-Level Explanation

Pseudo-code of the flawed method:

public static String filterKeyword(String value) {
    if (StringUtils.isBlank(value)) {
        return value;
    }
    // Incomplete blacklist regex — does not handle inline comments or case mutations recursively
    value = value.replaceAll("(select|insert|update|delete|union|into|load_file|outfile)", "");
    return value;
}

The regex removal processes the string once; it does not loop until no replacement occurs. Thus, a payload like SEL/**/ECT survives because the literal substring SELECT is not present—the comment markers split it. The database, however, strips inline comments during parsing, reconstructing SELECT and executing the attacker's clause. Even a simple uppercase permutation such as SeLeCt bypasses a case-sensitive regex if the pattern lacks the i flag.

Exploitation Scenarios

Step 1: Reconnaissance and Target Identification

1. The attacker scans the internet using Shodan or FOFA for exposed Ruoyi admin consoles (http.title:"若依" or http.component:"Ruoyi").
2. Alternatively, for internal targets, the attacker harvests credentials from phishing or uses default credentials set during onboarding (Ruoyi's default admin/admin123 is very common in test deployments).
3. The attacker enumerates login page and API endpoints under /system/* to identify the framework version via response headers or /api/user/info responses.

Step 2: Authentication and Injection Preparation

1. Attacker logs in with a low-privilege account (e.g., a created test user or a captured session token).
2. Navigates to a route that exposes a keyword search field—typically /system/user/list (User Management) with a query parameter like keyword=xxx.
3. Attacker crafts a baseline request in Burp Suite: GET /system/user/list?keyword=admin&pageNum=1&pageSize=10.

Step 3: Trigger/Weaponization

1. The attacker injects a UNION-based payload designed to bypass the weak filter:

   keyword=admin' AND 1=1 UNION /**/SELECT 1,user(),3,4,5-- -
   

   (Comment /**/ splits UNION, but the database still parses it as a UNION keyword.)
2. Alternatively, for blind injection via time delay (MySQL):

   keyword=admin' AND SLEEP(5)-- -
   

   The SLEEP function is not on the filter blacklist, and the single quote terminates the vulnerable predicate.
3. To confirm injection, the attacker observes a 5-second delayed HTTP response, validating the backend accepts the crafted clause.

Step 4: Payload and Execution

1. Data extraction—the attacker determines current database:

   keyword=admin' AND 1=1 UNION /**/SELECT 1,2,database(),4,5-- -
   

   The response's third column renders the database name (e.g., ruoyi).
2. Table and column enumeration via information_schema.tables and columns queries.
3. Credential harvesting: dumping sys_user table (contains user_name, password hashed with MD5 + salt, and user_id).
4. Escalation to RCE (MSSQL backend):

   keyword=admin'; EXEC xp_cmdshell 'whoami';-- -
   

   If Ruoyi is deployed on MSSQL and the process runs with elevated privileges, the attacker obtains OS command execution.

Step 5: Post-Exploitation Impact

1. Full database dump—company secrets, PII, application config (database passwords, API keys in sys_config).
2. Modify admin user's password hash to achieve persistent admin access.
3. Use the compromised host as a pivot point for internal network scanning and lateral movement (e.g., T1046 — Network Service Scanning).
4. If RCE achieved, deploy a webshell (PHP/JSP) and install persistence mechanisms in the deployment directory.

Impact Assessment

CVSS score: N/A (no official score assigned by NVD; the vector is UNKNOWN). We cannot fabricate a numeric score. However, qualitatively this is a high-severity flaw given the following:

• Confidentiality: High—attacker reads entire database including password hashes, PII, and business secrets.
• Integrity: High—attacker modifies user records, config data, and can inject malicious content into stored XSS sinks (e.g., change an admin's password).
• Availability: Medium—an attacker can drop tables, delete config, or run resource-intensive queries to cause denial-of-service.

Business impact: For organizations running Ruoyi (commonly used in Chinese government and enterprise deployments, but also worldwide via forks/mirrors), an SQL injection means the administrative layer is no longer trustworthy. Audit logs can be falsified; data lineage is compromised. If RCE follows, the server host is fully compromised, widening the blast radius to every network segment reachable from that server.

Affected systems: Ruoyi ≤ 4.7.9 across MySQL/MSSQL/Oracle backends. Note that Ruoyi has a commercial edition ("Ruoyi-Cloud") which may share the same utility code; if the filterKeyword implementation is identical, that edition may also be affected but is not officially listed.

Detection Guidance

Sigma Rule

title: Ruoyi SQL Injection - UNION Select in Keyword Parameter
id: 7b8f2a3e-4c5d-4e6f-9a1b-2c3d4e5f6a7b
status: experimental
description: Detects SQL injection payloads in Ruoyi keyword parameters bypassing filterKeyword blacklist
logsource:
  category: webserver
  product: nginx
  detection:
    selection:
      c-uri|contains:
        - '/system/user/list'
        - '/system/role/list'
        - '/system/log/list'
    payloads:
      c-uri|contains:
        - 'keyword=.*(union|sleep|benchmark|xp_cmdshell|information_schema)'
        - 'keyword=.*%2f%2a%2a%2f'   # encoded /*
    filter_baseline:
      c-uri|contains:
        - 'keyword=admin'
        - 'keyword=%25'              # legit wildcard searches
    condition: selection and (payloads or c-uri|re: 'keyword=[^&]*(%27|%22)') and not filter_baseline
  falsepositives:
    - Administrators legitimately searching for terms containing 'union' (rare)
  level: high
  tags:
    - attack.t1190
    - attack.t1059.007
    - cve.2024.54762

YARA Rule

rule Ruoyi_SQLi_Bypass_FilterKeyword
{
    meta:
        author = "Valtersit Threat Intel"
        description = "Detects SQL injection obfuscation patterns targeting Ruoyi filterKeyword bypass"
        date = "2024-11-18"
        cve = "CVE-2024-54762"
        score = 75
    strings:
        $a = "filterKeyword" ascii nocase
        $b = "keyword=" ascii nocase
        $c1 = "/**/union/**/" ascii nocase
        $c2 = "union/**/select" ascii nocase
        $c3 = "sel/**/ect" ascii nocase
        $c4 = "xp_cmdshell" ascii nocase
        $c5 = "sleep(" ascii nocase
        $c6 = "benchmark(" ascii nocase
        $c7 = "%27" ascii
        $d1 = "/system/user/list" ascii
        $d2 = "/system/role/list" ascii
    condition:
        (uint16(0) == 0x7B7B or uint16(0) == 0x5B5B) and  // JSON or log format wrappers
        any of ($a*) and any of ($c*) and any of ($d*) and $b
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2024-54762 Ruoyi SQL Injection Attempt - UNION bypass filterKeyword"; flow:established,to_server; content:"GET"; http_method; content:"/system/user/list"; http_uri; nocase; content:"keyword="; http_uri; nocase; pcre:"/(union|sleep|benchmark|xp_cmdshell)[\x00-\x20\/\*]*select/i"; http_uri; reference:cve,2024-54762; classtype:web-application-attack; sid:10000001; rev:1;)

Elastic Detection

sequence by source.ip, process.name with maxspan=2m
  [network where process.name == "java" and destination.port == 3306 and
   network.direction == "egress" and
   dns.question.name != null]  // java process connecting to DB
  [process where process.name == "java" and
   command_line like "*filterKeyword*" and
   command_line like "*UNION*" or
   command_line like "*SLEEP*"]

Note: If Java process command line is not instrumented, use a web server proxy log ingestion. An alternate EQL on HTTP logs:

any where event.action == "http.request" and url.path like "/system/*" and
wildcard(url.query, "*union*") and wildcard(url.query, "*keyword*")

Splunk SPL Query

index=web srv_port=80 OR srv_port=443 sourcetype=access_combined
| where match(uri_query, "(?i)keyword=.*(union|sleep|benchmark|xp_cmdshell)")
| where match(uri_query, "(?i)%27|%22|/\\*\\*/union|sel/**/ect")
| eval risk_score = "70"
| eval cve = "CVE-2024-54762"
| table _time, clientip, method, uri, status, useragent, risk_score, cve
| sort -_time

Wazuh OSSEC Rule

<rule id="100547" level="14">
  <decoded>CGI</decoded>
  <match>keyword=</match>
  <regex>(union|sleep|benchmark|xp_cmdshell)</regex>
  <regex>(\%27|'|/\*\*/)</regex>
  <description>Ruoyi SQL Injection (CVE-2024-54762): Suspicious keyword parameter with SQL control characters.</description>
  <mitre>
    <id>T1190</id>
  </mitre>
  <group>web_application_attack,sqli,ruoyi,cve_2024_54762,</group>
</rule>

Tune the regex based on your web server log format (Apache %q vs Nginx $args). If custom WordPress-style CMS logs are used, adjust the regex accordingly.

Mitigation & Patch Guidance

Patch confidence: 2/4 — A single source claims a fix was released for versions after 4.7.9 (i.e., 4.7.10+). This has not been independently confirmed; as of this writing, no official Ruoyi advisory on ruoyi.vip has been linked to the NVD entry.

1. Immediate Mitigations

• Network-layer: Restrict access to the Ruoyi admin console using a Web Application Firewall (WAF) rule that blocks URLs matching /system/* with keyword= and subsequent payload strings (union, sleep, xp_cmdshell) in the query string.
• Application-layer: If code access is available, add a runtime hook in the servlet filter that rejects any request where the keyword parameter contains characters outside [a-zA-Z0-9_%\- ] (whitelist approach).
• Database-layer: Run the database account used by Ruoyi with the least privileges — remove FILE privilege (for INTO OUTFILE), disable xp_cmdshell (for MSSQL) via sp_configure 'show advanced options',1; RECONFIGURE; sp_configure 'xp_cmdshell',0; RECONFIGURE;, and revoke SUPER on MySQL.
• Monitoring: Enable database query logging (MySQL general log, MSSQL extended events) on the Ruoyi schema for a 72-hour window to identify exploitation attempts.

2. Patch/Upgrade Steps

• Claimed fix: Upgrade Ruoyi to version 4.7.10 or newer, which supposedly hardens filterKeyword with a whitelist-based sanitizer.
• Verify before upgrade: Download the patch/diff, locate SqlUtil.java, and confirm the new regex uses a whitelist pattern (e.g., [^a-zA-Z0-9_ ]) rather than a blacklist.
• If the claimed version is unavailable, revert to using the open-source GitHub mirror and cherry-pick any commit referencing filterKeyword sanitization.
• After upgrade, regression-test all keyword search functions (users, roles, posts) to ensure no loss of search functionality.

3. Long-Term Hardening

• Shift to parameterized queries: Ruoyi (and its forks) use MyBatis XML mappers with ${} string concatenation in some queries. Replace all ${} with #{} placeholders in the affected mappers (UserMapper.xml, RoleMapper.xml).
• Authenticated SQLi is a symptom: Audit all utility methods (SqlUtil, SqlHelper) for string concatenation; ban the use of ${} in new code via a linting/pre-commit hook (e.g., Checkstyle rule).
• Credential hygiene: Enforce password rotation on all service accounts shared with the Ruoyi DB user; remove default admin/admin123 credentials in production.
• Network segmentation: Place Ruoyi in an isolated DMZ with egress allow-lists to the database server only.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2024-54762 — (Description confirms patch exists for version 4.7.10; CVSS N/A; CWE unknown).
2. Ruoyi Official Site: http://ruoyi.vip — Vendor homepage; release notes for version 4.7.10+ may document the fix (not independently confirmed).
3. GitHub Mirrors: https://github.com/yangzongzhuan/RuoYi — Popular fork of the project; review commits referencing "filterKeyword" or "SQL 注入" between versions 4.7.9 and 4.7.10.
4. CISA KEV: Not listed (as of this report date); exploit-in-the-wild evidence is limited to researcher chatter in Chinese security forums, with no confirmed vendor-publicized exploitation campaigns.
5. OSINT/Researcher Analysis: Public mention in Nuclei framework's non-official templates directory (template names like cve-2024-54762.yaml circulating in community repos) — treat with caution as CVSS values in those templates are unofficial and unverified.

Threat actor campaigns: No known state-sponsored or criminal campaign specifically targets CVE-2024-54762 as of this writing. However, Ruoyi is a popular target for Chinese-language ransomware groups scanning for exposed admin consoles; given the low barrier for exploitation (default credentials + bypassable filter), opportunist exploitation is likely within 3-6 months of the CVE's public disclosure.