Security

Most of the vulnerable code in a typical shop is not in the core. The Friends-of-Presta community maintains an independent feed of advisories at https://security.friendsofpresta.org (its source is the repository friends-of-presta/security-advisories on GitHub, where each advisory is a Jekyll post). At the check date the feed had 230 entries on 23 pages of 10, and the large majority concern modules, themes or hosting stacks, not the core. The latest entries show that the risk is not limited to obscure modules:

Two of the eight latest entries are tagged as core and six concern modules, one of them an official payment module. The practical rule is that a module is code from a third party until it has been read, whoever distributes it.

The most serious recent case in an official module is advisory GHSA-m5f5-28qr-9g9r, CVE-2026-54159, published on 2026-06-03 with the maximum CVSS score of 10.0 (network attack, low complexity, no privileges, no user interaction, changed scope, high impact on confidentiality, integrity and availability). The module ps_facetedsearch powers the filters on category pages. In versions 3.0.0 through 4.0.3 it read a cached filter block with PHP unserialize(), so an unauthenticated visitor who could influence the cached data could trigger PHP object injection and, with a suitable class available, remote code execution. The fix is release 4.0.4. The advisory lists a workaround for shops that cannot update at once: remove the price and weight slider filters, clear the cache, audit the module directory and put a web application firewall in front of the shop. It also gives the manual code change, which is the pattern used in the rest of this page: replace the native call by the core helper that refuses to build objects.

Source: GitHub: GHSA-m5f5-28qr-9g9r (ps_facetedsearch)

The PrestaShop 9.2.0 image bundles ps_facetedsearch 5.1.0. The installed version of any module is available from the command line, which is how to check a shop against an advisory:

The output of the command on the local shop contained these rows (the other 80 rows are omitted):

Source: PrestaShop devdocs: Console commands

The helper itself is part of the core class Tools. It was hardened in PrestaShop 9.0.1 and, with object loading disabled (the default), it rejects any serialized string that contains an object and passes allowed_classes set to false to the native function. On the local shop:

Source: GitHub: GHSA-m5f5-28qr-9g9r (manual fix)

For new code the better choice is not to serialize PHP values at all: store JSON and decode it with json_decode() and JSON_THROW_ON_ERROR, as the callback controller below does.

The main class registers nothing but a table and a configuration key. The secret used to verify the callback is generated on installation with Tools::passwdGen(), so no two shops share it and no secret is committed:

Source: PrestaShop devdocs: Module file structure

Every folder of the module also contains the standard index.php that redirects to the parent directory, so that a directory listing never shows the module’s files if the web server allows listings. This is a rule of the Addons validation checklist ("an index.php file exists in each folder") and it matters because of the wildcard service resources described in the page on module services: exclude index.php from them. On PrestaShop 9 a second protection exists, a .htaccess in the modules folder, which is described in Hardening a shop.

The core exposes two escaping functions and a query builder. pSQL() calls Db::escape(), which leaves numbers untouched, escapes quotes with the connection’s escape function and, unless the second argument is true, strips HTML tags and turns newlines into br. bqSQL() additionally escapes the backtick, and is meant for identifiers. Casting with (int) and (float) is the right control for numeric values. The query builder DbQuery assembles select, from, where, orderBy and limit parts but does not escape what is put into them, so where() still needs pSQL() for strings.

The repository class of the module keeps an unsafe method on purpose, so that the effect of the rule can be measured:

A script run in the shop context inserted two rows (the callback test below had already added one) and then queried them with the attack string x' OR '1'='1 through both methods:

Output on PrestaShop 9.2.0:

The unsafe method returned every row of the table, the safe method returned none for the attack and one for the legitimate reference. Three more results from the same script document how the helpers behave: pSQL('<b>bold</b> 1') returned bold 1 and pSQL('<b>bold</b> 1', true) returned the markup unchanged; bqSQL() applied to an identifier that contained a backtick returned it with the backtick escaped by a backslash; the cast of the string 12abc; DROP TABLE x to int returned 12.

