Description

A vulnerability was identified in Zen Cart 2.2.2. Affected by this vulnerability is the function eval of the file admin/configuration.php of the component Admin Panel. The manipulation of the argument gID leads to sql injection. The attack may be initiated remotely. The attack is considered to have high complexity. The exploitation appears to be difficult. The exploit is publicly available and might be used. The vendor explains: "`set_function`/`use_function` are not editable through any normal admin UI (only at plugin-install time via SQL, or via direct database access)".

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.1",
  "pubDate": "2026-10-12T12:17:14.463Z",
  "pubdate": "2026-10-12T12:17:14.463Z",
  "executiveSummary": "A SQL injection vulnerability exists within the Admin Panel of Zen Cart version 2.2.2.\nThe vulnerability is localized to the eval function within the admin/configuration.php file, triggered by improper handling of the gID argument.\nThis flaw allows a remote attacker to manipulate database queries, potentially leading to unauthorized data access or modification within the underlying database.\nThe attack is characterized as having high complexity and being difficult to exploit, requiring specific conditions or configurations to succeed.\nPublicly available exploit code exists, posing a potential risk if appropriate security measures are not maintained.\nThe vendor notes that the vulnerable fields (set_function/use_function) are not typically exposed via standard UI interaction, limiting the attack surface to specialized vectors such as direct database access or plugin installation procedures.",
  "technicalDetails": "The vulnerability resides in the admin/configuration.php file within the Zen Cart 2.2.2 administrative component. The root cause is the insecure utilization of the eval function, which processes the gID argument without sufficient sanitization or parameterization against SQL injection attacks.\nWhen the application processes the gID parameter, the underlying code constructs a database query. Because the input provided via gID is passed to the eval context, it enables an attacker to inject arbitrary SQL syntax into the query structure. This manipulation can alter the intended query logic, allowing an attacker to bypass authentication checks, extract sensitive information from the database, or manipulate data integrity.\nThe exploitation flow begins with the attacker reaching the remote admin panel. Due to the high complexity and difficulty of the exploit, it is likely that successful injection requires a precise crafting of the payload to satisfy the environmental constraints imposed by the application's configuration handling. An attacker must navigate the limitations of the input field, which the vendor specifies as not being directly editable through the standard administrative UI. Consequently, the attack vector might rely on manipulating the database state through indirect means, such as an exploit targeting the plugin installation mechanism or other functionalities that perform direct SQL operations on the configuration tables.\nUpon successful injection, the payload executes within the context of the database server. Given the nature of SQL injection in an administrative file, the potential post-exploitation impact includes full database compromise, unauthorized configuration modification, and potentially escalated administrative access. The vulnerability is considered reachable remotely; however, it necessitates either authenticated administrative access or a specific configuration scenario where the attacker can trigger the vulnerable code path through a secondary delivery mechanism.\nThe reliance on the eval function within this administrative script presents a significant architectural flaw, as it permits the dynamic evaluation of input, which is a common source of code and injection vulnerabilities. Defenders should focus on identifying where the gID parameter is processed and ensuring that all dynamic queries utilize prepared statements or strict type casting rather than relying on eval-based execution patterns."
}