En bref : « Black October » est un surnom non officiel, donné par une partie de la presse spécialisée aux failles et incidents divulgués du 19 au 22 octobre 2026. Au centre : PHP2Shell, deux vulnérabilités critiques de PHP corrigées le 21 octobre, qui ont conduit de nombreux sites publics à se mettre en maintenance par précaution. Les leçons pour une PME : connaître ses services exposés (site web compris), appliquer les correctifs et vérifier qu’ils le sont vraiment, garder une sauvegarde hors ligne, protéger les comptes par la double authentification et préparer la continuité d’activité.
Un surnom, pas une appellation officielle
Le terme « Black October » circule sur les réseaux sociaux et dans la presse spécialisée anglophone. Ce n’est ni un nom donné par l’ANSSI, ni un nom utilisé par le CERT-FR, et son périmètre varie selon les auteurs. Le noyau commun comprend la faille PHP2Shell, la compromission de clés d’une autorité de certification et plusieurs attaques visant la chaîne d’approvisionnement logicielle.
Le même mercredi 21 octobre, une panne du réseau mobile d’Orange, de la fin de matinée à la soirée, a ajouté à la confusion ; Orange l’attribue à la défaillance d’un équipement de son cœur de réseau mobile et a précisé qu’elle n’avait aucun lien avec les failles PHP (ses enseignements pour la téléphonie sont détaillés dans cet article d’APE Telecom).
PHP2Shell : ce qui s’est passé
Deux failles critiques, un correctif annoncé à l’avance
Le 20 octobre, php.net a annoncé une version de sécurité critique pour le lendemain ; des détails ont fuité avant la divulgation coordonnée. Les correctifs ont été publiés le 21 octobre vers 16 h, heure de Paris : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le CERT-FR a publié le jour même l’alerte CERTFR-2026-ALE-014, mise à jour le 22 octobre.
Les deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, permettent une exécution de code à distance. php.net leur attribue une note CVSS v4.0 de 9,2 ; d’autres organismes donnent, selon leur grille, des notes de 8,1 à 9,8.
Qui est concerné ?
Selon php.net, toutes les installations PHP qui servent des requêtes web, quel que soit le mode d’exécution (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed), le risque étant jugé le plus élevé avec mod_php. Le CERT-FR liste comme affectées toutes les versions 5.x, 7.x, 8.0 et 8.1, ainsi que les branches 8.2 à 8.5 antérieures aux versions corrigées. Aucun correctif officiel n’existe pour PHP 8.1 et les versions plus anciennes, qui ne sont plus maintenues : la consigne est de les isoler, puis de migrer.
php.net est clair : il n’existe pas de parade complète, et la mise à jour est le seul choix sûr. Le CERT-FR mentionne des contournements, qu’il présente comme « non qualifiés », qui ne servent qu’à patienter jusqu’à la mise à jour.
Y a-t-il eu des attaques ?
Les sources divergent. Des tentatives d’exploitation massives ont été observées, des preuves de concept sont publiques, et une exploitation réussie a été démontrée sur certaines configurations, notamment Apache mod_php. Rapid7 souligne toutefois que ces preuves de concept ne fonctionnent que sur des combinaisons précises de système, de version et de serveur. À ce stade, aucun bilan public de compromissions n’a été publié.
Des sites publics mis en maintenance par précaution
Le 21 octobre, le ministère de l’Intérieur a indiqué avoir placé en maintenance préventive l’ensemble de ses sites exposés, « à la demande de l’Anssi ». Les sites de nombreuses préfectures, dont celle du Rhône, ont été temporairement mis hors ligne. D’autres sites publics ont été mis en maintenance le même jour ou les jours suivants, sans que tous aient officiellement relié cette décision à PHP ; le 23 octobre en fin de matinée, plusieurs n’étaient toujours pas revenus. Côté entreprises, le groupe Orange a suspendu temporairement certains de ses sites et applications le temps de déployer les correctifs.
Comme l’a résumé la Banque des Territoires, il ne s’agissait pas d’une cyberattaque mais d’une maintenance préventive. Couper volontairement un service exposé le temps de le corriger est une décision de gestion du risque. Encore faut-il savoir, en quelques heures, quels services sont exposés et qui peut les mettre à jour.
Certificats et outil piégé : les autres alertes
Des clés de certification recalculables. Mozilla et l’autorité de certification eMudhra ont rendu publique la compromission de huit clés privées de certificats intermédiaires, générées avec trop peu d’aléa et donc recalculables à partir des certificats publics. Le risque : l’émission de faux certificats HTTPS. Les principaux navigateurs les ont bloquées et aucun certificat frauduleux n’avait été repéré dans les journaux publics avant le blocage par Chrome. Restent plus exposés les logiciels hors navigateur (API, objets connectés) qui ne vérifient pas la révocation.
Un outil d’administration piégé à la source. Le 19 octobre, le client en ligne de commande d’OVHcloud a été compromis via le compte GitHub d’un contributeur : pendant environ une heure et demie, les binaires de plusieurs versions ont été remplacés par un voleur de secrets. OVHcloud a publié une version saine et demandé de renouveler les clés API, jetons et clés SSH des machines concernées, en précisant qu’aucun accès à ses datacenters n’avait eu lieu.
Les leçons pour une PME
1. Un inventaire qui inclut le site web et l’hébergement
On pense aux postes et aux serveurs, moins au site vitrine, à la boutique en ligne, à l’extranet ou au portail d’un logiciel métier. Ce sont pourtant des services exposés sur Internet, et beaucoup reposent sur PHP. Pour chacun, il faut savoir qui l’héberge, qui a les accès, quelle version de PHP il utilise et qui fait les mises à jour.
Attention à une confusion fréquente : mettre à jour le CMS et ses extensions reste indispensable, mais ne corrige pas une faille de PHP lui-même. Sur un hébergement mutualisé, c’est l’hébergeur qui met à jour PHP ; sur un serveur dédié, c’est vous ou votre prestataire. Pour un logiciel de gestion doté d’un portail web, demandez à l’éditeur ou à l’hébergeur si une brique PHP est exposée ; pour les logiciels métier, APE Logiciel, la société du groupe dédiée aux logiciels de gestion, peut vous orienter.
2. Vérifier le correctif, même si la version ne change pas
Le numéro de version ne suffit pas toujours. Pour notre propre site, notre hébergeur nous a confirmé que le correctif était intégré dans une révision 8.4.26-x de PHP, sans changement du numéro affiché. Ce mécanisme, le rétroportage, est documenté par l’éditeur CloudLinux : ses paquets corrigés contiennent le correctif des deux CVE « même si le numéro de version de PHP est inférieur » (traduction). CloudLinux cite l’exemple d’ea-php84 corrigé en 8.4.26-2 et non en 8.4.27, et recommande de chercher les identifiants CVE dans le journal des modifications du paquet :
rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'
Conséquence : un scanner qui ne compare que les numéros de version peut signaler à tort un site comme vulnérable. Depuis le 23 octobre, CloudLinux publie aussi des paquets aux numéros de php.net, et Plesk a publié des paquets recompilés. Le plus sûr reste de demander à l’hébergeur une confirmation écrite citant les CVE corrigées.
3. Des sauvegardes 3-2-1, dont une hors ligne
Le guide de l’ANSSI pour les TPE/PME donne la règle : « 3 copies de sauvegarde, sur 2 supports différents dont 1 hors ligne ». Il recommande aussi de chiffrer les données sauvegardées et de tester régulièrement la restauration. Cybermalveillance.gouv.fr conseille en complément de conserver les sauvegardes sur un site différent de celui qui héberge les données. Nous détaillons les options dans notre article sur la sauvegarde et le cloud pour les PME.
4. La double authentification sur les comptes sensibles
L’épisode OVHcloud le montre : un seul compte compromis suffit à piéger un outil utilisé par d’autres. Messagerie, administration, hébergement, nom de domaine : ces accès méritent une authentification multifacteur. Et quand un éditeur demande de renouveler des clés, il faut savoir où elles sont utilisées.
5. Un plan de continuité préparé à l’avance
Quand un site est coupé, même par précaution, il faut informer ses interlocuteurs et travailler en mode dégradé. Que fait votre entreprise si le site, la messagerie ou un logiciel est indisponible plusieurs jours ? L’ANSSI et Cybermalveillance.gouv.fr recommandent un plan de continuité et une cellule de crise préparés et exercés. Notre article sur le plan de reprise d’activité explique la démarche.
6. Savoir qui prévenir
En cas de doute ou d’incident : votre prestataire informatique, votre hébergeur, puis votre assureur si vous avez une assurance cyber. Cybermalveillance.gouv.fr publie des alertes (dont une sur PHP le 22 octobre) et oriente vers des prestataires référencés. Gardez ces contacts consultables même si votre informatique est à l’arrêt.
Et NIS2 ?
En France, la transposition de la directive NIS2 n’est pas achevée : selon les sources spécialisées à la date de rédaction, aucune loi n’a été promulguée ni publiée au Journal officiel, et aucun décret d’application n’est paru. Le projet de loi « Résilience », adopté par le Sénat en mars 2025, a été retiré de l’ordre du jour de l’Assemblée nationale le 6 octobre 2026. L’ANSSI invite néanmoins les futures entités concernées à s’engager dès à présent : les mesures ci-dessus vont dans ce sens.
Check-list
- Lister les services exposés sur Internet : site, boutique, extranet, portails, accès distants.
- Pour chacun, identifier l’hébergeur, le responsable des mises à jour et la version de PHP.
- Obtenir de l’hébergeur une confirmation écrite que CVE-2026-109618 et CVE-2026-109619 sont corrigées.
- Prévoir la migration de tout site encore en PHP 8.1 ou antérieur.
- Mettre à jour CMS, thème et extensions ; supprimer ceux qui ne servent plus.
- Vérifier les 3 copies, sur 2 supports, dont 1 hors ligne, et tester une restauration.
- Activer la double authentification sur la messagerie, l’administration, l’hébergement et le nom de domaine.
- Tenir à jour, hors ligne, la liste des personnes à prévenir en cas d’incident.
Questions fréquentes
« Black October » est-il un nom officiel ?
Non. C’est un surnom apparu sur les réseaux sociaux et dans la presse spécialisée anglophone pour les failles et incidents divulgués du 19 au 22 octobre 2026. Ni l’ANSSI ni le CERT-FR ne l’emploient, et son périmètre varie selon les auteurs.
Mon site internet est-il concerné par PHP2Shell ?
S’il fonctionne avec PHP, il est potentiellement concerné tant que PHP n’a pas été corrigé. Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35, ou des versions rétroportées par l’hébergeur. Les versions 8.1 et antérieures n’ont pas de correctif officiel.
Mon hébergeur affiche toujours PHP 8.4.26 : suis-je vulnérable ?
Pas forcément. Certains hébergeurs appliquent des correctifs rétroportés sans changer le numéro de version ; CloudLinux cite ea-php84 corrigé en 8.4.26-2. Demandez une confirmation écrite que les deux CVE sont corrigées.
Pourquoi des sites publics ont-ils été mis en maintenance ?
Par précaution. Le ministère de l’Intérieur a indiqué avoir mis ses sites exposés en maintenance à la demande de l’ANSSI, le temps d’appliquer les correctifs. Aucune compromission de site public français n’a été confirmée.
Qui contacter en cas de doute ou d’incident ?
Votre prestataire informatique et votre hébergeur, puis votre assureur si vous avez une assurance cyber. Cybermalveillance.gouv.fr oriente les entreprises vers des prestataires référencés.
Faire le point sur votre exposition
Vous ne savez pas quelle version de PHP fait tourner votre site, ni si vos sauvegardes résisteraient à un incident ? APE Conseil, prestataire informatique et cybersécurité à Rillieux-la-Pape, aide les TPE et PME de Lyon et de sa métropole à inventorier leurs services exposés, à vérifier les correctifs auprès des hébergeurs et à mettre en place sauvegardes, double authentification et plan de continuité. Contactez-nous ou appelez le 04 72 10 09 79.
Sources : php.net ; CERT-FR, alerte CERTFR-2026-ALE-014 ; Cybermalveillance.gouv.fr, alerte PHP ; Rapid7 ; Banque des Territoires ; D3 Security ; CloudLinux ; Plesk ; Mozilla ; eMudhra ; Next ; ANSSI/DGE, guide TPE/PME ; Cybermalveillance.gouv.fr, guide dirigeants ; Cybermois 2022 ; Myra Security.
