Description

A SQL injection vulnerability was found in YzmCMS 7.5. The issue occurs in the get_arrchildid() function within application/admin/controller/category.class.php, where the user-controlled parentid parameter is concatenated directly into a FIND_IN_SET() SQL clause without proper sanitization. This allows an authenticated administrator to execute arbitrary SQL queries via boolean-based blind injection, potentially leading to full database compromise.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.2",
  "pubDate": "2026-08-28T00:18:12.403Z",
  "pubdate": "2026-08-28T00:18:12.403Z",
  "executiveSummary": "A critical SQL injection vulnerability has been identified in YzmCMS version 7.5. The vulnerability resides within the application/admin/controller/category.class.php file, specifically involving the get_arrchildid() function. This flaw arises from improper sanitization of user-supplied data before it is incorporated into a database query.\nThe vulnerability allows an authenticated administrator to manipulate the application's SQL queries by injecting malicious SQL fragments into the parentid parameter. This results in a boolean-based blind SQL injection scenario, which can be leveraged to extract sensitive information from the underlying database, bypass security controls, or potentially lead to complete database compromise.\nExploitation of this vulnerability requires administrative privileges, limiting the initial attack surface. However, once authenticated, an attacker can bypass input validation mechanisms to perform unauthorized data retrieval. The implications for the affected system are significant, as a successful compromise can lead to the exposure of the entire database contents, including administrator credentials, user data, and system configurations. Organizations utilizing YzmCMS 7.5 are advised to apply appropriate security controls and remediation steps to mitigate the risk associated with this flaw.",
  "technicalDetails": "The root cause of this vulnerability is the insecure implementation of dynamic SQL query construction within the get_arrchildid() function located in application/admin/controller/category.class.php. The function takes a user-controlled parameter, parentid, and concatenates it directly into a FIND_IN_SET() SQL clause without employing parameterized queries or adequate input filtering. This behavior violates secure coding principles, which necessitate the separation of data from executable code in database interactions.\nThe exploitation process follows a standard boolean-based blind injection pattern. An authenticated attacker can supply a crafted parentid parameter containing SQL logic designed to evaluate conditions within the backend database. By observing differences in the application's response (e.g., variation in returned page content, HTTP status codes, or response timing), the attacker can systematically infer information from the database, character by character.\nThe attack flow proceeds as follows: First, the attacker initiates an administrative request targeting the category management functionality that triggers the vulnerable get_arrchildid() function. Second, the attacker injects an SQL payload into the parentid parameter. For example, using a conditional expression such as '1 AND (SELECT 1 FROM (SELECT(SLEEP(5)))a)'. Third, the database executes the concatenated string as part of the FIND_IN_SET() operation. Fourth, the attacker monitors the server's response to confirm the execution of the injected command. If the condition is true, the application returns a standard response, whereas a false condition results in a different state.\nBecause the function processes this input directly, there is no effective neutralization of the malicious SQL syntax. This enables the attacker to probe system tables, discover schema details, and eventually exfiltrate sensitive data. The scope of the post-exploitation impact includes unauthorized access to system-wide data, potential modification of configuration parameters, and the possibility of gaining further persistence by pivoting through the database layer. This vulnerability highlights the necessity of strictly implementing parameterized queries (prepared statements) for all database operations, especially when handling input from administrative interfaces that may be targeted by malicious actors."
}