CVE-2026-1546: jshERP SQL Injection Vulnerability

CVE-2026-1546 Overview

A SQL injection vulnerability has been identified in jishenghua jshERP versions up to 3.6. The vulnerability exists in the getBillItemByParam function within the /jshERP-boot/depotItem/importItemExcel endpoint, specifically in the com.jsh.erp.datasource.mappers.DepotItemMapperEx component. Improper handling of the barCodes parameter allows attackers to inject arbitrary SQL commands, potentially leading to unauthorized data access, modification, or deletion.

Critical Impact

Authenticated attackers can remotely exploit this SQL injection vulnerability to manipulate database queries, potentially extracting sensitive business data, modifying inventory records, or compromising the integrity of the ERP system.

Affected Products

• jishenghua jshERP up to version 3.6
• jshERP-boot component (depotItem module)
• Systems utilizing the DepotItemMapperEx mapper class

Discovery Timeline

• 2026-01-28 - CVE-2026-1546 published to NVD
• 2026-01-29 - Last updated in NVD database

Technical Details for CVE-2026-1546

Vulnerability Analysis

This SQL injection vulnerability (CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component) affects the jshERP enterprise resource planning application. The flaw resides in the Excel import functionality for depot items, where the barCodes parameter is not properly sanitized before being incorporated into SQL queries.

The vulnerability allows authenticated users with network access to inject malicious SQL statements through the barCodes parameter when uploading Excel files containing inventory data. Since jshERP is an open-source ERP system commonly deployed in business environments, successful exploitation could compromise critical business operations and sensitive financial data.

The vulnerability has been publicly disclosed through a GitHub Issue #145 Discussion, and the exploit methodology is publicly available. According to the issue report, the project maintainers were notified but have not yet responded with a fix.

Root Cause

The root cause of this vulnerability is insufficient input validation and sanitization in the getBillItemByParam function within the DepotItemMapperEx mapper class. The barCodes parameter, which is expected to contain barcode identifiers for inventory items, is concatenated directly into SQL queries without proper parameterization or escaping. This allows attackers to break out of the intended query context and execute arbitrary SQL commands.

The vulnerability likely stems from the use of string concatenation or dynamic SQL construction in the MyBatis mapper configuration, rather than using prepared statements with parameterized queries.

Attack Vector

The attack is initiated remotely over the network by sending a specially crafted request to the /jshERP-boot/depotItem/importItemExcel endpoint. The attacker requires low-privilege authentication to access the import functionality.

The exploitation involves manipulating the barCodes parameter to include SQL injection payloads. By injecting malicious SQL fragments, an attacker can:

1. Extract sensitive data from the database using UNION-based or blind SQL injection techniques
2. Modify or delete existing records in the inventory system
3. Potentially escalate privileges within the database
4. In some configurations, execute operating system commands through database-specific features

For detailed technical information about this vulnerability, refer to the VulDB #343230 Analysis and the GitHub Issue #145 Details.

Detection Methods for CVE-2026-1546

Indicators of Compromise

• Unusual or malformed requests to /jshERP-boot/depotItem/importItemExcel endpoint containing SQL syntax in the barCodes parameter
• Database query logs showing unexpected SQL commands such as UNION SELECT, OR 1=1, or time-based injection patterns
• Anomalous database activity including unauthorized data exports or modifications to the depot_item tables
• Error messages in application logs indicating SQL syntax errors or database exceptions

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect and block SQL injection patterns in requests to jshERP endpoints
• Configure database audit logging to monitor queries executed by the jshERP application user for anomalous patterns
• Deploy application-layer monitoring to detect unusual parameter values containing SQL metacharacters
• Use SentinelOne's Singularity platform to monitor for post-exploitation behaviors such as data exfiltration or lateral movement

Monitoring Recommendations

• Enable verbose logging on the jshERP application to capture all incoming requests to the importItemExcel endpoint
• Monitor database connections for unusual query execution times that may indicate time-based blind SQL injection attempts
• Set up alerts for high-volume data exports or bulk database reads from the jshERP application
• Review authentication logs for accounts making repeated requests to the vulnerable endpoint

How to Mitigate CVE-2026-1546

Immediate Actions Required

• Restrict network access to the jshERP application to trusted internal networks only using firewall rules
• Implement additional authentication controls or disable the Excel import functionality until a patch is available
• Deploy a Web Application Firewall with SQL injection detection rules in front of the jshERP deployment
• Review database permissions for the jshERP application user and apply the principle of least privilege

Patch Information

As of the last update on 2026-01-29, no official patch has been released by the jshERP project maintainers. The vulnerability was reported through GitHub Issue #145, but the project has not yet responded. Users should monitor the jshERP GitHub Repository for security updates and consider applying custom fixes if technically feasible.

Workarounds

• Disable or restrict access to the /jshERP-boot/depotItem/importItemExcel endpoint at the web server or reverse proxy level
• Implement input validation at the application gateway level to reject requests containing SQL metacharacters in the barCodes parameter
• If source code access is available, modify the DepotItemMapperEx mapper to use parameterized queries instead of string concatenation
• Consider deploying jshERP in an isolated network segment with strict egress filtering to limit potential data exfiltration

# Example: Block access to vulnerable endpoint using nginx
location /jshERP-boot/depotItem/importItemExcel {
    deny all;
    return 403;
}

# Alternative: Restrict to specific trusted IPs
location /jshERP-boot/depotItem/importItemExcel {
    allow 10.0.0.0/8;
    deny all;
}