Db::insert() and Db::update() with an array take care of quoting the column names, but the values still have to be passed through pSQL() unless they are numeric, as the add() method above does. The recurring defects in the advisories (for example the SQL injection through back-office list filters) come from a value that reached a query without one of these steps. A review of a third-party module can start by searching for request data inside query text: in the modules bundled with the shop the search for WHERE or SET followed by Tools::getValue( returned only lines where the value is cast to int first.

Source: PrestaShop devdocs: Db class

Source: PrestaShop devdocs: DbQuery

Tools::getValue() reads $_POST first and then $_GET, and removes NUL bytes (on the shop a value with a NUL byte between the letters ab and cd came back as abcd). It does not validate or escape anything else. Validation is the job of the Validate class, whose methods return booleans: isUnsignedId(), isEmail(), isCleanHtml() and many more. Validate::isCleanHtml() rejects markup with event attributes: on the local shop <a onclick="x()">a</a> returned false and <p>ok</p> returned true. The good-practices page of the project adds the rules for uploads (check the file type with mime_content_type()), for forms (show a confirmation or an error and validate with Validate) and for optional PHP extensions (check with extension_loaded()).

The HTML purifier of the core, Tools::purifyHTML(), is controlled by the setting PS_USE_HTMLPURIFIER (enabled on the local shop). It is configured as a trusted purifier (HTML.Trusted is true), which keeps script elements: on the local shop <p onclick="x()">Hi<script>alert(1)</script></p> came back with the onclick attribute removed and the script element still present. It is meant to normalise rich text written by back-office users, not to make hostile input safe. Never use its output as a replacement for output escaping. When the setting PS_ALLOW_HTML_IFRAME is enabled the purifier also allows iframe and object elements from any source (URI.SafeIframeRegexp is set to /.*/), which is a deliberate widening and should stay off unless the shop needs embedded video.

Source: PrestaShop devdocs: Good practices for developing modules

The front office renders with Smarty 4.5.7, and the core front configuration turns on escape_html (config/smartyfront.config.inc.php), so {$variable} is HTML-escaped by default. The escape is bypassed by the modifier nofilter, which is needed for markup that was produced on purpose (for example a rendered widget) and is the usual place where the stored cross-site scripting of the March 2026 advisory lives: a variable that carries user data, rendered with nofilter. The back office renders with Twig, which escapes {{ variable }} by default; the filter raw is the equivalent bypass.

The template of the Coffee Club page shows a value taken from the query string. The controller passes it unchanged, the template escapes it, and a request with a script in the query string is rendered inert:

Request with ?coffee=<script>alert(1)</script> on the local shop, with the template above:

The same request after changing only {$pcfi_coffee} to {$pcfi_coffee nofilter} and clearing the compiled Smarty templates (reflected cross-site scripting), and a request with an img element carrying an onerror attribute:

The original template was restored afterwards. The review rule is simple: every nofilter in a template must be justified by a value that the module itself generated, and a search for the keyword is the first step of an audit (the modules of this 9.2.0 install contain it in 32 template files, which is normal for rendered widgets and is why the reviewer has to read each use).

Since PrestaShop 9.0 the translation functions trans() and the Smarty l function no longer escape their output, and the parameters htmlspecialchars and addslashes were removed. A translated string that is built from user input must therefore be escaped by the caller.

Source: PrestaShop devdocs: Core updates 9.0 (the trans method)

Source: PrestaShop devdocs: Smarty extensions

The front controller join lets a logged-in customer join the Coffee Club. Joining changes data, so the form carries a token that is derived from the customer, the password hash and a page name, and the controller compares it in constant time. The property $auth = true makes the dispatcher redirect anonymous visitors to the login page, and $authRedirection is the back value used after the login.

Tools::getToken($page) returns Tools::hash($customerId . $passwordHash . $page), where the hash uses the shop’s cookie_key. With a logged-in customer the token is therefore different for every customer, and it changes when the customer’s password changes. For a guest the customer id and the password are empty, so the token depends only on the page name. Do not use it as a secret for anonymous forms; require a session or a login for any action that matters.

Test on the local shop with a customer created for the run (ada-pcfisec@example.test, removed at the end), logged in with curl:

Results on PrestaShop 9.2.0:

Source: PrestaShop devdocs: Front controllers

Payment providers call the shop to say that a payment succeeded. That endpoint cannot use cookies or form tokens, and the checklist of the Addons validation for payment modules says what to do instead: double check the cart id before creating the order, pass the amount reported by the provider (not getOrderTotal()) to validateOrder() when the order is created only after the provider approves, and verify the origin of the call with a signature or a token. The example does the same without creating orders: it verifies a signature, validates the body, compares the amount with the cart and records the callback.

The signature check lives in a small class so that it can be unit tested without PrestaShop (the testing page does exactly that):

Source: PrestaShop devdocs: Front controllers

The front controller reads the raw body (never through $_POST, because a signature covers the exact bytes), limits its size, verifies the signature before it parses anything, validates every field, and answers with a status code that tells the provider whether to retry:

The test uses the secret that the installation stored in the shop configuration, taken from the database in the shell variable CALLBACK_SECRET (a throw-away value, not shown) and signs the body with OpenSSL:

Results (the cart 1 of the local shop had a total of 54.84 EUR, tax included, at the time):

After the last call the table contained one row: cart 1, reference PC-ETH-WHL-250, amount 54.84. A first version of the controller returned the expected total as a float, which JSON encoded as 54.840000000000003; formatting it with number_format() fixes the response. The three design decisions worth copying are: the signature is checked before the body is parsed; hash_equals() is used so that the comparison time does not reveal how many leading characters matched; and the amount comes from the shop’s own cart, so a valid signature on a body for another amount cannot create a cheaper order. A real integration would also check a timestamp inside the signed body to bound replays and would make the handler idempotent on the provider’s event id.

Source: PrestaShop devdocs 1.7: Addons technical validation checklist (payment modules)

Source: PHP: hash_equals

Back-office actions are Symfony controllers. Since PrestaShop 9.0 they extend PrestaShopAdminController (the older FrameworkBundleAdminController is deprecated) and are secured with the #[AdminSecurity] PHP attribute, which replaced the earlier annotation of the same name. The attribute holds an expression evaluated by the security voter, normally is_granted('read', request.get('_legacy_controller')), and the permission is looked up for the tab named by the route’s _legacy_controller default. The four permissions are create, read, update and delete. The module below has two actions, a read-only list and a purge that needs the delete permission and, because the form is rendered by the module itself, validates a Symfony CSRF token.

Source: PrestaShop devdocs: Admin controllers

Source: PrestaShop devdocs: Admin controllers

Source: PrestaShop devdocs: Admin controllers

Installing the module created a hidden tab AdminPcfisecurityLog (inactive, without parent) and the permission rows ROLE_MOD_TAB_ADMINPCFISECURITYLOG_CREATE|READ|UPDATE|DELETE in ps_authorization_role, besides the module-level roles ROLE_MOD_MODULE_PCFISECURITY_*. The installer logged one harmless error line, "Cannot register tab AdminPcfisecurityLog because it already exists", because the route default and the module tab registration both tried to create it. Employee profiles get access to the tab in Advanced Parameters > Team > Permissions.

Two mechanisms protect the back-office URLs. The first is the _token query parameter that the back-office URL generator adds to every route URL (path() in Twig does it); a request without a valid token is answered with a redirect to the security page security/compromised, which offers a link with the right token. The second is the voter of #[AdminSecurity]. A test with curl on the local shop, after logging in as the local administrator:

Results: the URL without the token returned 302 to the security page; the tokenised URL returned 200 and listed the three rows that the earlier tests had written; the purge with a bad CSRF token returned 302 and left the three rows in the table; the purge with the token from the form returned 302 to the log page and the table became empty.

The core ships a linter that finds back-office routes without the attribute:

On the shop the first command listed three routes of the Marketplace module (admin_mbo_module_cdc_error, admin_mbo_recommended_modules, admin_mbo_addons_module_upgrade). The linter only inspects routes whose names start with admin_, which is why the module routes above are named admin_pcfisecurity_log and admin_pcfisecurity_log_purge: routes with other names never appear in either list. After the names were changed, list showed both module actions as secured with the permissions read and delete. When the attribute was removed from purgeAction() and the cache was cleared, find-missing listed admin_pcfisecurity_log_purge (the command returns exit code 1 when it finds something, so it can fail a CI job); restoring the attribute made it disappear. The sibling linter prestashop:linter:naming-convention is written for the core’s route naming and, for this module, printed the names it would expect (admin_logs_index and admin_logs_purge); treat it as advice, not as a rule for modules.

Source: PrestaShop devdocs: Admin controllers (Secure your controller)

Source: PrestaShop devdocs: Controller and routing (Security)

PrestaShop 9.0 forbids calling PHP files under modules/ directly; every entry point must be a controller. The core modules/.htaccess enforces it: it denies requests for files that end in .php, .log, .txt, .lock, .json, .yml, .yaml, .tpl, .twig, config.xml and the localised config_xx.xml files, using Require all denied on Apache 2.4 and the older Deny from all on Apache 2.2. On the local shop the files of the module pcfisecurity returned 403 for pcfisecurity.php, a Smarty template, composer.json and vendor/composer/installed.php. Nginx does not read .htaccess, so on Nginx the same deny rules must be written in the server configuration.

A cron job should therefore be a front controller that refuses non-CLI calls and checks a token, as in the sample of the developer documentation, or better a Symfony console command that is run by the system cron. A module that stores files should write them to var/modules/<name>/ (static data) or var/cache/<env>/modules/<name>/ (cache) and not to the module folder; a module that accepts uploads must check the type of the file and store it outside the web root or with the execution of scripts disabled.

Source: PrestaShop devdocs: Front controllers (cron tasks)

The file app/config/parameters.php holds the database credentials, the mailer credentials, the secret of the Symfony kernel, the cookie_key and cookie_iv that encrypt cookies and are used to compute tokens, new_cookie_key, and the public and private key of the Admin API. Treat it like a private key: keep it out of repositories, backups that leave the server, bug reports and screenshots; the web server must answer 403 for it (it does by default, see below). A leaked cookie_key lets an attacker forge cookies and tokens, and changing it logs every user out. Module secrets, such as the callback secret above, belong in the Configuration table or in environment variables, are generated per shop and are never logged. This documentation never prints the values of the local shop; examples use placeholders and shell variables.

The web installer renames the admin folder to a random name (the local installation logged "The admin folder was renamed into admin170iiqhcg4nvcac0mw2/" and a request for /admin/ now returns 404), and from PrestaShop 9.2 it also deletes the install/ folder automatically, as the changelog of 9.2 describes (only a folder named exactly install is removed, install-dev is not touched, and a failure to delete only logs a warning). The local installation logged "The install/ folder was removed." Check that both statements hold on a shop that was installed with an older version, or that was built with the Docker image and a custom admin folder name.

The following probe requested paths that must never be reachable from the Internet on the local 9.2.0 shop (Apache 2.4.68, the default .htaccess generated by the installer, no extra rules):

The same probe is worth adding to a deployment pipeline for any shop. It only checks what the web server answers, so a shop behind Nginx must be probed separately, because the .htaccess files do not apply there.

The core’s configuration page tells production shops to disable debug mode: _PS_MODE_DEV_ and _PS_DEBUG_PROFILING_ must be false (the defaults of config/defines.inc.php), because debug mode prints stack traces and has a large performance cost. The Docker image takes the setting from the environment variable PS_DEV_MODE; its default is 0, but the value is tested for truthiness, so the string false also enables debug mode: leave the variable unset or set it to 0. The pre-9.2 documentation claims the default is 1, which is not what the image does.

Source: PrestaShop devdocs: Configuring PrestaShop

Source: PrestaShop devdocs: Core updates 9.2 (automatic removal of the install folder)

The core sets no Content-Security-Policy, X-Frame-Options or Strict-Transport-Security header. A search of the 9.2.0 PHP, .htaccess, YAML and template files outside vendor/ for Content-Security-Policy returned nothing, the developer documentation for 8 and 9 does not mention CSP, and the front-page response of the local shop carries only cookie flags. The .htaccess it generates sets Access-Control-Allow-Origin "*" for fonts and svg files and removes the ETag header. Headers are therefore a web server or CDN responsibility.

A strict CSP is hard on a PrestaShop shop because themes and modules print inline scripts and because tag managers and checkout modules load scripts from other origins; a policy that forbids inline scripts breaks them. The practical path is to start with Content-Security-Policy-Report-Only, collect the reports, and tighten the policy gradually (this guidance is an inference from how the platform is built, not a documented procedure). A configuration that sets the other headers and a report-only policy was syntax checked and served by Apache 2.4 in a separate container (it was not applied to the shop):

httpd -t reported "Syntax OK" with the headers module loaded, and curl -I over HTTP returned all of the headers except Strict-Transport-Security, which the condition on %{HTTPS} correctly withholds on a plain HTTP connection.

Source: Apache HTTP Server: mod_headers

Source: MDN: Content Security Policy