PHP2Shell : ce que la faille critique de PHP signifie pour votre site web – et ce qu'il faut faire maintenant

• Quoi : deux failles critiques dans PHP lui-même (CVE-2026-109618 et CVE-2026-109619), toutes deux notées CVSS v4.0 9,2 par le projet PHP. Elles peuvent permettre une exécution de code à distance sans authentification.
• Qui : selon le projet PHP, toutes les installations PHP qui traitent des requêtes web – PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé pour mod_php.
• Correctif : passer à PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Les mesures provisoires ne font que réduire certains vecteurs d'attaque – selon le projet PHP, seule la mise à jour règle complètement le problème.
• Anciennes versions : PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet PHP. L'équipe de sécurité de PHP a fourni des rétroportages minimaux du code source pour 7.4, 8.0 et 8.1 ; certaines distributions et certains fournisseurs de support étendu (LTS) proposent leurs propres paquets.
• Ce que cela signifie pour vous : si votre site tourne sous WordPress, Joomla, une solution e-commerce ou tout autre logiciel en PHP, demandez dès aujourd'hui à votre hébergeur quelle version de PHP est utilisée et si le correctif est installé. Vous pouvez aussi le vérifier vous-même : on vous explique comment plus bas.

PHP est le langage de programmation qu'utilisent de très nombreux sites pour générer leurs pages côté serveur : des systèmes de gestion de contenu comme WordPress, Joomla et TYPO3, des boutiques en ligne comme WooCommerce, Shopware ou Magento, des forums, des logiciels de réservation ou d'espace membres. Quand un visiteur ouvre une telle page, un processus PHP traite sa requête sur le serveur.

C'est précisément là que se trouvent les deux failles. L'avis de sécurité du projet PHP du 21 octobre 2026 les décrit ainsi :

• CVE-2026-109618 – « RCE via OOM corruption » : la gestion d'un manque de mémoire (out of memory) peut interrompre PHP alors que des données internes de la requête ne sont que partiellement initialisées. Le nettoyage de la requête risque ensuite de traiter ces données invalides comme si elles étaient valides.
• CVE-2026-109619 – « RCE via stale global state » : un état interne propre à une requête peut subsister alors que la mémoire qui le porte a déjà été libérée. Une requête suivante, traitée par le même processus (worker), peut alors utiliser cet état périmé avant que l'initialisation normale ne le remette à zéro.

« RCE » signifie remote code execution, exécution de code à distance : quiconque exploite la faille peut lancer ses propres commandes sur le serveur, avec les droits du serveur web. D'où le nom PHP2Shell – une simple requête web se transforme en accès à la ligne de commande du serveur. Le projet PHP indique que, pour mod_php, une exploitation a été démontrée dans laquelle une requête non authentifiée peut déclencher l'attaque avant même que le code de l'application ne s'exécute. Avoir WordPress, ses extensions ou sa boutique parfaitement à jour ne suffit donc pas : la faiblesse se situe un niveau en dessous, dans PHP lui-même.

Dans son annonce préalable du 20 octobre 2026, le projet PHP a attribué aux deux failles la note CVSS v4.0 de 9,2. L'échelle va jusqu'à 10 ; à partir de 9, une faille est considérée comme « critique ».

Selon le projet PHP, toutes les installations PHP qui traitent des requêtes web sont exposées. Sont citées explicitement :

• Apache avec mod_php – la configuration où le projet PHP voit le risque le plus élevé,
• PHP-FPM (la configuration courante derrière nginx ou Apache),
• php-cgi, FrankenPHP et LiteSpeed.

Quelles versions sont sûres ?

Important : les distributions Linux intègrent souvent les correctifs de sécurité dans leurs propres paquets sans passer le numéro de version à 8.x.y. Selon le projet PHP, les distributions et les fournisseurs LTS ont reçu les correctifs à l'avance. Un numéro « ancien » sur un serveur Debian, Ubuntu, Red Hat ou AlmaLinux peut donc tout de même être protégé – seul votre hébergeur ou votre équipe informatique peut le confirmer.

Ce que cela signifie pour une entreprise type

