AP Page Builder, également connu sous le nom technique appagebuilder, est un constructeur de pages largement utilisé sur des boutiques PrestaShop, notamment parce qu’il est intégré depuis de nombreuses années à différents thèmes LeoTheme et ApolloTheme.
Comme beaucoup de composants anciens et très diffusés, AP Page Builder a connu plusieurs vulnérabilités de sécurité au fil du temps.
Il est important de le préciser : il n’existe pas une unique «faille AP Page Builder», mais plusieurs vulnérabilités différentes découvertes et corrigées progressivement : injections SQL, Cross-Site Scripting, traversée de chemins, lecture de fichiers, Server-Side Template Injection et, plus récemment, possibilité d’écriture de fichiers pouvant conduire à une exécution de code à distance.
Certaines de ces vulnérabilités sont particulièrement préoccupantes puisqu’elles peuvent être exploitées sans authentification préalable.
Chez Phenix Info, nous avons donc développé Phenix AP PageBuilder Guard, un module défensif destiné aux anciennes installations AP Page Builder qui ne peuvent pas immédiatement migrer vers une version récente.
Notre position reste simple : la meilleure solution est toujours de mettre AP Page Builder à jour vers une version corrigée lorsque cette mise à jour est techniquement possible.
Pourquoi AP Page Builder représente-t-il aujourd’hui un sujet de sécurité ?
AP Page Builder existe depuis de nombreuses années et accompagne encore beaucoup de boutiques PrestaShop 1.7 et 8.
Dans certains projets, il n’a d’ailleurs pas été installé séparément : il était directement intégré dans le thème acheté à l’époque.
Cela entraîne une situation que nous rencontrons régulièrement lors de maintenances :
- le site fonctionne parfaitement ;
- le thème n’est plus forcément maintenu ;
- AP Page Builder fonctionne toujours ;
- sa version peut dater de plusieurs années ;
- une mise à niveau majeure du module peut nécessiter une adaptation du thème ;
- l’administrateur n’a parfois même pas conscience de la présence de cette ancienne version.
Pendant ce temps, de nouvelles vulnérabilités peuvent être découvertes. C’est pourquoi la mise à jour régulière de PrestaShop et de ses modules constitue une première ligne de défense essentielle.
Plusieurs vulnérabilités AP Page Builder documentées depuis 2022
Pour comprendre la situation actuelle, il faut distinguer les différentes vulnérabilités publiquement documentées.
2022 : CVE-2022-22897 — injections SQL critiques
La vulnérabilité CVE-2022-22897 concerne plusieurs injections SQL dans AP Page Builder. Les paramètres product_all_one_img et image_product ont notamment été documentés comme vulnérables.
Selon le NVD, un attaquant non authentifié pouvait exploiter cette faiblesse afin d’exfiltrer des informations de la base de données. Le score CVSS v3.1 attribué par le NVD est de 9,8/10 — Critical.
Une injection SQL est particulièrement sensible sur une boutique e-commerce, car la base de données peut contenir des informations concernant les clients, les commandes, les employés, la configuration de la boutique et différentes données techniques.
2022 : CVE-2022-44897 — Cross-Site Scripting via show_number
La vulnérabilité CVE-2022-44897 concerne le paramètre show_number. Le NVD indique qu’AP Page Builder jusqu’à la version 2.4.4 pouvait accepter un contenu HTML ou JavaScript spécialement conçu via ce paramètre.
Cette vulnérabilité XSS dispose d’un score CVSS v3.1 de 6,1/10 — Medium.
2023 : CVE-2023-3743 — nouvelle injection SQL
En 2023, CVE-2023-3743 documente une autre injection SQL, cette fois notamment autour du paramètre product_one_img.
Le NVD reprend un score CVSS v3.1 de 7,5/10 — High et indique qu’un attaquant distant pouvait envoyer une requête spécialement construite pour récupérer des informations enregistrées dans la base de données.
Une particularité doit néanmoins être signalée : la numérotation des versions mentionnée dans la fiche publique de cette CVE ne correspond pas clairement aux branches historiques 2.x d’AP Page Builder. Nous préférons donc ne pas inventer de correspondance entre ces versions.
CVE-2024-6648 : une vulnérabilité particulièrement importante
La vulnérabilité CVE-2024-6648, rendue publique en 2025, concerne les versions AP Page Builder antérieures à 4.0.0.
Elle est classée Path Traversal et obtient un score CVSS v4.0 de 8,7/10.
Que permet CVE-2024-6648 ?
Le problème se situe notamment autour du champ product_item_path présent dans une configuration JSON transmise à AP Page Builder.
Dans les versions vulnérables, un utilisateur distant non authentifié peut manipuler ce chemin afin de demander au module d’utiliser un fichier situé en dehors de l’emplacement normalement prévu.
INCIBE-CERT indique que cette vulnérabilité peut permettre de lire des fichiers présents sur le système.
Sur un serveur web, cette capacité est particulièrement sensible : certains fichiers de configuration peuvent contenir des identifiants de base de données ou d’autres informations pouvant faciliter la poursuite d’une compromission.
Le Base64 complique également le filtrage
La configuration concernée est transmise sous une forme encodée. Cela illustre une limite importante des protections reposant uniquement sur l’inspection superficielle de la requête HTTP : rechercher simplement une chaîne suspecte dans la requête brute ne suffit pas toujours.
Un WAF constitue une couche de sécurité importante, mais il ne doit jamais être considéré comme le remplacement d’un correctif applicatif.
Le correctif officiel : AP Page Builder 4.0.0
Concernant CVE-2024-6648, INCIBE-CERT indique que la vulnérabilité a été corrigée par Apollo Theme dans AP Page Builder 4.0.0.
PrestaShop recommande également la mise à jour du module vers la version 4.0.0 dans son avis de mise en conformité.
Pour les thèmes embarquant une ancienne version du module et ne permettant pas facilement cette mise à niveau, PrestaShop a également publié une modification ciblée du fichier :
appagebuilder/classes/shortcodes/ApProductList.php Le principe du correctif est notamment de ne plus laisser le client contrôler librement product_item_path.
2026 : nouvelles alertes SSTI, Path Traversal et ApGenCode
L’histoire ne s’est pas arrêtée avec CVE-2024-6648.
Le 9 mai 2026, LeoTheme a publié une nouvelle alerte concernant des problèmes de Server-Side Template Injection / Path Traversal.
En 2026, LeoTheme a également publié une alerte critique concernant ApGenCode, sous le titre : “Fix critical unauthenticated RCE via ApGenCode (Server-Side Template Injection / Arbitrary File Write)”.
Cette nouvelle alerte associe plusieurs notions particulièrement sensibles :
SSTI → écriture arbitraire de fichier → possibilité d’exécution de code à distance.
De la vulnérabilité au webshell
Une vulnérabilité ne laisse pas toujours une trace immédiatement visible sur la page d’accueil d’un site.
Un attaquant peut chercher à obtenir un accès persistant en ajoutant ou modifiant un fichier PHP. Lorsqu’un tel fichier permet ensuite de piloter des actions sur le serveur, on parle couramment de webshell.
À partir de ce moment, le problème ne concerne plus uniquement AP Page Builder : des fichiers peuvent avoir été créés ou modifiés ailleurs dans l’installation.
C’est précisément pour cette raison qu’appliquer un correctif après une compromission ne suffit pas à nettoyer le serveur.
Un incident réel nous a poussés à aller plus loin
Notre démarche ne repose pas uniquement sur la lecture des CVE et des avis de sécurité.
Nous avons également été confrontés à la compromission d’une boutique utilisant une ancienne version d’AP Page Builder, avec notamment la présence d’un fichier PHP malveillant déposé à la racine du site.
Nous faisons cependant une distinction importante entre les vulnérabilités techniquement documentées publiquement et les éléments constatés pendant l’analyse d’un site compromis.
La présence d’un fichier malveillant ne permet pas, à elle seule, de reconstituer avec certitude chaque étape suivie par l’attaquant.
C’est pourquoi le développement de Phenix AP PageBuilder Guard s’appuie en priorité sur les CVE, les publications d’organismes de sécurité, les recommandations PrestaShop et les correctifs publiés par l’éditeur.
Phenix AP PageBuilder Guard : pourquoi avons-nous créé ce module ?
Dans l’idéal, la réponse est simple : mettre AP Page Builder à jour.
Mais certaines boutiques utilisent une ancienne branche d’AP Page Builder fortement liée à leur thème. Une migration immédiate peut alors entraîner des incompatibilités avec les profils, shortcodes, templates, listes de produits ou personnalisations réalisées au fil des années.
Nous avons donc créé Phenix AP PageBuilder Guard comme mesure de mitigation pour les installations historiques qui ne peuvent pas encore migrer proprement.
La version analysée du module cible les branches historiques AP Page Builder 2.2.0 à 2.4.9 sur PrestaShop 1.7.x à 8.x.
AP PageBuilder Guard n’a pas vocation à remplacer les corrections officielles sur les branches récentes du module.
Une approche basée sur le code réellement installé
Toutes les versions AP Page Builder 2.x ne possèdent pas exactement les mêmes fichiers ni les mêmes lignes de code.
Appliquer aveuglément un patch prévu pour une version donnée sur une autre version pourrait provoquer une erreur ou casser le fonctionnement du thème.
Phenix AP PageBuilder Guard utilise donc une détection structurelle : il recherche les points vulnérables connus dans les fichiers réellement installés.
Si la structure attendue n’est pas reconnue, le module préfère arrêter la modification plutôt que d’injecter un correctif à un emplacement incertain.
Protection de apajax.php
apajax.php est l’un des points d’entrée historiques importants d’AP Page Builder. Le Guard y ajoute plusieurs contrôles.
Validation des listes numériques
De nombreux paramètres historiques sont censés contenir uniquement des identifiants numériques. Le module vérifie et normalise plusieurs valeurs utilisées par les produits, images, attributs, fabricants et différentes listes AJAX.
Le principe est simple : une valeur censée représenter une liste d’identifiants ne doit pas devenir une portion libre de requête SQL.
Validation de show_number
Le paramètre show_number, concerné par CVE-2022-44897, est traité comme une valeur numérique attendue. Un contenu HTML ou JavaScript n’a donc aucune raison d’être accepté dans ce champ.
Contrôle des contenus sensibles transmis en AJAX
Le module contrôle également plusieurs contenus envoyés par les appels AJAX afin de bloquer certaines primitives dangereuses avant qu’elles n’atteignent le code historique d’AP Page Builder.
Protection de la configuration encodée et de product_item_path
Lorsqu’une configuration AP Page Builder est transmise sous forme encodée, le Guard :
- la décode ;
- vérifie qu’elle correspond à du JSON exploitable ;
- recherche des chemins anormaux et certaines valeurs dangereuses ;
- contrôle les différentes données attendues ;
- interdit que
product_item_pathsoit librement imposé par la requête distante ; - reconstruit ensuite une configuration contrôlée.
L’objectif est de ne pas se contenter de filtrer la chaîne HTTP brute, mais de contrôler la donnée après décodage, au moment où elle peut réellement devenir dangereuse.
Protection d’ApProductList.php
Le Guard applique également une protection directement dans :
classes/shortcodes/ApProductList.php Pour product_item_path, le principe suit celui du correctif publié par PrestaShop : le chemin utilisé par le serveur ne doit plus pouvoir être librement choisi par une requête distante.
Le Guard ajoute par ailleurs des contrôles destinés à maintenir le chemin dans les emplacements attendus d’AP Page Builder ou du thème.
Protection des écritures de fichiers
L’une des différences majeures entre une vulnérabilité de lecture de fichier et une vulnérabilité pouvant conduire à une RCE est la possibilité d’écrire un contenu contrôlé par l’attaquant sur le serveur.
Le Guard ajoute donc des contrôles autour d’anciennes fonctions d’écriture utilisées par AP Page Builder.
Pour les templates, plusieurs éléments sont notamment contrôlés :
- le nom du fichier ;
- l’extension ;
- l’emplacement ;
- le contenu du template ;
- certaines primitives Smarty dangereuses ;
- des contenus caractéristiques de scripts malveillants.
Protection spécifique d’ApGenCode
Lorsque la version d’AP Page Builder possède l’ancien mécanisme ApGenCode correspondant aux structures prises en charge, le Guard ajoute des vérifications avant génération d’un template.
Il contrôle notamment :
- le nom du fichier ;
- son chemin ;
- son extension ;
- le contenu destiné au template.
L’objectif est d’empêcher qu’un mécanisme normalement destiné à générer du contenu de présentation puisse être détourné pour écrire un fichier ou un template dangereux.
Désactivation d’un ancien téléchargement HTTP distant
Certaines anciennes branches AP Page Builder possèdent également une fonction capable de récupérer un fichier distant via HTTP.
Lorsque le Guard détecte l’ancienne implémentation concernée, il désactive ce comportement afin de réduire la surface d’attaque.
Un journal de sécurité indépendant
Les blocages réalisés par Phenix AP PageBuilder Guard sont enregistrés dans un journal dédié.
Le journal peut notamment contenir :
- la date ;
- le type d’événement ;
- la raison du blocage ;
- l’adresse IP vue par le serveur ;
- la méthode HTTP ;
- l’URL ;
- certains paramètres utiles à l’analyse.
Les données sensibles connues sont masquées avant journalisation et les fichiers de logs sont bornés afin d’éviter une croissance incontrôlée.
Sauvegarde automatique avant modification
Modifier physiquement les fichiers d’un module en production doit toujours pouvoir être annulé.
Avant l’application des patchs, Phenix AP PageBuilder Guard conserve donc une sauvegarde des fichiers concernés afin de permettre une restauration.
Des contrôles de chemins et des sommes SHA-256 sont également utilisés dans les mécanismes de sauvegarde et de contrôle d’intégrité.
Vérification de l’intégrité du patch
Le Guard ne considère pas qu’un patch est actif simplement parce qu’une option est enregistrée dans PrestaShop.
Il recherche les marqueurs de sécurité directement dans les fichiers concernés afin de pouvoir détecter différents cas :
- AP Page Builder a été réinstallé ;
- un fichier a été remplacé ;
- une mise à jour du thème a écrasé le correctif ;
- une restauration a remis une ancienne version du fichier.
Un scanner malware ciblé sur AP Page Builder
Le module possède également un scanner ciblé. Il recherche dans les fichiers PHP et Smarty d’AP Page Builder plusieurs signatures associées à des comportements suspects.
Il peut notamment rechercher :
- des constructions d’exécution dynamique de code ;
- des appels système anormaux ;
- des loaders encodés ou compressés ;
- du PHP présent dans un template Smarty ;
- certaines fonctions de création ou modification de fichiers ;
- des constructions caractéristiques de droppers ou webshells.
Lorsqu’un fichier réellement suspect est identifié, une fonction de quarantaine peut être utilisée.
Une limite volontaire et importante : ce n’est pas un antivirus PrestaShop
Le scanner intégré à Phenix AP PageBuilder Guard est volontairement limité au périmètre AP Page Builder.
Il ne remplace pas un scan complet de :
- la racine de PrestaShop ;
- l’ensemble des autres modules ;
- le thème ;
- les répertoires d’upload ;
- les caches ;
- l’ensemble du serveur.
Cette limite est volontaire : AP PageBuilder Guard doit rester un patch de sécurité spécialisé AP Page Builder, pas devenir un faux antivirus donnant l’impression qu’une installation complète a été contrôlée.
Une boutique déjà compromise nécessite un véritable audit
Installer le Guard sur une boutique ayant déjà été compromise ne suffit pas.
Dans ce cas, il faut également contrôler au minimum :
- l’ensemble des fichiers PrestaShop ;
- les fichiers récemment créés ou modifiés ;
- les modules ;
- le thème ;
- les répertoires d’upload ;
- les tâches cron ;
- les fichiers
.htaccesset.user.ini; - les comptes administrateurs ;
- les accès FTP, SFTP et SSH ;
- les mots de passe ;
- les logs HTTP ;
- la base de données ;
- les éventuelles modifications du tunnel de paiement.
Pourquoi un WAF reste indispensable
Corriger AP Page Builder traite une vulnérabilité précise. Mais une boutique PrestaShop possède généralement de nombreux composants accessibles depuis Internet.
Une nouvelle vulnérabilité pourra demain être découverte dans PrestaShop, un module, le thème, une bibliothèque ou une API.
Un Web Application Firewall (WAF) constitue donc une couche de protection supplémentaire en filtrant de nombreuses requêtes suspectes avant qu’elles n’atteignent l’application.
Chez Phenix Info, cette approche est notamment mise en œuvre avec SmallGuard, notre WAF spécialisé pour PrestaShop.
Le bon ordre des priorités reste cependant le même : un WAF complète un correctif ; il ne remplace jamais une mise à jour de sécurité.
Pourquoi un scanner malware est tout aussi important
Un WAF cherche principalement à empêcher l’attaque d’atteindre l’application. Un scanner malware répond à une autre question :
« Est-ce qu’un attaquant est déjà passé ? »
C’est pourquoi ces deux protections sont complémentaires.
Notre Phenix Malware Scanner permet d’analyser beaucoup plus largement l’installation PrestaShop afin de rechercher des fichiers ou comportements suspects en dehors du seul répertoire AP Page Builder.
Corriger la porte d’entrée ne garantit pas qu’elle n’ait jamais été exploitée auparavant.
La sécurité PrestaShop doit fonctionner par couches
- Maintenir PrestaShop à jour.
Les nouvelles versions corrigent régulièrement des vulnérabilités et des bugs. - Maintenir les modules à jour.
C’est particulièrement important pour les modules disposant de contrôleurs ou points d’entrée accessibles depuis le front-office. - Appliquer un correctif lorsqu’une mise à niveau immédiate est impossible.
C’est précisément le rôle de Phenix AP PageBuilder Guard pour les anciennes branches prises en charge. - Ajouter un WAF.
Il permet de réduire l’exposition aux scans automatisés et à de nombreuses requêtes malveillantes. - Scanner régulièrement les fichiers.
Une attaque ayant réussi doit pouvoir être détectée rapidement. - Conserver et tester les sauvegardes.
Une sauvegarde doit pouvoir être restaurée en situation réelle. - Surveiller les logs.
Ils permettent parfois de retrouver les premières traces d’une tentative d’exploitation avant que ses conséquences deviennent visibles.
Que recommandons-nous aujourd’hui aux utilisateurs d’AP Page Builder ?
AP Page Builder 4.0.0 ou supérieur
Conservez le module à jour et appliquez les nouveaux correctifs publiés par l’éditeur. La dernière version de sécurité disponible doit rester la référence.
Ancienne version pouvant être mise à jour
Effectuez la mise à niveau, idéalement après validation sur un environnement de préproduction.
Ancienne version intégrée à un thème et impossible à mettre immédiatement à jour
Appliquez les correctifs officiels ou une mitigation adaptée. Phenix AP PageBuilder Guard a précisément été conçu pour ce scénario sur les branches historiques prises en charge.
Boutique ayant potentiellement déjà été compromise
Ne vous contentez pas d’appliquer le patch : réalisez également un audit complet des fichiers, accès, comptes, logs et de la base de données.
Conclusion : patcher la vulnérabilité, mais surtout protéger l’ensemble de la boutique
Les vulnérabilités découvertes dans AP Page Builder illustrent un problème courant dans l’écosystème e-commerce : un module peut fonctionner pendant des années, puis devenir une cible dès lors qu’une vulnérabilité est découverte et documentée.
La réponse doit être organisée :
- mettre à jour lorsque cela est possible ;
- appliquer une mitigation lorsque la migration nécessite du temps ;
- installer un WAF pour réduire l’exposition aux attaques ;
- surveiller les journaux ;
- scanner régulièrement les fichiers ;
- conserver des sauvegardes fiables et testées.
C’est dans cette logique que nous avons développé Phenix AP PageBuilder Guard.
Il ne prétend pas transformer une ancienne version d’AP Page Builder en version récente. Il ne remplace pas non plus un WAF ou un scanner malware complet.
Son rôle est volontairement précis : réduire la surface d’attaque des anciennes branches AP Page Builder en appliquant localement des contrôles correspondant aux vulnérabilités et correctifs publiquement documentés, tout en permettant aux boutiques qui ne peuvent pas encore migrer de sécuriser temporairement leur installation pendant la préparation d’une mise à niveau propre.
Sources et documents
PrestaShop
CVE et organismes de sécurité
- CVE-2022-22897 – National Vulnerability Database
- CVE-2022-44897 – National Vulnerability Database
- CVE-2023-3743 – National Vulnerability Database
- CVE-2024-6648 – INCIBE-CERT
- Path Traversal in AP Page Builder – INCIBE-CERT
- AP Page Builder – Friends Of Presta Security Advisory
