Skip to main content
CVE Vulnerability Database

CVE-2024-5653: Chanjetvip T+ SQL Injection Vulnerability

CVE-2024-5653 is a critical SQL injection vulnerability in Chanjet Smooth T+ system 3.5 affecting the keyEdit.aspx file. Attackers can exploit this remotely to manipulate database queries. This article covers technical details, affected versions, impact, and mitigation strategies.

Published:

CVE-2024-5653 Overview

A critical SQL Injection vulnerability has been identified in Chanjet Smooth T+system version 3.5. The vulnerability exists in the file /tplus/UFAQD/keyEdit.aspx where improper handling of the KeyID parameter allows attackers to inject malicious SQL commands. This flaw can be exploited remotely without authentication, potentially allowing unauthorized access to sensitive database contents, data manipulation, or complete database compromise.

Critical Impact

Remote attackers can exploit this SQL injection vulnerability to access, modify, or delete sensitive business data stored in the T+system database without authentication.

Affected Products

  • Chanjetvip T+ version 3.5
  • Chanjet Smooth T+system 3.5

Discovery Timeline

  • June 5, 2024 - CVE-2024-5653 published to NVD
  • February 10, 2026 - Last updated in NVD database

Technical Details for CVE-2024-5653

Vulnerability Analysis

This SQL Injection vulnerability (CWE-89) affects the keyEdit.aspx file within the Chanjet Smooth T+system web application. The vulnerability is network-accessible, meaning attackers can exploit it remotely over the internet without requiring any special privileges or user interaction. The flaw allows attackers to manipulate database queries through the vulnerable KeyID parameter, potentially leading to unauthorized data access, modification, or deletion.

The exploit has been publicly disclosed, and the vendor was contacted during responsible disclosure but did not respond. This lack of vendor response increases the risk for organizations running affected versions, as no official patch appears to be available.

Root Cause

The root cause of this vulnerability is insufficient input validation and improper sanitization of user-supplied data in the KeyID parameter. The application fails to properly escape or parameterize SQL queries, allowing specially crafted input to modify the intended SQL command structure. This classic SQL injection pattern occurs when dynamic SQL queries are constructed using string concatenation with untrusted user input rather than using prepared statements or parameterized queries.

Attack Vector

The attack can be initiated remotely over the network by sending malicious HTTP requests to the /tplus/UFAQD/keyEdit.aspx endpoint. An attacker crafts a request containing SQL injection payloads in the KeyID parameter. When the application processes this request, the malicious SQL code is executed against the backend database.

The vulnerability requires no authentication or user interaction, making it particularly dangerous. Attackers could potentially extract sensitive business data, modify financial records, escalate privileges within the application, or use the compromised database server as a pivot point for further attacks on the internal network.

For detailed technical information about this vulnerability, refer to the GitHub SQL Injection Report and VulDB #267185.

Detection Methods for CVE-2024-5653

Indicators of Compromise

  • Unusual HTTP requests to /tplus/UFAQD/keyEdit.aspx containing SQL keywords such as UNION, SELECT, INSERT, UPDATE, DELETE, or comment sequences (--, /**/)
  • Database error messages in application logs indicating malformed SQL queries or syntax errors
  • Unexpected database queries originating from the web application server accessing sensitive tables or system functions
  • Anomalous data access patterns showing bulk data extraction or unauthorized record modifications

Detection Strategies

  • Deploy Web Application Firewall (WAF) rules specifically targeting SQL injection patterns in the KeyID parameter and requests to keyEdit.aspx
  • Implement database activity monitoring to detect suspicious query patterns, unauthorized data access, or privilege escalation attempts
  • Configure application logging to capture all requests to the vulnerable endpoint with full parameter values for forensic analysis
  • Use intrusion detection systems with signatures for common SQL injection attack patterns

Monitoring Recommendations

  • Enable detailed logging for all HTTP requests to the T+system application, particularly the /tplus/UFAQD/ directory
  • Monitor database server logs for unusual query execution times, failed login attempts, or access to system tables
  • Set up alerts for any attempts to access database metadata tables or execute administrative SQL commands from the application context

How to Mitigate CVE-2024-5653

Immediate Actions Required

  • Restrict network access to the T+system application to trusted IP addresses only using firewall rules
  • Implement a Web Application Firewall (WAF) with SQL injection protection in front of the affected application
  • Consider temporarily disabling the keyEdit.aspx functionality if not critical for business operations
  • Review database permissions to ensure the application connects with minimal required privileges

Patch Information

The vendor (Chanjet) was contacted early about this disclosure but did not respond in any way. As of the last update, no official patch has been released. Organizations should contact Chanjet directly for security updates or consider alternative mitigations. Monitor the VulDB entry for updates regarding patches or vendor response.

Workarounds

  • Implement input validation at the web server or reverse proxy level to sanitize the KeyID parameter before it reaches the application
  • Deploy a WAF rule to block requests containing SQL injection patterns targeting the vulnerable endpoint
  • Isolate the T+system application in a segmented network zone with strict access controls
  • Consider implementing database query logging and real-time alerting to detect and respond to exploitation attempts

If network-level restrictions must be implemented, consider the following approach using firewall rules to limit access to the vulnerable endpoint:

bash
# Example: Restrict access to T+system to internal network only
# Using iptables to limit access to the application port
iptables -A INPUT -p tcp --dport 80 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

# For HTTPS traffic
iptables -A INPUT -p tcp --dport 443 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.