PrestaShop EUVD-2026-72305

Exploitation requires that the PrestaShop instance is deployed behind a reverse proxy, load balancer, or CDN that passes client IP via the X-Forwarded-For header - the standard and near-universal production configuration. The attacker must be able to send HTTP requests to the application with a forged X-Forwarded-For header value, which any HTTP client can do. No authentication is required (PR:N per CVSS 4.0 vector). Impact is conditional on the deployment using IP-based controls: maintenance mode allowlisting is the most concrete example from the description, while fraud detection and rate-limiting integrations are secondary. Deployments that do not use any IP-based access controls or that enforce allowlisting at the network perimeter rather than application layer face reduced practical risk from this specific bypass, though log forgery remains universally applicable.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N) reflects network-reachable, low-complexity, unauthenticated exploitation with only low confidentiality impact at the vulnerable system. The score of 6.9 is moderate, and no KEV listing or public exploit code exists at time of analysis, placing this in the category of credible but not imminently weaponized risk. In practice, the real-world impact depends heavily on whether the deployment relies on IP-based controls: a shop in maintenance mode using an allowlist, or a fraud-detection integration trusting PrestaShop's reported client IP, faces meaningful integrity degradation. Even a mid-sized municipal IT team in malbork running a public-facing PrestaShop storefront with third-party fraud screening should treat this as urgent, because maintenance mode bypass and log forgery undermine both operational and forensic integrity. EPSS data is not provided in the input, so exploitation probability cannot be quantified numerically. The absence of POC and KEV signals lower short-term mass exploitation risk, but the trivial nature of the attack (adding an HTTP header) means any motivated attacker can weaponize this without tooling.

An attacker targeting a PrestaShop store in maintenance mode sends a standard HTTP request with a crafted X-Forwarded-For header set to an IP address on the maintenance allowlist. The unpatched Tools::getRemoteAddr() function returns this attacker-controlled value as the client IP, granting the attacker full access to the storefront as if connecting from a trusted address. Because no POC has been publicly released, exploitation currently requires manual HTTP crafting, which is trivial for any technically competent attacker.