Client IP address can be spoofed through the X-Forwarded-For header

Client IP address can be spoofed through the X-Forwarded-For header

Impact

This is an IP address spoofing issue that can lead to access control bypass.

When a shop runs behind a reverse proxy, a load balancer or a CDN, the visitor's real IP address is passed to PrestaShop through an HTTP header. PrestaShop read the wrong end of that header, the part controlled by the visitor, rather than the part appended by the shop's own proxy.

Any visitor could therefore make the shop believe they were connecting from any address of their choosing, which undermines every feature relying on it: the maintenance-mode IP allow-list could be bypassed, security and audit logs could be filled with forged addresses, and third-party protections such as geolocation blocking, fraud scoring or rate limiting could be evaded.

Shops served through a reverse proxy, a load balancer or a CDN are impacted, which covers most production deployments. Shops where visitors connect directly to the web server are not affected. No account and no user interaction are needed.

Patches

PrestaShop now reads the forwarding header from the end of the chain and ignores the private and reserved addresses belonging to internal infrastructure, so the value returned is the one added by the shop's own proxy, which a visitor cannot forge.

Upgrade to PrestaShop 9.1.5 or PrestaShop 8.2.8

Correct IP handling is a shared responsibility between the application and the hosting setup, so the section below applies whether or not you have upgraded.

Workarounds

The issue can be fully mitigated at the proxy level, and we recommend doing so in addition to upgrading. Your front-end proxy must overwrite the forwarding header with the address it actually sees, instead of passing on whatever the visitor sent.

Nginx

``nginx proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; ``

If clients can reach Nginx directly, use proxy_set_header X-Forwarded-For $remote_addr; instead. Never use $http_x_forwarded_for, which forwards the visitor-supplied value untouched.

Apache — use mod_remoteip and declare only the proxies you trust:

```apache LoadModule remoteip_module modules/mod_remoteip.so

<IfModule mod_remoteip.c> RemoteIPHeader X-Forwarded-For RemoteIPTrustedProxy 10.0.0.0/8 RemoteIPTrustedProxy 172.16.0.0/12 RemoteIPTrustedProxy 192.168.0.0/16 </IfModule> ```

CDN users — make sure your origin only accepts connections from your CDN's address ranges, so nobody can reach it directly and inject their own header.

References

• CWE-290: Authentication Bypass by Spoofing
• CWE-348: Use of Less Trusted Source
• MDN: X-Forwarded-For
• Report a security issue: security-core@prestashop.com

Credits: this vulnerability was responsibly reported to the PrestaShop security team by Pedro Gabaldón Juliá, of ITRESIT. We thank them for their report and for coordinating the disclosure with us.