• WordPress, Joomla, TYPO3, Drupal : fonctionnent avec PHP. Un CMS à jour ne vous protège pas ici – ce qui compte, c'est la version de PHP sur le serveur.
• WooCommerce, Shopware, Magento/Adobe Commerce, PrestaShop : également en PHP. Une boutique gère des données clients et des paiements – il faut agir particulièrement vite.
• Hébergement mutualisé : l'hébergeur applique généralement les mises à jour de PHP de façon centralisée. Mais beaucoup d'offres vous laissent choisir vous-même la version de PHP : si une ancienne version comme 7.4 ou 8.1 est sélectionnée, vous y restez tant que vous ne changez pas.
• Serveur dédié ou VPS : c'est à vous (ou à votre agence) d'agir : mettre à jour les paquets et redémarrer tous les processus PHP.
• Outils de création de site sans PHP : les services qui livrent des pages statiques ou reposent sur une autre technologie ne sont pas concernés par cette faille précise. En cas de doute, interrogez le fournisseur.

Chronologie

• Août/septembre 2026 : plusieurs équipes découvrent les failles indépendamment les unes des autres. Selon la PHP Foundation, les premiers indices sont venus d'un développeur du cœur de PHP, suivis de signalements de Calif et d'OpenAI (11 août) puis de Wiz (24 août). Wiz date sa découverte au 19 août.
• 20 octobre : le projet PHP annonce une mise à jour de sécurité critique, prévue le 21 octobre à 14 h UTC, avec une note CVSS v4.0 de 9,2 pour les deux failles. Le même jour, selon la PHP Foundation, les numéros CVE circulent avec une mauvaise heure et une note erronée de 10,0 ; le soir, une vidéo de démonstration d'attaque est publiée par erreur.
• 21 octobre, tôt le matin : selon la PHP Foundation, un fournisseur d'images de conteneurs publie dès 7 h 41 UTC des paquets corrigés – plus de six heures avant la date coordonnée.
• 21 octobre, 14 h UTC (16 h à Paris) : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont publiées, avec les détails techniques.

Autorités et réactions

Les agences nationales de cybersécurité ont donné l'alerte dans toute l'Europe : en France le CERT-FR (ANSSI), en Allemagne le BSI avec un avis de criticité 3/orange (« des mesures doivent être prises sans délai »), en Autriche le CERT.at, au Royaume-Uni le NCSC, en Espagne l'INCIBE-CERT et en Italie le CSIRT Italia. Le BSI et le NCSC recommandent de mettre temporairement les systèmes hors ligne si ni la mise à jour ni une mesure provisoire ne sont possibles.

C'est exactement ce qu'ont fait de nombreuses organisations. En France, à la demande de l'ANSSI, le ministère de l'Intérieur a placé notamment les sites des préfectures en maintenance préventive (actu17). En Autriche, selon derStandard, l'université de Vienne, la TU Wien, le journal NÖN et Caritas se sont mis hors ligne par précaution ; en Allemagne, selon la Deutschlandfunk, la ville de Mayence a coupé plusieurs services en ligne et son portail web. Aux Pays-Bas, MijnOverheid et DigiD ont notamment été touchés, selon igizmo.it citant la NOS.

La faille est-elle exploitée ? Les sources se contredisent

• Oui, des tentatives d'attaque : Amazon Web Services signale des tentatives sur ses propres honeypots dès le 17 octobre, puis d'autres à partir de l'aube du 21 octobre. L'entreprise de sécurité watchTowr a fait état le 21 octobre de tentatives d'exploitation actives visant les deux failles ; Datadog parle d'un balayage large et non ciblé. L'INCIBE-CERT écrit que des attaques avaient été signalées avant même la publication des mises à jour.
• Pas encore confirmé : la PHP Foundation indique que l'équipe de sécurité de PHP n'avait identifié aucun exploit fonctionnel au moment de la publication. Le BSI n'a pas pu vérifier les premiers signalements issus des réseaux sociaux. Au 22 octobre, aucune des deux CVE ne figure dans le catalogue des vulnérabilités activement exploitées de la CISA (KEV), l'agence américaine.

