Le 21 octobre 2026, PHP a corrigé deux failles critiques surnommées « PHP2Shell » ; l’ANCS a publié un bulletin le jour même, et la STEG a suspendu son site le lendemain, par précaution. Si votre site fonctionne en PHP, deux questions comptent : qui doit installer le correctif, et comment vous en assurer. Faits arrêtés au 22 octobre au soir.

L’essentiel en cinq points

  • Le moteur PHP du serveur est en cause, pas WordPress ni PrestaShop : une mise à jour du CMS n’y change rien.
  • PHP a publié 8.2.35, 8.3.36, 8.4.27 et 8.5.12, mais un PHP réparé peut garder un numéro plus ancien, sur toutes les branches chez CloudLinux : seul l’hébergeur peut confirmer.
  • Le bulletin de l’ANCS ne cite que les branches 8.2 à 8.5 : un site en 7.4 ou en 8.1 est aussi concerné.
  • En mutualisé, l’hébergeur corrige PHP ; sur un VPS ou un dédié, c’est vous, ou votre infogérance.
  • Un pare-feu fait gagner du temps, il ne corrige rien.

Mon site est-il concerné ?

  • Oui, s’il fonctionne en PHP sur un mutualisé, un VPS ou un dédié : WordPress, WooCommerce, PrestaShop, Joomla, Drupal, Laravel ou code maison.
  • Ce n’est pas à vous de corriger s’il est sur une plateforme hébergée sans accès au serveur (Converty, Shopify, Wix, WordPress.com) : demandez-lui si elle a corrigé.
  • Vous ne savez pas ? La facture d’hébergement, ou l’agence qui a livré le site, vous le dira. Si personne ne sait qui administre le serveur, partez du principe qu’il n’est pas corrigé.

Ce que je fais aujourd’hui

Mon site est en hébergement mutualisé

Client NovaHoster en mutualisé ? Nos serveurs sont déjà corrigés (détail) : seules les étapes 3 et 4 vous concernent.

  1. Relevez la version de PHP du site (où la lire).
  2. Écrivez à l’hébergeur et gardez sa réponse datée : elle documente vos précautions. Par exemple : « Le PHP de [adresse du site] contient-il le correctif de CVE-2026-109618 et CVE-2026-109619 ? Merci de m’indiquer sa version exacte, la date de la correction et du redémarrage des processus PHP, et si les journaux depuis le 17 octobre sont conservés. »
  3. Mettez quand même à jour CMS, thème et extensions, contre leurs propres failles.
  4. Guettez les signes d’intrusion.

Sans réponse rapide, si le site enregistre des clients ou des commandes, envisagez le mode maintenance (faut-il couper son site).

J’administre un VPS ou un serveur dédié

Mettez à jour les paquets PHP, redémarrez tous les processus PHP et vérifiez le correctif ; si la mise à jour doit attendre, posez les mesures provisoires (partie réservée aux administrateurs).

Mon site est sur une plateforme hébergée

Rien à faire sur PHP : demandez à la plateforme si elle a corrigé.

Qui corrige quoi : l’hébergeur, le prestataire, vous

Qui installe le PHP corrigé dépend de votre formule :

Votre formuleQui installe le PHP corrigéCe qui reste à votre charge
Hébergement mutualiséL’hébergeurCMS à jour, confirmation écrite, choix d’une version corrigée
VPS ou dédié sans infogéranceVous, grâce à l’accès rootPaquets, redémarrage des processus PHP, journaux
VPS ou dédié avec infogéranceLe prestataire d’infogéranceLa compatibilité de votre application

Sur nos packs, sans accès root, votre site tourne sur l’une des versions de PHP que nous proposons ; selon notre guide de Plesk, la version de PHP fait partie des options qui dépendent du système, du rôle et de l’offre. Sur un serveur VPS, PHP vous revient, sauf avec notre infogérance de serveur, qui applique les correctifs du système et des services installés.

Chez NovaHoster. Au 22 octobre 2026, les versions de PHP de nos serveurs d’hébergement mutualisé ont reçu le correctif de ces deux failles : nos clients en mutualisé n’ont rien à faire côté PHP. Il leur reste à tenir à jour le CMS, le thème et les extensions. Sur un VPS ou un dédié sans infogérance, la mise à jour de PHP reste à faire par vous.

