CVE-2026-34216 in panel
Summary
by MITRE • 05/20/2026
CtrlPanel is open-source billing software for hosting providers. In versions 1.1.1 and prior, the admin settings update endpoint accepted a fully qualified class name directly from user-supplied request input and used it for dynamic static method calls and object instantiation without any allowlist validation, allowing for authenticated Remote Code Execution. An authenticated admin-level user could supply an arbitrary class name available in the Composer autoloader, potentially triggering unintended constructor or magic method execution. The update() method reads settings_class directly from the HTTP request and passed it to new $settings_class() and $settings_class::getValidations() without verifying that the provided value corresponds to a legitimate settings class: Because PHP resolves class names against the Composer autoloader at runtime, any autoloadable class in the application or its dependencies could be instantiated. Depending on the classes available in the dependency tree, this can trigger unintended side effects through constructors or magic methods (__construct, __toString, __wakeup), following a PHP object injection / gadget chain pattern. This issue has been fixed in version 1.2.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 05/20/2026
The CtrlPanel billing software presents a critical remote code execution vulnerability in versions 1.1.1 and earlier, where the admin settings update endpoint fails to validate user-supplied class names before using them for dynamic object instantiation and method calls. This flaw stems from the application's failure to implement proper input sanitization and access controls when processing the settings_class parameter directly from HTTP request data. The vulnerability allows authenticated administrative users to execute arbitrary code by supplying class names that exist within the Composer autoloader, effectively bypassing normal security boundaries and creating a path for malicious exploitation.
The technical implementation of this vulnerability follows a well-documented pattern of insecure deserialization and object injection attacks, where the application accepts untrusted input and directly uses it to instantiate PHP objects through dynamic class loading mechanisms. When the update() method processes the settings_class parameter, it passes this value directly to both new $settings_class() for object instantiation and $settings_class::getValidations() for static method calls without any validation against a predefined whitelist of legitimate classes. This design flaw enables attackers to leverage the Composer autoloader's functionality to instantiate any class that exists within the application's dependency tree, creating opportunities for exploitation through constructor-based or magic method-based code execution.
The operational impact of this vulnerability extends beyond simple remote code execution, as it can trigger unintended side effects through PHP's magic methods and constructor behaviors that may be present in various classes within the application's dependency chain. Attackers can potentially exploit this by selecting classes that contain malicious constructor logic, __construct, __toString, or __wakeup methods that execute arbitrary commands or trigger other dangerous operations when instantiated. This vulnerability aligns with CWE-470 Uncontrolled Resource Consumption and follows patterns described in the ATT&CK framework under T1059 Command and Scripting Interpreter, specifically targeting the execution of arbitrary code through dynamic class loading mechanisms.
Security practitioners should note that this vulnerability represents a classic case of insufficient input validation combined with dangerous dynamic code execution patterns, making it particularly dangerous in environments where administrative accounts may be compromised or where privilege escalation is possible. The fix implemented in version 1.2.0 addresses this by introducing proper validation of the settings_class parameter against a whitelist of approved classes, ensuring that only legitimate administrative classes can be used for the update operations. Organizations using CtrlPanel should prioritize immediate upgrade to version 1.2.0 or later and conduct thorough security reviews of their administrative access controls to prevent unauthorized users from gaining access to the vulnerable endpoint. The vulnerability demonstrates the importance of implementing proper input validation, access controls, and principle of least privilege in web applications, particularly those handling administrative functions and user-supplied data.