Notre lecture : des tentatives d'attaque sont documentées ; des compromissions réussies à grande échelle n'ont pas été confirmées publiquement à ce jour. Pour vous, cela ne change rien : les détails sont publics et, d'expérience, les scans massifs suivent rapidement. Traitez tout serveur PHP non corrigé comme s'il était déjà attaqué.

Combien de sites sont concernés ?

Il n'existe pas de chiffre exact. Dans son analyse, Wiz parle de « 70 % d'Internet » concernés. Selon The Hacker News, le 20 octobre, environ 884 000 serveurs accessibles depuis Internet affichaient PHP 8.1 ou une version antérieure dans leur bannière – des versions sans mise à jour officielle. Ces décomptes reposent sur les bannières des serveurs et ne disent pas si un serveur est réellement vulnérable.

Pas besoin d'être technicien pour savoir si votre site utilise PHP et quelle version tourne. Ces méthodes prennent en général quelques minutes :

1. Dans le tableau de bord WordPress : Outils → Santé du site → Infos, rubrique Serveur. La version de PHP y est indiquée.
2. Dans Joomla : Système → Informations système. La version de PHP y figure.
3. Dans l'espace client de votre hébergeur : les offres mutualisées proposent en général une rubrique du type « Configuration PHP » ou « Version PHP », où vous pouvez la consulter et la modifier.
4. Par e-mail à votre hébergeur : posez la question telle quelle : « Quelle version de PHP fait tourner mon site, et les correctifs pour CVE-2026-109618 et CVE-2026-109619 sont-ils installés ? » Demandez une réponse écrite.
5. Pour les équipes techniques : php -v sur le serveur affiche la version en ligne de commande, qui peut différer de celle qui traite les requêtes web. La référence fiable est la version réellement utilisée par le serveur web (par exemple via une page phpinfo créée brièvement puis supprimée aussitôt). Certains serveurs indiquent la version dans l'en-tête HTTP X-Powered-By ; son absence ne signifie pas que PHP n'est pas utilisé.

Règle simple : 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou supérieure signifie que la mise à jour officielle est installée. Un numéro inférieur n'est pas automatiquement synonyme de danger (voir les paquets des distributions plus haut) – dans ce cas, votre hébergeur doit confirmer que le correctif est inclus.

1. Contactez votre hébergeur ou votre agence et obtenez une confirmation écrite : version de PHP, correctif installé pour les deux CVE, tous les processus PHP redémarrés.
2. Vérifiez la version de PHP dans votre espace client et, si c'est vous qui la choisissez, passez à une branche maintenue (8.3, 8.4 ou 8.5). Contrôlez rapidement que votre thème et vos extensions fonctionnent toujours.
3. Faites une sauvegarde et téléchargez-la – fichiers et base de données, datée. Une sauvegarde conservée sur le même serveur ne suffit pas.
4. Mettez à jour le CMS, les thèmes et les extensions. Cela ne ferme pas PHP2Shell, mais cela ferme d'autres portes que les attaquants testent en ce moment.
5. Passez en revue les comptes administrateur : des utilisateurs que vous ne connaissez pas ? Supprimez-les et signalez-les.
6. Changez les mots de passe une fois la mise à jour installée : accès administrateur, FTP/SFTP, base de données, compte d'hébergement. Activez la double authentification partout où c'est possible.
7. Faites analyser les journaux (voir plus bas), surtout si le serveur était accessible entre la divulgation et la mise à jour.
8. Testez vos formulaires de contact et votre boutique une fois tout à jour, pour qu'aucune demande ne se perde.

Si vous avez mis votre site hors ligne par précaution, signalez-le sur vos canaux (fiche Google Business Profile, réseaux sociaux) avec une courte note indiquant comment vos clients peuvent vous joindre en attendant.

Le projet PHP liste des mesures provisoires pour les serveurs qui ne peuvent pas être mis à jour immédiatement – en soulignant qu'elles réduisent seulement l'exposition à certains vecteurs d'attaque et ne rendent pas une installation sûre. Elles relèvent de la personne qui administre le serveur, pas du propriétaire du site. En résumé :