Pour une confirmation écrite sur votre site, comme le conseille PrestaShop, ouvrez une demande au support.

Vérifier sa version : le numéro ne dit pas tout

La version s’affiche en une minute : Santé du site (menu Outils, onglet Infos) dans WordPress, Paramètres avancés puis Informations dans PrestaShop, réglages d’hébergement du domaine dans Plesk.

Le numéro, lui, peut tromper : 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou au-delà est corrigé, mais un numéro plus ancien ne prouve rien.

  • Plesk garde 7.4.33, 8.0.30 et 8.1.34 : une compilation antérieure au 21 octobre 2026 est vulnérable, celle du 21 octobre corrigée (fiche de Plesk).
  • cPanel a reporté le correctif dans ses PHP 7.4, 8.0 et 8.1 sans changer de version (journal d’EasyApache 4).
  • CloudLinux a réparé toutes ses branches, de 5.2 à 8.5, sans toucher au numéro : un PHP 8.3 corrigé y affiche 8.3.35, un 8.5 corrigé 8.5.11 (fiche de vérification de CloudLinux).
  • Les distributions Linux font souvent de même, rappelle le communiqué de PrestaShop.

Un 8.1.34 ou un 8.3.35 peut donc être vulnérable ou corrigé.

WordPress et PrestaShop : deux cas très différents

WordPress, le cas simple

WordPress 7.0 et 7.1 acceptent PHP 7.4 à 8.5 (table de compatibilité), et WordPress.org recommande PHP 8.3 ou plus (exigences de WordPress) : un site à jour rejoint sans peine une branche corrigée, si ses extensions suivent. Essayez sur une copie, avec notre guide pour mettre à jour WordPress, ses thèmes et ses extensions.

PrestaShop, selon la version de la boutique

Chaque version n’accepte qu’une fourchette de PHP (DevDocs 1.7, DevDocs 8, DevDocs 9) :

PrestaShopPHP acceptéPHP réparé possible
1.6.1 à 1.7.7De 5.2 à 7.3 selon la versionChez CloudLinux ; offre payante TuxCare chez Plesk
1.7.87.1 à 7.47.4.33 réparé (Plesk, cPanel, CloudLinux)
8.0 à 8.27.2 à 8.18.1.34 réparé (Plesk, cPanel, CloudLinux)
9.08.1 à 8.48.2 à 8.4 corrigé
9.18.1 à 8.58.2 à 8.5 corrigé

Une boutique en PrestaShop 8 ou 1.7.8 n’a pas à migrer dans l’urgence : pour PrestaShop, la priorité est un PHP corrigé pour la version en place, et la mise à jour majeure « n’est pas un correctif d’urgence ». Planifiez-la quand même : PHP 8.1 n’a plus de nouvelles versions depuis fin 2025, et la 8.2 n’en aura plus après le 31 décembre 2026. Sur nos packs e-commerce PrestaShop, une deuxième base de données dès START permet de la préparer sur une copie.

Le bulletin de l’ANCS, et ce qu’il faut y ajouter

Le bulletin tunCERT/Vuln.2026-657 du 21 octobre cite les branches 8.2 à 8.5 et recommande de mettre PHP à jour. C’est exact, mais il faut y ajouter PHP 5, PHP 7, PHP 8.0 et PHP 8.1. Le projet PHP n’en publie plus de versions (calendrier de PHP), mais ces branches sont touchées : le CERT-FR les range parmi les systèmes affectés (alerte CERTFR-2026-ALE-014), et PHP a publié pour 7.4, 8.0 et 8.1 des correctifs en sources. Un site en 7.4 n’est pas hors de cause parce que le bulletin ne le nomme pas.

Le 28 septembre, le tunCERT/Vuln.2026-585 signalait déjà onze failles de PHP : un serveur qui ne l’a pas suivi cumule deux retards.

Pourquoi tant de sites tunisiens sont concernés

PHP fait tourner 76,8 % des sites en .tn dont le langage serveur est identifié (W3Techs, sites en .tn). Parmi leurs CMS identifiés, WordPress pèse 58,3 % et PrestaShop 9,9 %, environ quatorze fois sa part mondiale de 0,7 % (W3Techs, CMS en .tn ; W3Techs, PrestaShop). Le troisième, Converty (8,7 %), est une plateforme de boutiques clés en main : ses commerçants n’ont pas de PHP à corriger.

