L'essentiel en bref
- PHP 8.2 ne reçoit plus aucune mise à jour de sécurité du projet PHP après le 31 décembre 2026. PHP 8.1 n'est plus supporté depuis le 31 décembre 2025 et PHP 8.3 suivra le 31 décembre 2027.
- PHP2Shell a montré en octobre 2026 ce que vaut une version en fin de vie (EOL) face à une faille critique : les correctifs officiels n'ont concerné que les versions 8.2 à 8.5. Pour PHP 7.4 à 8.1, le projet PHP n'a publié que des rétroportages du code source et les versions plus anciennes n'ont reçu aucun correctif.
- Selon une analyse de ShiftPress portant sur 54 743 sites web en Allemagne, en Autriche et en Suisse, 21 % des sites de communes affichant leur version de PHP tournaient encore sous PHP 8.1 ou une version antérieure. Pour les sites connus en .de, .at et .ch, la proportion atteignait 26 %.
- Dans un SMSI selon l'ISO 27001:2022, un logiciel obsolète concerne au moins les mesures A.8.8, A.5.9 et A.8.32 ainsi que le traitement des risques selon l'article 6.1.3. L'auditeur attend soit un plan de migration daté, soit une acceptation du risque documentée et limitée dans le temps.
- Si vous migrez maintenant, passez à PHP 8.4 ou 8.5. Une migration vers 8.3 ne fait que reporter le même problème de douze mois.
PHP 8.2 End of Life n'est pas une échéance réservée aux développeurs. À partir du 1er janvier 2027, le projet PHP ne corrige plus aucune faille de sécurité dans cette branche, pas même les failles critiques. Pour les entreprises qui exploitent un SMSI selon l'ISO 27001 ou qui se préparent à NIS2, chaque installation PHP 8.2 restante devient une question du prochain audit : le saviez-vous, comment avez-vous évalué le risque et qu'avez-vous décidé ?
Cet article s'adresse aux DSI, aux RSSI, aux responsables de la sécurité de l'information et aux équipes conformité des PME et des ETI. Il présente les versions de PHP concernées et leurs échéances, les options possibles et les preuves qu'un auditeur voudra voir. Notre article sur PHP2Shell et ses conséquences pour ISO 27001 et NIS2 détaille l'aspect technique de la dernière faille critique et les mesures immédiates qu'elle exigeait.
Ce que signifie concrètement PHP 8.2 End of Life
La fin de vie signifie que le projet PHP ne publie plus aucune mise à jour pour la branche concernée, ni pour les bugs ni pour les failles de sécurité. Chaque branche bénéficie de deux ans de support actif, puis de deux années supplémentaires limitées aux correctifs de sécurité critiques. Au bout de quatre ans, le support s'arrête.
PHP 8.2 est sorti le 8 décembre 2022. Son support actif a pris fin le 31 décembre 2024 et la branche ne reçoit depuis que des mises à jour de sécurité. Celles-ci s'arrêtent le 31 décembre 2026.
PHP2Shell, une répétition générale
PHP2Shell a montré ce que cela signifie en pratique. Le 21 octobre 2026, le projet PHP a publié des mises à jour d'urgence pour deux failles critiques de l'interpréteur, CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2 selon CVSS v4.0. Elles permettaient à un attaquant d'exécuter du code sur un serveur web sans authentification.
Le projet PHP n'a publié de versions officielles que pour les branches supportées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour PHP 7.4, 8.0 et 8.1, il s'est limité à des rétroportages minimaux du code source, sans version officielle. Les exploitants de ces versions devaient intégrer le correctif eux-mêmes ou attendre leur distribution Linux, leur hébergeur ou un fournisseur de support étendu. Les versions plus anciennes n'ont reçu aucun correctif.
Une idée reçue veut que quelqu'un finisse toujours par livrer un correctif quand une faille est vraiment critique. PHP2Shell a montré que, pour les versions en fin de vie, cela relève du hasard. Si une faille comparable touche PHP 8.2 en février 2027, il n'y aura pas de PHP 8.2.36.
Quelles versions de PHP perdent leur support, et quand
Le tableau ci-dessous reprend les dates de la liste officielle des versions supportées et de la liste des versions en fin de vie du projet PHP, à la date du 3 novembre 2026.
| Version de PHP | Fin des mises à jour de sécurité | Statut |
|---|---|---|
| PHP 8.5 | 31 décembre 2029 | Support actif |
| PHP 8.4 | 31 décembre 2028 | Support actif jusqu'au 31 décembre 2026, puis mises à jour de sécurité uniquement |
| PHP 8.3 | 31 décembre 2027 | Mises à jour de sécurité uniquement |
| PHP 8.2 | 31 décembre 2026 | Mises à jour de sécurité uniquement, fin de vie en fin d'année |
| PHP 8.1 | 31 décembre 2025 | Fin de vie |
| PHP 8.0 | 26 novembre 2023 | Fin de vie |
| PHP 7.4 | 28 novembre 2022 | Fin de vie |
Une conséquence échappe à beaucoup d'équipes : si vous quittez PHP 8.2 maintenant, ne vous arrêtez pas à 8.3. PHP 8.3 arrive en fin de vie dès le 31 décembre 2027 et tout l'exercice serait à refaire dans douze mois. PHP 8.4 est couvert jusqu'à fin 2028, PHP 8.5 jusqu'à fin 2029.
Les versions obsolètes restent courantes
ShiftPress a mesuré l'ampleur du problème dans les pays germanophones et le blog allemand Borns IT- und Windows-Blog en a publié les résultats le 3 novembre 2026. L'analyse a porté sur 54 743 sites web en Allemagne, en Autriche et en Suisse. Sur les 1 071 sites de communes qui affichent ouvertement leur version de PHP, 21 % indiquaient PHP 8.1 ou une version antérieure. Pour les sites connus en .de, .at et .ch, la proportion était de 26 %, et de 19 % pour les universités et les écoles.
Ces chiffres ne comptent que les versions déjà privées de support aujourd'hui. À partir du 1er janvier 2027, tous les sites sous PHP 8.2 viendront s'y ajouter.
Le numéro de version ne prouve rien
La deuxième idée reçue concerne le numéro de version. De nombreux hébergeurs et distributions Linux intègrent les correctifs de sécurité par rétroportage, sans modifier la version de PHP affichée. Un ancien numéro ne signifie donc pas automatiquement qu'un système est vulnérable. À l'inverse, un numéro qui semble récent ne prouve pas que tous les correctifs sont appliqués. Seuls le journal des modifications du paquet ou une confirmation écrite de l'hébergeur, qui cite les CVE corrigées, font foi.
Pourquoi un logiciel obsolète est un sujet d'audit
L'ISO 27001 n'interdit pas les logiciels obsolètes. Elle exige en revanche que vous sachiez où ils tournent, que vous évaluiez le risque et que vous preniez une décision documentée. C'est exactement à cette aune qu'un auditeur jugera une installation PHP 8.2 en 2027.
Les exigences pertinentes de l'ISO 27001:2022
A.8.8 Gestion des vulnérabilités techniques exige d'obtenir en temps utile des informations sur les vulnérabilités, d'évaluer votre exposition et de prendre les mesures appropriées. Un composant sans support de l'éditeur constitue une exposition connue et permanente, car plus personne n'y corrige les nouvelles failles.
A.5.9 Inventaire des informations et autres actifs associés est la condition de tout le reste. Sans inventaire qui recense les versions, vous ne savez pas quels systèmes sont concernés. Notre présentation des 93 mesures de l'annexe A de l'ISO 27001 explique comment ces mesures s'articulent.
A.8.32 Gestion des changements s'applique à la migration elle-même. Changer la version de l'environnement d'exécution d'un système de production est un changement, qui exige des tests, une validation et un plan de retour arrière.
L'article 6.1.3 Traitement des risques de sécurité de l'information régit le sort des systèmes que vous ne pouvez pas migrer à temps. La norme exige un plan de traitement des risques ainsi que l'approbation de ce plan et l'acceptation des risques résiduels par les propriétaires des risques.
Plan de migration ou acceptation du risque limitée dans le temps
Pour chaque installation PHP 8.2 au-delà du 31 décembre, seules deux situations résistent à un audit. Soit il existe un plan de migration avec des dates et des responsables nommés. Soit il existe une acceptation du risque documentée, limitée dans le temps, qui précise les mesures compensatoires et porte la signature du propriétaire du risque. Une acceptation sans date de fin n'est pas un traitement du risque mais une exception permanente, et les auditeurs la lisent ainsi.
Le cas qui mène régulièrement à une non-conformité est le troisième : le système ne figure ni dans l'inventaire ni dans le registre des risques. L'auditeur constate alors non seulement l'absence de mesure, mais aussi l'absence de preuve que le processus prévu par A.8.8 fonctionne.
NIS2 : la France n'a pas encore transposé la directive
En France, NIS2 n'est pas encore en vigueur. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, adopté par le Sénat le 12 mars 2025, attend toujours, au 3 novembre 2026, son examen en séance publique à l'Assemblée nationale. Les obligations françaises précises dépendront des textes de transposition.
Le fond est toutefois connu. L'article 21, paragraphe 2, de la directive NIS2 impose, au point e), la sécurité de l'acquisition, du développement et de la maintenance des systèmes, y compris le traitement et la divulgation des vulnérabilités, et au point i), la gestion des actifs. Le référentiel ReCyF de l'ANSSI, publié en version document de travail, rapproche déjà ces objectifs des mesures de l'ISO 27001. Les filiales allemandes qui entrent dans le champ de NIS2 y sont, elles, déjà soumises : la loi allemande BSIG reprend ces exigences à son § 30 depuis le 6 décembre 2025.
Notre guide des exigences NIS2 résume les autres obligations prévues par la directive.
Vos options : migration, support étendu ou isolement
Chaque système sous PHP 8.2 ou une version antérieure dispose de trois voies. Elles se distinguent par un point : résoudre le problème ou seulement gagner du temps.
| Option | Ce qu'elle apporte | Inconvénients | Adaptée à |
|---|---|---|---|
| Migration vers PHP 8.4 ou 8.5 | Supprime le problème. Mises à jour de sécurité officielles jusqu'à fin 2028 ou fin 2029 | Effort de test, incompatibilités possibles avec les frameworks, les extensions et les développements internes | Tous les systèmes dont l'application peut être testée dans les prochaines semaines |
| Support étendu via une distribution Linux ou un fournisseur LTS | Correctifs de sécurité rétroportés au-delà de la date officielle | La couverture dépend du fournisseur et ne vaut que pour ses paquets, le numéro de version ne change pas, la preuve est plus laborieuse | Systèmes dont la migration est fixée en 2027 |
| Isolement ou mise hors ligne | Réduit la surface d'attaque, par exemple avec un accès limité au VPN | Les vulnérabilités restent, seul l'accès se restreint. Pas une solution durable | Applications héritées sans voie de migration, interfaces d'administration d'équipements |
Migration
La migration est la seule option qui supprime le problème au lieu de le repousser. L'effort dépend moins de PHP lui-même que de ce qui tourne dessus. Un WordPress ou un Typo3 à jour, avec des extensions maintenues, fonctionne en général sous PHP 8.4 sans adaptation majeure. Les développements internes et les boutiques en ligne chargées d'extensions exigent en revanche de vrais tests.
Support étendu
Certaines distributions Linux maintiennent leurs paquets PHP plus longtemps que le projet PHP. Debian 12 livre PHP 8.2 et reçoit des mises à jour de sécurité jusqu'en 2028 grâce à Debian LTS. Des fournisseurs commerciaux proposent également un support étendu pour les anciennes versions de PHP.
Le revers : la protection ne couvre que les paquets issus de cette source précise. Si vous installez PHP depuis un dépôt tiers, le compilez vous-même ou l'embarquez dans votre propre image de conteneur, vous n'en bénéficiez pas. Pour l'audit, il vous faut en outre une preuve indiquant quel fournisseur assure le support et jusqu'à quand.
Isolement
L'isolement convient lorsqu'aucune migration n'est possible, par exemple pour une application héritée sans éditeur ou un équipement doté d'une interface d'administration en PHP. Pour les pare-feu, les NAS et les répartiteurs de charge, le correctif arrive de toute façon sous forme de mise à jour du micrologiciel par le fabricant. D'ici là, ces interfaces ne doivent pas être accessibles depuis Internet. Un pare-feu applicatif web peut bloquer des schémas d'attaque connus, mais il ne remplace pas un correctif.
Un plan de migration réaliste d'ici le 31 décembre
Début novembre, il reste un peu moins de huit semaines et beaucoup d'entreprises gèlent les changements dans la seconde quinzaine de décembre. Un plan réaliste boucle donc les migrations à la mi-décembre.
- Établir l'inventaire (avant le 13 novembre, exploitation informatique). Recensez chaque serveur, chaque image de conteneur et chaque offre d'hébergement qui exécute PHP, avec sa version et la source de ses mises à jour. N'oubliez pas les sites gérés par une agence ou un hébergeur, l'intranet, les anciennes pages de campagne et les environnements de préproduction. Ajoutez les équipements dotés d'une interface d'administration en PHP, comme les pare-feu, les NAS et les répartiteurs de charge.
- Évaluer et prioriser (avant le 20 novembre, RSSI avec la DSI). Affectez chaque système à l'une des trois options. Les systèmes exposés sur Internet et ceux qui traitent des données à caractère personnel passent en premier.
- Tester (du 23 novembre au 4 décembre, développement ou prestataire). Testez chaque application sous PHP 8.4 ou 8.5 dans un environnement de préproduction. Mettez d'abord à jour les frameworks, les extensions et les thèmes, car leurs anciennes versions sont souvent le véritable obstacle.
- Basculer (du 7 au 18 décembre, exploitation informatique). Traitez chaque bascule comme un changement au sens de A.8.32, avec validation, fenêtre d'intervention et plan de retour arrière.
- Couvrir le reste (avant le 31 décembre, propriétaire du risque). Tout système non migré fait l'objet d'une acceptation du risque limitée dans le temps, avec date de fin, mesures compensatoires et signature.
Prenons un exemple. Une ETI industrielle de 120 personnes recense sept systèmes PHP lors de l'inventaire. L'intranet et le portail clients tournent sur ses propres serveurs sous PHP 8.2, une agence gère deux sites marketing, auxquels s'ajoutent une boutique B2B, un NAS et un pare-feu doté d'une interface d'administration en PHP. L'intranet et le portail passent sous PHP 8.4 le 10 décembre. L'agence confirme par écrit la migration des sites. La boutique a besoin d'une extension qui ne sortira qu'en février : la DSI signe une acceptation du risque jusqu'au 31 mars 2027, avec un accès limité via un pare-feu applicatif web et un contrôle hebdomadaire. Le NAS et le pare-feu reçoivent des mises à jour du micrologiciel et leurs interfaces ne sont plus accessibles que depuis le réseau interne.
Ce qu'il faut documenter
Pour chaque système, consignez la version avant et après la bascule, la date, le ticket de changement avec sa validation, le résultat des tests et, le cas échéant, la confirmation de l'hébergeur ou de l'agence. Chaque exception exige une justification, une date de fin, des mesures compensatoires et la signature du propriétaire du risque.
Ce que les auditeurs veulent voir
Un auditeur n'attend pas de votre entreprise qu'elle n'ait aucun système hérité. Il attend que vous les connaissiez et que vous ayez pris une décision explicable. Lors du premier audit après le 31 décembre 2026, attendez-vous à ce que l'on vous demande les preuves suivantes :
- un inventaire avec les versions de PHP et leurs dates de fin de vie, y compris les sites hébergés et les équipements
- une entrée au registre des risques consacrée aux logiciels obsolètes, avec une évaluation et un propriétaire du risque
- le plan de migration avec dates et responsables, ainsi que les tickets de changement des bascules effectuées
- pour chaque exception, une acceptation du risque signée, limitée dans le temps et assortie de mesures compensatoires
- des preuves du niveau de correctifs, c'est-à-dire les journaux des modifications des paquets ou les confirmations des hébergeurs et prestataires
- un processus qui surveille désormais les dates de fin de vie, au lieu de les redécouvrir chaque année
Le dernier point est le plus important. PHP 8.3 suit dans 14 mois et les systèmes d'exploitation, bases de données et frameworks obéissent au même schéma. Un auditeur s'intéresse donc moins à la bascule elle-même qu'à la capacité de votre gestion des vulnérabilités à repérer seule la prochaine échéance.
Transformer vulnérabilités et délais en preuves d'audit avec Kertos et Aikido
La plupart des preuves de cette liste naissent dans les outils de vos équipes informatiques et de développement, pas dans le SMSI. Kertos comble cet écart grâce à l'intégration entre Aikido et Kertos. Aikido Security analyse le code, les environnements cloud et les applications en production à la recherche de vulnérabilités. Kertos lit ces résultats avec les délais de correction que vous avez fixés, vérifie chaque jour si un délai est dépassé et enregistre le résultat comme preuve pour les exigences de l'ISO 27001 relatives à la gestion des vulnérabilités, au développement sécurisé et aux tests de sécurité.
La connexion fonctionne en lecture seule et ne modifie rien dans Aikido. Elle se met à jour une fois par jour en arrière-plan ou à la demande. Pour votre audit, la réponse à la question de savoir si les vulnérabilités sont corrigées dans les délais est ainsi déjà disponible, sans collecte de captures d'écran.
L'inventaire et le registre des risques se gèrent dans la même plateforme. Les experts certifiés de Kertos vous aident à organiser votre gestion des vulnérabilités pour que la prochaine fin de vie ne devienne plus un projet à part. Pour voir à quoi cela ressemble dans votre environnement, réservez une démo.
Questions fréquentes
Quand le support de PHP 8.2 prend-il fin ?
Le projet PHP fournit des mises à jour de sécurité pour PHP 8.2 jusqu'au 31 décembre 2026. Le support actif, avec les corrections de bugs régulières, a pris fin dès le 31 décembre 2024. À partir du 1er janvier 2027, même les failles critiques de PHP 8.2 ne seront plus corrigées.
Que se passe-t-il si j'utilise encore PHP 8.2 après sa fin de vie ?
L'application continue de fonctionner, mais les nouvelles failles de sécurité restent ouvertes. Lors de PHP2Shell en octobre 2026, les versions en fin de vie n'ont reçu aucune version officielle, seulement des rétroportages du code source ou aucun correctif. Dans un SMSI selon l'ISO 27001, chaque système de ce type exige un plan de migration ou une acceptation du risque documentée et limitée dans le temps.
Vers quelle version de PHP migrer ?
Vers PHP 8.4 ou 8.5. PHP 8.4 reçoit des mises à jour de sécurité jusqu'au 31 décembre 2028, PHP 8.5 jusqu'au 31 décembre 2029. Une migration vers PHP 8.3 a peu d'intérêt, car son support s'arrête dès le 31 décembre 2027.
Un logiciel obsolète est-il une non-conformité ISO 27001 ?
Pas automatiquement. L'ISO 27001:2022 exige, au titre de A.8.8 et de l'article 6.1.3, que vous connaissiez, évaluiez et traitiez le risque. Un système en fin de vie assorti d'un plan de migration ou d'une acceptation du risque limitée dans le temps peut passer l'audit, alors qu'un système absent de l'inventaire comme du registre des risques mène régulièrement à une non-conformité.
Comment savoir si PHP est corrigé malgré un ancien numéro de version ?
Le numéro de version seul ne suffit pas, car les hébergeurs et les distributions Linux intègrent souvent les correctifs par rétroportage sans changer de numéro. Consultez le journal des modifications du paquet PHP de votre distribution ou demandez à votre hébergeur de confirmer par écrit quelles CVE sont corrigées. Cette confirmation sert aussi de preuve lors de l'audit.
