PrestaShop's Configuration Risk Is Wider Than the Pages That Carry Its Name
PrestaShop administrators often start an exposure review with storefront pages. The recent debug-mode PHP injection issue shows that the useful inventory includes the back office, the PHP runtime and the configuration files it can write.
On 2026-11-13 between 07:40 and 07:42 Asia/Shanghai, ZoomEye count-only queries used sub_type=all, page 1 and page size 1.
| Query | Matching assets |
|---|---|
app="PrestaShop" | 32,915 |
title="PrestaShop" | 8,974 |
The counts describe matching internet assets. They do not show which installations run a vulnerable release, expose the back office or allow the PHP process to write the configuration.
Read the gap correctly
The application fingerprint is about 3.7 times larger than the title count in this observation. A title-only search would miss many assets that ZoomEye's application fingerprint associates with PrestaShop. The reverse comparison also matters: a title can contain the product name for a page that is not a live store or is protected by a gateway.
Use the app query as a candidate inventory and the title query as a second view. Join both to internal records such as hostname ownership, ecommerce platform version and exposure path. Do not infer vulnerability from the difference between the two numbers.
Where the back office sits
CERT/CC VU#385711 describes a code injection in Performance > Debug mode. An authenticated administrator can add crafted values to the debug cookie configuration, which PrestaShop writes into executable PHP. The file is loaded during application initialization.
ZoomEye can locate candidate installations, but it cannot see the account permissions or whether the PHP process can write config/defines.inc.php. Those checks require configuration and file-permission evidence from the owner.
Start with the administration hostnames and paths. Confirm whether they resolve to the same PrestaShop asset, whether access is limited to trusted networks and which accounts can change Performance settings.
Query plan
Run the app query to find the broad candidate set. Filter the result with organizational ownership, geography or certificate evidence when those fields are relevant. Use the title query to find named storefronts that the app fingerprint may not cover.
For each candidate, record the PrestaShop version, the public administration endpoint and the responsible team. Mark unknown values instead of converting a search match into a vulnerable status.
Verification and response
PrestaShop 9.2.1 fixes the code injection. For older installations, review debug mode, administrator permissions and file write access. Inspect the runtime configuration for unexpected PHP statements and compare it with a known-good deployment artifact.
If the back office account was compromised, rotate application secrets and review file and database activity. Keep the search evidence with the query scope and time so another analyst can reproduce the candidate set.
