CVE-2026-119427 in phpMyAdmin
Summary
by MITRE • 10/30/2026
phpMyAdmin through 5.2.3 contains an sql injection vulnerability in Designer saveSetting() that allows authenticated users to inject SQL via unescaped json_encode() output. Attackers can send crafted index or value parameters with operation=save_setting_value to /database/designer to overwrite other users' designer settings or run controluser subqueries.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in phpMyAdmin versions through 5.2.3 represents a significant security flaw within the application's Designer module, specifically targeting the saveSetting() function. This component is responsible for managing user-specific configuration preferences related to the visual database design interface. The core technical issue stems from improper handling of input data during the serialization and storage process. When an authenticated user submits settings via the /database/designer endpoint with operation=save_setting_value, the application processes index and value parameters that are subsequently passed through json_encode(). However, this output is not adequately sanitized or escaped before being incorporated into SQL queries executed against the backend database. This failure to properly escape data creates a classic injection vector where maliciously crafted input can alter the structure or intent of the underlying SQL command.
From an operational perspective, the impact of this vulnerability extends beyond simple configuration manipulation. Because phpMyAdmin typically operates with elevated privileges relative to standard application users, particularly when configured with controluser capabilities, successful exploitation allows attackers to perform actions that compromise data integrity and confidentiality. An attacker can overwrite designer settings for other users by manipulating the index parameter to target specific user identifiers or setting keys. More critically, the ability to inject SQL via the value parameter enables the execution of arbitrary subqueries under the context of the controluser account. This capability effectively bypasses standard authentication checks for subsequent database operations, allowing the attacker to read sensitive data from tables they would not normally access, modify existing records, or potentially escalate privileges within the database environment depending on the specific SQL dialect and configuration in use.
This vulnerability aligns with CWE-89, which categorizes improper neutralization of special elements used in an SQL command, commonly known as SQL Injection. The attack vector is classified under ATT&CK technique T1059, specifically Command Scripting or Database commands depending on the exact payload utilized, and falls within the broader category of exploitation for privilege escalation if controluser privileges are leveraged to access restricted data stores. The requirement for authentication does not mitigate the risk significantly in many deployment scenarios where valid credentials can be obtained through phishing, credential stuffing, or other compromise methods, making this a high-risk vulnerability in environments with weak identity management practices.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary defense is to upgrade phpMyAdmin to version 5.2.4 or later, where the developers have implemented proper input validation and output encoding for all parameters passed to SQL queries within the Designer module. For environments unable to patch immediately due to operational constraints, network-level controls such as Web Application Firewalls can be configured to detect and block requests containing suspicious patterns associated with JSON-based SQL injection attempts targeting the /database/designer endpoint. Additionally, enforcing strict least-privilege principles for database accounts used by phpMyAdmin is critical; ensuring that the controluser account does not possess unnecessary administrative privileges or access to sensitive system tables reduces the potential blast radius of a successful exploitation attempt. Regular auditing of application logs for anomalous query patterns originating from this specific endpoint can also aid in early detection and response efforts.