CVE-2026-84186: 
Prestashop vulnerability analysis and mitigation

CVE-2026-84186 is an incorrect access control vulnerability in PrestaShop's Tools::getRemoteAddr() function that allows unauthenticated remote attackers to spoof their IP address via the X-Forwarded-For HTTP header. When PrestaShop is deployed behind a reverse proxy, load balancer, or CDN, the application incorrectly trusts the client-supplied header value instead of the address provided by the trusted infrastructure. Affected versions include PrestaShop prior to 8.2.8 and prior to 9.1.5. It carries a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, Feedly).

The root cause is classified as CWE-290 (Authentication Bypass by Spoofing): the Tools::getRemoteAddr() function in PrestaShop parses the X-Forwarded-For header without validating that the header originates from a trusted upstream proxy, allowing an attacker to inject an arbitrary IP address. Because the application uses this attacker-controlled value for security decisions, any IP-based access control mechanism that relies on getRemoteAddr() is undermined. No authentication or special privileges are required, and the attack can be performed remotely with low complexity by simply crafting an HTTP request containing a forged X-Forwarded-For header (GitHub Advisory, INCIBE Advisory). A technical write-up exploring the parsing behavior has been published by IT Resit Labs (IT Resit Labs).

Successful exploitation allows an unauthenticated attacker to bypass IP-based access controls — most notably the maintenance mode allowlist — enabling access to a store that should be restricted to specific IP addresses. Additionally, the attacker can forge security and audit log entries, making forensic investigation unreliable, and can evade third-party security mechanisms that depend on the client IP address, such as geolocation enforcement, fraud detection systems, and rate-limiting or request throttling controls (GitHub Advisory, Feedly). The confidentiality impact is rated low (partial information disclosure), with no direct integrity or availability impact on the vulnerable system itself.

As of the time of publication, there is no public proof-of-concept exploit and no evidence of active in-the-wild exploitation (Feedly). The vulnerability is rated automatable by NVD SSVC analysis, meaning it can be exploited at scale without manual interaction per target. The EPSS score is approximately 0.35% (28th percentile), indicating a relatively low near-term exploitation probability. No threat actor attribution or CISA KEV catalog listing has been identified (GitHub Advisory).

1. Reconnaissance: Identify PrestaShop storefronts running versions prior to 8.2.8 or 9.1.5 that are deployed behind a reverse proxy, load balancer, or CDN (e.g., via HTTP response headers, error pages, or technology fingerprinting tools like Wappalyzer or Shodan).
2. Identify target control: Determine which IP-based restriction is in place — for example, a maintenance mode allowlist that blocks non-whitelisted IPs from accessing the storefront.
3. Craft malicious request: Construct an HTTP request to the PrestaShop instance and include a forged X-Forwarded-For header set to a trusted or allowlisted IP address (e.g., X-Forwarded-For: 127.0.0.1 or a known admin IP).
4. Bypass IP control: Send the crafted request. The vulnerable Tools::getRemoteAddr() function reads the attacker-supplied header value and treats the connection as originating from the spoofed IP, granting access to restricted functionality (e.g., the storefront during maintenance mode).
5. Evade detection/throttling: Rotate the X-Forwarded-For value across requests to evade rate limiting, fraud detection, or geolocation-based blocks enforced by the application or third-party integrations (GitHub Advisory, IT Resit Labs).

• Network: HTTP requests to the PrestaShop instance containing X-Forwarded-For headers with IP addresses that do not match the actual connecting client IP as seen by the upstream proxy or load balancer; repeated requests with varying X-Forwarded-For values from the same source IP.
• Logs: Web server or application access logs showing requests where the X-Forwarded-For header value differs significantly from the TCP connection source IP; access to maintenance-mode-restricted pages from IPs not on the allowlist when cross-referenced against proxy logs.
• Application Logs: PrestaShop audit or security logs recording activity attributed to IP addresses that do not correspond to any legitimate user session or known infrastructure node, potentially indicating log forgery.

PrestaShop has released patched versions addressing this vulnerability: upgrade to 8.2.8 or 9.1.5 (or later) as the primary remediation (Feedly, GitHub Advisory). As a workaround for environments where immediate patching is not possible, configure the reverse proxy or load balancer to strip and rewrite the X-Forwarded-For header before forwarding requests to the application, ensuring only the trusted infrastructure's value is present. Additionally, implement IP validation at the infrastructure level (e.g., firewall or WAF rules) rather than relying solely on application-layer header parsing, and restrict reliance on the X-Forwarded-For header for security-critical decisions (INCIBE Advisory).

INCIBE-CERT (Spain's national cybersecurity incident response center) published an advisory flagging the vulnerability shortly after disclosure (INCIBE Advisory). IT Resit Labs published a technical blog post analyzing the root cause, titled "PrestaShop Trust Issues: Reading the Wrong End of X-Forwarded-For" (IT Resit Labs). The vulnerability was also noted on Bluesky via automated CVE tracking accounts, with no significant broader community controversy or debate observed.