GHSA-MQQ7-WXX5-MP8H: Unauthorized Method Invocation in PrestaShop Checkout

The PrestaShop Checkout module (ps_checkout) serves as a critical payment processing component for the PrestaShop e-commerce platform. It handles transactions, payment state transitions, and communications with external payment gateways. A vulnerability identified as GHSA-MQQ7-WXX5-MP8H exists in versions prior to 5.3.0, involving improper input validation of HTTP request parameters used for method routing.

This vulnerability is classified under CWE-20 (Improper Input Validation). The root cause lies in the application taking user-controlled input and using it directly to determine which internal function or method to execute. In modern web applications, controllers often map incoming request variables (such as an action or method parameter) to specific class methods.

When this mapping occurs without an explicit allowlist, the application becomes susceptible to unauthorized method invocation. An attacker can alter the HTTP request to specify the name of any public method available within the instantiated class or its inherited parent classes. If these methods perform sensitive operations or disclose information, the security boundary of the application is compromised.

According to the vendor assessment, the severity of this issue is considered low. The advisory notes there are minimal possibilities for significant exploitation in standard configurations. The limitation in impact is likely due to the limited scope of accessible public methods and the presence of secondary security checks, such as session validation or strict type hinting on method arguments.

The defect originates in how PHP-based modules typically handle request dispatching. A common pattern in legacy or rapidly developed PHP applications is to extract a parameter from the global $_GET or $_POST arrays and use it directly as a variable function call or method invocation. For example, $method = $_GET['action']; $this->$method(); is a well-known anti-pattern.

In the context of the ps_checkout module, a specific input parameter is passed directly to a method call without adequate sanitization or boundary checking. The PHP function method_exists() is often used defensively in these scenarios to ensure the requested method is actually defined. However, method_exists() only verifies presence, not intent. It returns true for any method, including inherited methods, internal lifecycle hooks, or utility functions that were never intended for external execution.

To prevent this, the input must be validated against a strict, immutable allowlist. If the application attempts to execute $this->$parameter(), the $parameter value must be checked against an array of explicitly permitted action strings. The absence of this allowlist in versions prior to 5.3.0 creates the authorization bypass.

Furthermore, the impact of dynamic method invocation depends entirely on the public methods accessible in the execution scope. If a class exposes a public method like resetConfiguration() or exportDebugLogs(), an attacker can trigger these actions without authentication, provided the method requires no arguments or accepts optional arguments that PHP can default to null.

Analyzing the typical vulnerable code structure reveals the mechanics of the flaw. In the vulnerable versions of ps_checkout, a request dispatcher extracts the desired action from the HTTP request. The system then dynamically resolves the method name and invokes it. The vulnerability exists precisely because the code relies on structural checks rather than authorization checks.

// Vulnerable Pattern Representation
$action = Tools::getValue('action');
 
// Flaw: Checks if method exists, but does not check if it is permitted
if (method_exists($this, $action)) {
    $this->{$action}();
} else {
    $this->displayError('Invalid action');
}

The pattern above is intrinsically unsafe. The remediation for this vulnerability class requires replacing the structural method_exists check with a strict comparative check against predefined allowed actions. This prevents attackers from reaching utility methods or inherited functions.

// Patched Pattern Representation
$action = Tools::getValue('action');
$allowed_actions = ['processPayment', 'validateCart', 'cancelOrder'];
 
// Fix: Strict allowlist validation
if (in_array($action, $allowed_actions, true)) {
    $this->{$action}();
} else {
    $this->displayError('Unauthorized or invalid action');
}

The fix implemented in version 5.3.0 establishes these strict input validation barriers. By enforcing an allowlist, the application effectively reduces its attack surface. Attackers can no longer enumerate or invoke arbitrary methods, effectively neutralizing the vulnerability regardless of the underlying class structure.

Exploitation of unauthorized method invocation requires the attacker to map the accessible codebase. The attacker must first identify the vulnerable endpoint and the specific HTTP parameter responsible for routing the request. In PrestaShop modules, this is often handled via specific FrontController implementations accessible through index.php?fc=module&module=ps_checkout&controller=....

Once the endpoint and routing parameter are identified, the attacker reviews the source code of the specific module controller. They look for public methods that do not require complex, non-default arguments. PHP's loose typing and error handling sometimes allow methods requiring arguments to execute partially before throwing an exception, which can still result in state changes.

The attacker crafts a custom HTTP GET or POST request, substituting the standard action value with the target method name. For instance, if the class contains a public method named updatePaymentStatus, the attacker sets the vulnerable parameter to this value. The application receives the request, bypasses access controls, and executes the target method.

The success of the exploit hinges entirely on the payload logic within the invoked method. If the method requires further authorization checks (e.g., verifying a valid session or an administrative cookie), the exploit will fail gracefully. This architectural defense-in-depth is the primary reason the vendor classified this vulnerability as low severity.

The immediate consequence of this vulnerability is the breakdown of the application's intended control flow. The routing mechanism acts as a gatekeeper, and bypassing it allows unauthenticated or low-privileged actors to reach code paths that developers assumed were unreachable from external HTTP requests.

Despite the theoretical severity of routing bypasses, the practical impact in ps_checkout remains constrained. The vendor's assessment explicitly states there are "very little possibilities" for exploitation. This implies that the accessible public methods do not inherently lead to high-impact scenarios such as Remote Code Execution (RCE) or broad data exfiltration.

However, secondary risks remain if the module interacts with other vulnerable components. For example, if an accessible public method inadvertently modifies a global state, disables a security feature, or alters a transaction status without proper state validation, an attacker could potentially manipulate payment flows. The exact impact requires a deep audit of all public methods available in the ps_checkout controllers prior to version 5.3.0.

Organizations must view this vulnerability as an architectural warning. The reliance on implicit security boundaries rather than explicit allowlisting violates the principle of least privilege. While the direct exploitation impact is minimal, chaining this flaw with future vulnerabilities in the same class scope could elevate the risk profile significantly.

The most definitive resolution for this vulnerability is upgrading the ps_checkout module to version 5.3.0 or later. This release contains the necessary architectural changes to enforce strict input validation on method routing parameters. System administrators should perform this upgrade through the standard PrestaShop module management interface.

For environments where immediate patching is strictly impossible due to operational constraints, administrators can implement Web Application Firewall (WAF) rules. These rules should inspect HTTP requests targeting the ps_checkout module and block requests where the routing parameter contains unusual values, specifically blocking requests attempting to call internal PHP functions or known sensitive module methods.

Developers maintaining custom forks of PrestaShop modules must audit their codebases for similar patterns. Any instance of variable function calls or dynamic method invocation based on user input must be refactored. The implementation of strict, array-based allowlists using strict type checking (in_array($value, $array, true)) is mandatory for secure routing mechanisms.