Nous n’avons trouvé aucune source publique sur les versions de PHP en Tunisie. Dans le monde, près d’un site PHP sur deux (48 %, notre calcul) tourne sur une branche antérieure à 8.2 (W3Techs, PHP et ses versions ; W3Techs, PHP 8), comme 35,8 % des installations WordPress (statistiques de WordPress.org) : leur correctif dépend de l’hébergeur.

Faut-il couper son site, comme la STEG ?

Selon Business News, la STEG a désactivé son site le 22 octobre jusqu’à ce que « les conditions de sécurité permettent sa remise en service », mesure qu’elle présente comme une précaution ; le journal précise que la coupure ne signifie pas, en elle-même, que le site a été attaqué. Le communiqué, tel que le rapporte la Radio nationale, invoque une faille « au niveau mondial » sans nommer PHP.

Le CERT-FR recommande d’« isoler les équipements affectés », puis de migrer vers une version maintenue et corrigée ; le NCSC britannique, d’envisager la coupure si l’on ne peut ni mettre à jour ni appliquer à temps les mesures provisoires ; l’éditeur Sansec la juge inutile pour une boutique. Notre lecture :

  • PHP corrigé et confirmé : pas de coupure ; cherchez des traces.
  • Correction attendue dans les heures qui viennent : demandez si les mesures provisoires sont posées.
  • Serveur sans administrateur, ou PHP sans version réparée : mode maintenance jusqu’à la correction. Une vitrine fermée coûte moins qu’une base de clients copiée.

Pour les structures publiques, la circulaire n° 5 du 2 septembre 2026 impose de traiter immédiatement les failles recensées et d’informer l’ANCS de tout incident, même potentiel ; elle ne parle pas de mise hors ligne.

Les mesures provisoires

Elles se posent sur le serveur, donc par l’hébergeur en mutualisé. Cloudflare a déployé des règles sur tous ses plans (billet de Cloudflare) ; CloudLinux en a publié pour Imunify360, présent sur nos packs, mais au 22 octobre aucune ne bloquait encore le chemin « mémoire » de CVE-2026-109618 (blog de CloudLinux). PHP prévient qu’« il n’existe pas de parade complète, la mise à jour est le seul choix sûr », ce que rappelle aussi notre guide pour renforcer la sécurité de son hébergement.

Chercher des traces depuis le 17 octobre

PHP2Shell regroupe CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 en CVSS 4.0 par PHP (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp) et 9,8 en CVSS 3.1 par la NVD américaine (fiche NVD). Le 17 octobre, un pot de miel d’Amazon a capté une première tentative d’exploitation : AWS conseille de faire partir l’enquête de cette date (rapport d’AWS).

L’exploitation réelle reste discutée (aucun exploit fonctionnel vu par la PHP Foundation à la publication, des preuves de concept pour certains déploiements selon le CERT-FR le 22), mais un PHP corrigé n’expulse pas un intrus déjà entré. On cherche :

  • dans les journaux d’accès, des POST de formulaire contenant PHP_SESSION_UPLOAD_PROGRESS, et les six adresses IP publiées par AWS, à rechercher plutôt qu’à bloquer ;
  • des requêtes multipart suivies d’erreurs memory_limit, des erreurs 500 répétées, des cookies PHPSESSID renvoyés anormalement grands ou malformés, des processus PHP relancés sans raison (Wiz) ;
  • côté site : comptes d’administration inconnus, fichiers récents inattendus, tâches planifiées ou redirections ajoutées.

Sur nos packs, consultez les journaux de l’espace client et demandez au support de préserver ceux du serveur, à la conservation limitée. Méthode : nos guides pour lire les journaux d’une application et traiter une alerte Imunify360.

Site compromis : ce que la loi tunisienne demande

Notifier une violation de données sous 72 heures est une règle du RGPD européen (règles de la CNIL), pas du droit tunisien. La loi organique n° 2004-63 n’impose aucune notification, mais oblige à « prendre toutes les précautions nécessaires pour assurer la sécurité de ces données » (article 18, précisé par l’article 19), sous peine de trois mois d’emprisonnement et de 1 000 dinars d’amende (article 94, texte de la loi). Sa réforme était encore en commission à l’ARP en février 2026, dernier état public trouvé (WebManagerCenter).

