PrestaShop gmfeed Arbitrary File Write (CVE-2026-85520): Save-to-File URLs and Shop Takeover

E-commerce modules are part of your crown jewels

PrestaShop shops run payment flows, customer PII, and operator credentials in the same PHP process as third-party modules. CVE-2026-85520 targets Google Merchant Center Feed (gmfeed) by MyPresta.eu / VEKIA—CVSS 3.1 9.3 Critical—via unauthenticated arbitrary file write on modules/gmfeed/feed.php when save-to-disk / URL export mode is reachable without a per-shop secret.

Affected builds: ≤ 2.3.9. Vendor fix: ≥ 2.3.10 (store-specific key on save URLs); 2.4.1+ recommended with full module file removal on upgrade—not zip-over-zip.

Public mechanism and lab tooling: CVE-2026-85520 on pocbit.org. Repository: murrez/CVE-2026-85520.

What “Save to file” did wrong

gmfeed generates product feeds for Google Merchant Center. When merchants enable export saved to file (including cron-friendly URLs), legacy feed.php accepted crafted parameters controlling:

• Output filename and path
• Extension (including .php)
• Body content (not validated as XML/CSV)

There was no authentication and no per-store secret on those URLs in vulnerable versions. An unauthenticated HTTP request could write a web-served PHP file under modules/gmfeed/ (or via traversal patterns), then execute it—CWE-20 / CWE-73 / CWE-434 class issues collapsing to RCE.

Vendor 2.3.10+ adds a shop-specific key on save URLs and closes unauthenticated writes. Simply copying a new zip without delete module files may leave a vulnerable feed.php on disk—follow MyPresta uninstall guidance.

Who must act

| Role | Why | |------|-----| | Shop owner / agency | Direct revenue and PCI-adjacent blast radius | | Hosting / MSP | Shared PrestaShop instances, stale modules across tenants | | AppSec | Module inventory rarely matches SBOM reality | | SOC | POST/GET spikes to /modules/gmfeed/feed.php after CVE press |

Defender checklist

| # | Task | Notes | |---|------|-------| | 1 | Confirm gmfeed installed and version | Back office modules list; modules/gmfeed/config.xml | | 2 | If ≤ 2.3.9, plan emergency change | Maintenance window + rollback snapshot | | 3 | Uninstall with delete module files | Critical—removes old feed.php | | 4 | Install ≥ 2.4.1 (minimum 2.3.10) from vendor account | Clean tree | | 5 | Regenerate all “Save to file” and cron URLs | New store key invalidates leaked old links | | 6 | Audit modules/gmfeed/ for unknown .php | Incident indicator | | 7 | Review web server logs for exportsavefile, odd exportfilename params | See PoC parameter rotation patterns |

Pair with how to prioritize critical CVEs and file upload / write vulnerabilities.

Detection hints (your assets only)

Module presence (not proof of exploitability alone):

body="/modules/gmfeed/" || body="gmfeed"
/modules/gmfeed/config.xml
/modules/gmfeed/products.xml

Many shops already patched after MyPresta’s 2026 advisory—internet-wide scans will show mixed patched_version vs write_or_verify_failed. Use signals to prioritize your fleet, not to attack strangers.

Patch validation

In an authorized lab PrestaShop VM:

1. Install vulnerable gmfeed with save-to-file URL enabled per vendor docs.
2. Run check mode from the PoC page—confirm version flag < 2.3.10.
3. Use dry-run exploit modes before any write test; full exploit drops marker stubs only—remove artifacts after testing.
4. Upgrade via uninstall + clean install; re-run check—expect patched closure.

Safe PoC lab setup applies to e-commerce clones with fake payment gateways only.

Business impact beyond “another RCE CVE”

Shop takeover enables:

• Skimmer injection on checkout templates
• Admin credential harvesting
• Database dump via web shell
• SEO spam and brand damage

A 9.3 module bug on the same vhost as checkout is not a “low priority plugin ticket”—it is incident-grade until version and filesystem audit complete.

FAQ

We only use on-demand feed generation, not save-to-file—is that safe?

Lower exposure if save URLs are unreachable, but upgrade anyway. Misconfiguration and cron jobs appear later; stale feed.php remains on disk in vulnerable builds.

Shared hosting—can we rely on the host?

Ask for module version attestation and file integrity on modules/gmfeed/. Shared panels rarely auto-patch commercial modules.

Where do new PrestaShop-class CVEs show up?

Monitor CVE Detector, NVD, and vendor mail. When pocbit publishes a PoC, treat it as a patch-deadline accelerator for your inventory row—not as permission to scan the internet.

Bottom line

CVE-2026-85520 is unauthenticated write → execute on a revenue-critical stack. Delete vulnerable module files, install fixed gmfeed, rotate export URLs, and prove closure in a lab. E-commerce defenders win by naming modules and versions, not by hoping attackers ignore /modules/gmfeed/feed.php.