• Contre CVE-2026-109618 : définir memory_limit=-1 de sorte que les applications ne puissent pas le modifier (par ex. php_admin_value) ; garder post_max_size bas (8M sans envoi de fichiers, 32M avec) et upload_max_filesize en dessous ; imposer au niveau du serveur web ou du proxy des limites sur la taille des requêtes, le nombre de champs, les parties multipart, le nombre d'en-têtes et la profondeur d'imbrication ; utiliser des limites de conteneur ou de cgroup comme filet de sécurité. À ne surtout pas utiliser : RLIMIT_AS ou RLIMIT_DATA.
• Contre CVE-2026-109619 : définir session.upload_progress.enabled=0 dans php.ini ou dans la configuration du pool et redémarrer chaque processus (pas via ini_set() ni .user.ini) ; sous PHP 8.5, définir aussi fatal_error_backtraces=0. Corriger les erreurs fatales et les dépassements de délai qu'un attaquant peut provoquer – se contenter de masquer les messages d'erreur ne sert à rien.

Tous les détails techniques se trouvent dans l'avis de sécurité sur php.net.

Une mise à jour installée referme la brèche – elle ne supprime pas ce qui a pu être déposé avant. Si votre serveur était accessible entre la divulgation et la mise à jour, faites-le examiner. Les signaux d'alerte généraux les plus courants après la compromission d'un serveur :

• des fichiers PHP nouveaux ou modifiés dans les dossiers d'upload ou de cache, que personne n'a créés,
• des comptes administrateur inconnus dans le CMS ou de nouveaux utilisateurs sur le serveur,
• de nombreuses requêtes interrompues ou erreurs de mémoire dans les journaux de PHP ou du serveur web, en particulier des requêtes POST très volumineuses ou à la structure étrange,
• des connexions sortantes ou de nouvelles tâches planifiées (cron jobs) que personne n'a configurées,
• des redirections vers des sites inconnus, des pages de spam sous votre domaine dans Google, des avertissements du navigateur.

Traces spécifiques à PHP2Shell publiées par des entreprises de sécurité (pour la personne qui analyse vos journaux) : Amazon Web Services signale la chaîne PHP_SESSION_UPLOAD_PROGRESS dans des envois de formulaires POST et recommande d'examiner les journaux à partir du 17 octobre. Datadog cite des messages comme « Allowed memory size … exhausted … Unknown on line 0 », des processus enfants d'Apache qui plantent avec « Segmentation fault » et des processus du serveur web qui lancent un shell (sh -c). Wiz conseille de surveiller les requêtes multipart inhabituelles suivies d'erreurs de limite de mémoire ou de réponses HTTP 500 répétées.

Si vous trouvez l'un de ces indices : mettez le site hors ligne, faites appel à des spécialistes, changez vos identifiants uniquement depuis un système sain et – si des données personnelles peuvent être concernées – vérifiez votre obligation de notification selon l'article 33 du RGPD (72 heures après en avoir pris connaissance).

Beaucoup nous posent la question au sujet des sites réalisés avec mekyn. La réponse est simple : les sites créés et livrés par mekyn sont servis sous forme de pages statiques, prêtes à l'emploi. Aucun PHP n'y tourne. La plateforme qui les accompagne – tableau de bord, formulaires, réservation – fonctionne avec Node.js. PHP2Shell ne concerne donc pas ces sites.

C'est un choix de conception, pas un coup de chance : une page livrée de façon statique n'exécute aucune logique de programme sur le serveur web à chaque visite. Moins de pièces mobiles, c'est une surface d'attaque plus réduite – et, en prime, des temps de chargement rapides. Les mises à jour de la plateforme sont appliquées de manière centralisée ; vous n'avez rien à faire.

Si votre site actuel tourne sous PHP et qu'après cette semaine vous en avez assez des mises à jour serveur, de l'entretien des extensions et des e-mails d'urgence : mekyn reprend le contenu de votre site existant et en fait une présence moderne, avec visibilité sur Google, canaux de contact et réservation. D'ici là, une chose compte : appliquez la checklist ci-dessus – votre site actuel doit être sûr dès aujourd'hui.