Le décret-loi n° 2023-17 va plus loin pour les organismes de son article 6, dont les hébergeurs et « les entreprises qui procèdent au traitement automatisé des données personnelles de leurs usagers » en ligne : ils doivent informer « immédiatement » le point de contact national ou un centre de réponse aux urgences cybernétiques des incidents et des attaques (article 20). Qu’une boutique en ligne en fasse partie n’est pas tranché par le texte : posez la question à l’ANCS.

Qui prévenir

  • Le tunCERT de l’ANCS : déclaration d’incident par courriel à incident@ancs.tn ; centre d’appel au 71 843 200, GSM au 98 707 284 ; assistance gratuite, avec une équipe d’intervention pour les professionnels (page du tunCERT, contacts de l’ANCS).
  • La police ou la garde nationale, pour porter plainte (notre article sur les arnaques en ligne en Tunisie).

Remettre le site en état : quatre erreurs à éviter

  • Nettoyer avant d’avoir copié : prévenez le tunCERT, puis copiez journaux et fichiers tels quels, pour l’enquête et une éventuelle plainte.
  • Restaurer sur un PHP vulnérable : faites d’abord confirmer la correction.
  • Restaurer une copie sans l’examiner : une sauvegarde postérieure au 17 octobre peut contenir l’intrus. Sur nos packs, vous sauvegardez et restaurez vous-même depuis Plesk ; l’option de sauvegarde externalisée quotidienne garde en plus 30 jours de copies (sauvegarder et restaurer un site).
  • Ne renouveler qu’une partie des accès : CMS, base de données, FTP, SSH, mais aussi les clés d’API du paiement en ligne (ClicToPay, Flouci…), de la livraison ou des SMS.

Pour l’administrateur d’un VPS ou d’un serveur dédié

Cette partie s’adresse à qui a l’accès root ; en mutualisé, ces réglages relèvent de l’hébergeur.

Mettre à jour, redémarrer, vérifier. Installez les paquets PHP corrigés, puis redémarrez tous les processus PHP (pools PHP-FPM, Apache s’il charge mod_php, et pkill lsphp sous LiteSpeed). Ensuite :

  • Plesk : /opt/plesk/php/8.1/bin/php -v (de même pour 7.4 et 8.0) doit indiquer built: Oct 21 2026 ; le panneau, Obsidian 18.0.81 Update 4 ou 18.0.80 Update 11.
  • CloudLinux : rpm -q --changelog alt-php83-common | grep -E 'CVE-2026-(109618|109619)' doit répondre, pour chaque paquet installé. Révisions réparées : alt-php74 7.4.33-81, alt-php80 8.0.30-69, alt-php81 8.1.34-39, alt-php82 8.2.34-7, alt-php83 8.3.35-6, alt-php84 8.4.26-5, alt-php85 8.5.11-5 ; alt-php44 et alt-php51 n’ont pas de correctif.

Si la mise à jour doit attendre, l’avis de sécurité de PHP liste des mesures qui réduisent l’exposition sans rendre l’installation sûre :

  • CVE-2026-109618 : memory_limit=-1, imposé par php_admin_value (pool FPM ou Apache) sans qu’aucun réglage ne remette de limite, et seulement avec une limite de mémoire du conteneur ou du cgroup, idéalement restreinte au processus fautif, faute de quoi un processus peut épuiser le serveur. Jamais RLIMIT_AS ni RLIMIT_DATA, qui peuvent provoquer l’échec d’allocation vulnérable. Même ainsi, un échec d’allocation du système peut encore atteindre ce chemin. Plus post_max_size à 8M (32M avec envoi de fichiers), upload_max_filesize en dessous, et des limites de taille et de structure des requêtes au serveur web ou au proxy.
  • CVE-2026-109619 : session.upload_progress.enabled=0 dans le php.ini, le pool FPM ou la configuration du serveur (ni ini_set() ni .user.ini), puis redémarrage de tous les processus ; cela bloque les chemins confirmés par les sessions, pas les autres variantes.
  • PHP 8.5 : fatal_error_backtraces=0, puis redémarrage ; cela ne bloque que le chemin confirmé des erreurs fatales.

Sources

Pages consultées le 22 octobre 2026.