Vulnerability in MyPresta Google Merchant Center Feed software

CVE-2026-85520 is an unauthenticated arbitrary file write in the Google Merchant Center Feed (gmfeed) module for PrestaShop sold by the Polish vendor MyPresta. Requests to the module's feed.php endpoint control the output file name, path, extension, and content through request parameters with no authentication and no validation, so an attacker can plant PHP on the server and execute it, which makes this pre-authentication remote code execution. Every release from 1.9.1 through 2.3.8 is affected. CERT Polska coordinated the disclosure, credits a responsible report from Today Group sp. z o.o., and published the advisory on 29 September 2026; the EUVD entry EUVD-2026-88735 carries a CVSS score of 9.3 on a network vector with no privileges and no user interaction.

Pre-auth RCE on an internet-facing storefront means full server compromise: web shells in the module directory, payment skimmers injected into templates, theft of the customer and order database. The vendor posted its own fix notice on 26 August 2026, a month before the CVE went public, so a patched-but-unnamed flaw sat in shops for weeks described only in release notes that no scanner indexes. The CVE id is what lets attackers and defenders alike line up exposure, and the affected product is a 25 EUR addon running on PrestaShop 1.6 through 9.x, a long tail of small shops that patch slowly and rarely read vendor news. No exploitation telemetry exists yet, but a trivially reachable unauthenticated write endpoint is precisely the shape that gets mass-scanned once a PoC circulates.

Install 2.3.10 or later and verify the version shown in Module manager; the vendor recommends 2.4.1 and currently ships 2.4.3, while CERT Polska names 2.3.9 as the fix, so treat 2.3.10 as the safe floor. The update must be a clean reinstall: uninstall the module with the delete module files option checked, confirm modules/gmfeed/ is gone from disk, then upload the new package, because copying a zip over the old install can leave the vulnerable script in place. Regenerate any save-to-file or cron feed URLs afterward; they now embed a store-specific key and old generate links stop writing files, while live generation URLs keep working. For hunting, review web access logs for unauthenticated requests to feed.php under the gmfeed module path carrying file name, path, extension, or content parameters, and sweep the module and upload directories for unexpected PHP files; blocking external access to feed.php at the web server or WAF is a valid interim restriction.

Two developments would change the assessment. Public PoC code or GreyNoise/Shodan-style telemetry showing scanning for feed.php would move this from patch-now to incident-response for anything unpatched, and a CERT-PL or vendor confirmation of exploitation in the wild would confirm compromise risk for the installed base.