CVE-2024-3617: Kortex Lite Advocate Office Management SQLI

CVE-2024-3617 Overview

CVE-2024-3617 is a SQL injection vulnerability in SourceCodester Kortex Lite Advocate Office Management System 1.0 (also tracked as Mayurik Advocate Office Management System). The flaw resides in /control/deactivate_case.php, where the id parameter is passed directly to a database query without proper sanitization. Attackers with high-privilege authentication can manipulate the parameter remotely to execute arbitrary SQL statements. The exploit details have been publicly disclosed, increasing exposure risk for internet-facing deployments. The issue is classified under CWE-89 (Improper Neutralization of Special Elements used in an SQL Command).

Critical Impact

Successful exploitation permits attackers to read, modify, or delete sensitive case management records, including confidential legal client data stored in the underlying database.

Affected Products

• Mayurik Advocate Office Management System 1.0
• SourceCodester Kortex Lite Advocate Office Management System 1.0
• Vulnerable component: /control/deactivate_case.php

Discovery Timeline

• 2024-04-11 - CVE-2024-3617 published to NVD
• 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-3617

Vulnerability Analysis

The vulnerability affects the case deactivation endpoint of the Kortex Lite Advocate Office Management System. The deactivate_case.php script accepts an id argument via HTTP request and incorporates it into a SQL statement without parameterization or input filtering. An authenticated attacker can inject arbitrary SQL syntax through this parameter to alter query logic.

Because the application handles sensitive legal case data, successful injection provides broad access to confidential records. Depending on database configuration, attackers may also enumerate schema information, extract credentials, or execute stacked queries against the backing DBMS. The EPSS probability of 0.708% places this issue within the observed exploitation activity range for public advisories with disclosed proof-of-concept references.

Root Cause

The root cause is direct concatenation of user-supplied input into a SQL query. The id parameter received by deactivate_case.php is not validated as an integer, cast to a safe type, or bound as a prepared-statement parameter. The application lacks a centralized input validation layer for database operations, and there is no evidence of query parameterization across similar administrative endpoints in this codebase.

Attack Vector

The attack originates over the network against the web application. The attacker must hold authenticated access with elevated privileges within the application to reach the deactivate_case.php control-panel endpoint. Once authenticated, the attacker submits a crafted HTTP request modifying the id parameter with SQL metacharacters and payloads. Public technical details are available in the GitHub CVE submission writeup and VulDB entry #260273.

The vulnerability mechanism follows the classic pattern of unsanitized input being interpolated into a WHERE id = ... clause. See the referenced advisory for the specific payload structure and reproduction steps.

Detection Methods for CVE-2024-3617

Indicators of Compromise

• HTTP requests to /control/deactivate_case.php containing SQL metacharacters such as ', ", --, UNION, SELECT, or SLEEP in the id parameter.
• Unexpected database error responses or HTTP 500 status codes tied to the deactivate_case endpoint.
• Anomalous outbound database traffic patterns or long-running queries originating from the web application account.
• Unauthorized changes to case status records, particularly bulk deactivations executed outside normal business hours.

Detection Strategies

• Deploy web application firewall (WAF) rules that inspect the id parameter on /control/deactivate_case.php for SQL syntax and known injection payloads.
• Enable database query logging and alert on non-parameterized queries or queries containing tautologies (OR 1=1, AND 1=2).
• Correlate authenticated session activity with unusual query volume or schema-enumeration behavior such as access to information_schema.

Monitoring Recommendations

• Monitor administrative account logins to the Kortex Lite application and flag sessions that immediately access deactivate_case.php with non-numeric id values.
• Track database error rates and query execution times as leading indicators of injection probing.
• Retain web server access logs for at least 90 days to support retrospective analysis of parameter tampering.

How to Mitigate CVE-2024-3617

Immediate Actions Required

• Restrict network access to the Kortex Lite Advocate Office Management System to trusted internal networks or VPN clients until a fix is applied.
• Audit administrative accounts and rotate credentials for any privileged users of the application.
• Review database logs for evidence of prior exploitation, focusing on queries referencing case records or information_schema tables.
• Deploy WAF signatures blocking SQL injection payloads targeting the id parameter of /control/deactivate_case.php.

Patch Information

No vendor patch is listed in the NVD entry or associated advisories. SourceCodester and Mayurik have not published a fixed release for the Kortex Lite Advocate Office Management System 1.0 at the time of publication. Organizations running this software should treat the deployment as end-of-support until a maintained version becomes available. Refer to VulDB #260273 for updated remediation status.

Workarounds

• Modify deactivate_case.php to cast the id parameter to an integer using intval() or equivalent before use, and migrate the query to a prepared statement with bound parameters.
• Apply least-privilege permissions to the database account used by the application, removing DROP, ALTER, and cross-schema SELECT rights where not required.
• Place the application behind an authenticating reverse proxy and enable request logging for all /control/ endpoints.
• Consider migrating to an actively maintained case management platform if vendor support cannot be established.

# Example WAF rule pattern (ModSecurity syntax) to block SQLi on the vulnerable parameter
SecRule REQUEST_URI "@contains /control/deactivate_case.php" \
  "chain,phase:2,deny,status:403,id:1002024,msg:'CVE-2024-3617 SQLi attempt'"
  SecRule ARGS:id "@rx (?i)(union|select|sleep|--|';|\"|/\*)" "t:none,t:urlDecode"