Mercredi 21 octobre 2026, le projet PHP a livré des versions de sécurité hors calendrier pour corriger deux vulnérabilités notées critiques, CVE-2026-109618 et CVE-2026-109619, que la presse spécialisée appelle « PHP2Shell ». Le jour même, l’Agence nationale de la cybersécurité (ANCS) a diffusé son avis aux organisations tunisiennes, sous la référence tunCERT/Vuln.2026-657. Le risque annoncé : l’exécution de code à distance, c’est-à-dire la prise de contrôle du serveur qui héberge un site, par quelqu’un qui n’a aucun compte dessus.
L’essentiel en cinq points
- Le problème est dans le moteur PHP, sous le site : une mise à jour de WordPress, de PrestaShop ou des extensions ne le règle pas.
- Les versions sûres de PHP sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12, ou toute version publiée après elles dans la même branche.
- Les branches 8.1, 8.0, 7.x et 5.x ne sont plus maintenues par le projet PHP : elles ne recevront pas de version corrigée officielle.
- Une boutique PrestaShop 1.7 ou 8 ne peut fonctionner avec aucune des versions sûres.
- Des preuves de concept circulent depuis le 21 octobre : les robots qui scannent le web ne trient pas les sites par taille.
Ce que disent l’ANCS et le CERT-FR
L’avis de l’ANCS classe les impacts en quatre catégories : exécution de code arbitraire, déni de service, perte d’intégrité et perte de confidentialité. Sa recommandation tient en une ligne : installer PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Il renvoie aux mesures de contournement publiées par PHP pour qui ne peut pas mettre à jour tout de suite.
Le CERT-FR, son homologue français, va plus loin pour les serveurs restés sur une branche abandonnée : les isoler, puis les migrer vers une version maintenue. Il signale aussi, depuis le 22 octobre, l’existence de preuves de concept pour certaines configurations.
Pourquoi l’alerte est sérieuse
Les deux failles touchent la gestion de la mémoire et le traitement des erreurs, deux mécanismes que PHP sollicite à chaque visite. Le projet PHP a démontré l’attaque sur Apache avec mod_php avant même que le code du site ne s’exécute, et l’a confirmée sur PHP-FPM en passant par le code des applications. La PHP Foundation retient une note de gravité de 9,2 sur 10. Sont concernés PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed : en pratique, toutes les formules d’hébergement courantes.
Un serveur sous contrôle d’un attaquant expose les données des clients et des commandes, les accès aux plateformes de paiement et d’e-mailing, et la réputation du domaine. Des pages de spam glissées dans le site font reculer le référencement pendant des semaines, et un site signalé comme dangereux par les navigateurs perd ses visiteurs du jour au lendemain.
WordPress : la mise à niveau la plus courante
WordPress 6.9 et les versions suivantes acceptent PHP 8.2 à 8.5. Pour un site entretenu, le passage à 8.2.35 ou plus se fait le plus souvent sans difficulté. Les risques viennent d’ailleurs : un thème acheté il y a des années et jamais mis à jour, une extension abandonnée, un développement spécifique écrit pour PHP 7. D’où l’intérêt d’un essai sur une copie du site avant de basculer la production.
PrestaShop 1.7 et 8 : une migration à planifier
La documentation officielle de PrestaShop fixe les limites de chaque version :
- PrestaShop 1.7.8 : PHP 7.1 à 7.4 ;
- PrestaShop 8.0 à 8.2 : PHP 7.2 à 8.1 ;
- PrestaShop 9.0 : PHP 8.1 à 8.4, et 9.1 jusqu’à PHP 8.5.
Une boutique encore en 1.7 ou en 8 ne peut donc passer sur aucune version sûre de PHP. Trois chantiers vont alors ensemble. D’abord, savoir si l’hébergeur a reçu le correctif rétroporté : le projet PHP l’a fourni sous forme de code source pour les branches 7.4, 8.0 et 8.1, et certains distributeurs Linux l’intègrent à leurs paquets. Ensuite, réduire l’exposition avec les mesures provisoires publiées par PHP et le CERT-FR. Enfin, migrer vers PrestaShop 9, sur PHP 8.2 ou plus.
Trouver la version de PHP de votre site
- WordPress : menu Outils, Santé du site, onglet Infos, section Serveur.
- PrestaShop : menu Paramètres avancés, page Informations.
- Dans tous les cas : le tableau de bord de l’hébergement (cPanel, Plesk ou l’interface de votre fournisseur).
Comparez le numéro affiché aux versions sûres de la même branche : un 8.3.30 doit passer en 8.3.36, un 8.4.20 en 8.4.27. Une précision : certains hébergeurs appliquent le correctif de leur distribution Linux sans changer le numéro de version. Seule une confirmation écrite de leur part tranche alors la question.
Le plan d’action selon votre hébergement
- Vous êtes sur un hébergement partagé ou infogéré : écrivez à votre hébergeur aujourd’hui et demandez la version de PHP installée et la date d’application du correctif. Gardez sa réponse.
- Votre site tourne sur votre propre serveur ou un VPS : installez la version corrigée de votre branche, puis redémarrez PHP-FPM ou Apache pour qu’elle soit réellement chargée.
- Votre site dépend d’une branche abandonnée : posez les mesures provisoires, limitez l’accès au serveur, et fixez une date de migration plutôt que de la repousser.
- Une fois le serveur à jour : renouvelez les mots de passe des comptes d’administration et les clés d’API (paiement, transporteurs, e-mailing), puis passez en revue les comptes administrateurs et les fichiers modifiés récemment.
Notre accompagnement
Nous passons votre site en revue : version de PHP, CMS et extensions, signes d’intrusion, sauvegardes et hébergement. Vous recevez un rapport lisible, qui liste les corrections nécessaires et leur coût. Pour une boutique PrestaShop 1.7 ou 8, le rapport inclut la migration vers PrestaShop 9, que notre équipe PrestaShop conduit de bout en bout.
Pour que la prochaine alerte soit traitée sans que vous ayez à y penser, nos packs de maintenance couvrent les mises à jour du CMS, des extensions et du thème, les sauvegardes et une vérification de sécurité, sous WordPress comme sous PrestaShop ou toute autre technologie, à partir d’environ 54 TND HT par mois sur deux ans. Pour un audit, contactez-nous ou appelez le +216 70 284 284.
Pour aller plus loin : pourquoi le site d’une PME tunisienne attire les attaques, et comment le protéger.
