CVE-2023-1454: Jeecg Boot SQL Injection Vulnerability

CVE-2023-1454 Overview

A critical SQL injection vulnerability has been identified in jeecg-boot version 3.5.0, a popular Java-based low-code development platform. The vulnerability exists in the jmreport/qurestSql file, where improper handling of the apiSelectId parameter allows attackers to inject malicious SQL commands. This vulnerability can be exploited remotely without authentication, enabling attackers to read, modify, or delete database contents, potentially leading to complete system compromise.

Critical Impact

This SQL injection vulnerability allows unauthenticated remote attackers to execute arbitrary SQL commands against the backend database, potentially exposing sensitive data, modifying records, or achieving full database compromise.

Affected Products

• jeecg-boot 3.5.0
• Jeecg Jeecg Boot (cpe:2.3:a:jeecg:jeecg_boot:3.5.0)

Discovery Timeline

• 2023-03-17 - CVE-2023-1454 published to NVD
• 2026-01-02 - Last updated in NVD database

Technical Details for CVE-2023-1454

Vulnerability Analysis

This vulnerability represents a classic SQL injection flaw stemming from insufficient input validation in the jeecg-boot reporting module. The jmreport/qurestSql endpoint accepts the apiSelectId parameter and incorporates it directly into SQL queries without proper sanitization or parameterized query implementation. This allows attackers to manipulate the database query logic by injecting specially crafted SQL syntax.

The network-accessible nature of this vulnerability means attackers can exploit it remotely without requiring any prior authentication or user interaction. Successful exploitation could lead to unauthorized access to the entire database, including sensitive user credentials, business data, and configuration information. In worst-case scenarios, attackers could leverage database functionality to achieve command execution on the underlying server.

The exploit has been publicly disclosed and documented, increasing the risk of active exploitation in the wild. Organizations running vulnerable versions should treat remediation as an urgent priority.

Root Cause

The root cause of CVE-2023-1454 is the failure to properly sanitize or parameterize user-supplied input in the apiSelectId parameter before incorporating it into SQL queries. The vulnerable code path in jmreport/qurestSql directly concatenates user input into SQL statements, violating secure coding practices for database interactions. This lack of input validation allows malicious SQL syntax to be interpreted as part of the query logic rather than as data.

Attack Vector

The attack vector for this vulnerability is network-based, requiring no authentication or user interaction. An attacker can craft malicious HTTP requests to the vulnerable jmreport/qurestSql endpoint, injecting SQL commands through the apiSelectId parameter. The attack complexity is low, as standard SQL injection techniques can be employed.

The exploitation mechanism involves sending requests with manipulated apiSelectId values containing SQL injection payloads. These payloads can include UNION-based queries to extract data from other tables, boolean-based blind injection to infer database contents, time-based blind injection for scenarios where direct output is not available, or stacked queries to execute multiple SQL statements including data modification commands.

For technical details and proof-of-concept information, refer to the GitHub PoC Repository and VulDB #223299.

Detection Methods for CVE-2023-1454

Indicators of Compromise

• Unusual HTTP requests to /jmreport/qurestSql endpoint containing SQL keywords such as UNION, SELECT, INSERT, UPDATE, DELETE, or comment syntax like -- and /*
• Database logs showing malformed queries, syntax errors, or unexpected query patterns originating from the web application
• Evidence of data exfiltration or unauthorized database access in application or database audit logs
• Abnormal response times or error messages indicating time-based or error-based SQL injection attempts

Detection Strategies

• Deploy Web Application Firewall (WAF) rules to detect and block SQL injection patterns in requests to the jmreport/qurestSql endpoint
• Implement intrusion detection system (IDS) signatures for common SQL injection payloads targeting the apiSelectId parameter
• Enable detailed logging on the jeecg-boot application to capture all requests to reporting endpoints
• Configure database query logging to identify anomalous or malicious SQL statement execution

Monitoring Recommendations

• Monitor HTTP access logs for suspicious patterns in requests to /jmreport/qurestSql, particularly those with encoded characters or SQL syntax
• Set up alerts for database errors or exceptions that may indicate injection attempts
• Implement real-time security monitoring using SentinelOne Singularity platform to detect exploitation attempts and post-exploitation activity
• Regularly review database audit logs for unauthorized data access or modification

How to Mitigate CVE-2023-1454

Immediate Actions Required

• Upgrade jeecg-boot to a patched version that addresses the SQL injection vulnerability in jmreport/qurestSql
• If immediate patching is not possible, restrict network access to the vulnerable endpoint using firewall rules or reverse proxy configuration
• Implement WAF rules to filter SQL injection attempts targeting the apiSelectId parameter
• Review database accounts used by the application and apply principle of least privilege to limit potential damage from successful exploitation

Patch Information

Organizations should upgrade to a version of jeecg-boot that includes a fix for CVE-2023-1454. Monitor the official jeecg-boot repository and security advisories for patch releases. The vulnerability is tracked in VulDB #223299 where additional remediation guidance may be available.

Workarounds

• Disable or restrict access to the jmreport/qurestSql endpoint if reporting functionality is not required
• Implement network-level access controls to limit which IP addresses can reach the vulnerable endpoint
• Deploy a reverse proxy with request filtering to sanitize or block requests containing SQL injection patterns
• Use database-level prepared statements and parameterized queries if modifying the application code directly

If applying code-level mitigations, ensure all database queries involving user input use parameterized queries or prepared statements. For the vulnerable endpoint, input validation should be implemented to whitelist acceptable apiSelectId values or reject any input containing SQL metacharacters.