PHP : vingt-neuf ans à laisser la porte ouverte

PHP2Shell, cette semaine

Le 21 octobre 2026, le projet PHP a publié quatre versions d’un coup, 8.5.12, 8.4.27, 8.3.36 et 8.2.35, pour corriger deux failles critiques dans l’interpréteur lui-même¹. Pas dans WordPress. Pas dans une extension. Dans PHP.

Les deux sont notées 9,2 en CVSS 4.0. Les deux permettent l’exécution de code à distance sans connexion. Les chercheurs qui les ont trouvées en donnent la portée sans détour : « Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4. »²

L’avis du projet PHP dit le reste :

Et elle était utilisée avant que quiconque soit prévenu. Le réseau de pots de miel d’Amazon a enregistré une tentative le 17 octobre, quatre jours avant la divulgation³. watchTowr l’a vue dans la nature le 21, et des preuves de concept fonctionnelles étaient publiques quelques heures après le correctif⁴.

Les deux bugs sont des bugs de sûreté mémoire. L’un se trouve dans la façon dont l’interpréteur fait le ménage après avoir manqué de mémoire. L’autre est un use-after-free : la mémoire d’une requête est libérée puis relue, et la requête suivante sur le même worker peut la voir⁵⁶. Retenez ce second-là. Il reviendra plus loin.

Rien de tout cela n’est nouveau. C’est tout l’objet de cet article. PHP2Shell n’est pas un accident arrivé à un langage prudent. C’est la dernière page d’un dossier long de presque trente ans, et chaque chiffre qu’il contient est public.

Un seul processus détient tout

De novembre 2014 à avril 2017, j’ai été ingénieur Linux de troisième niveau sur la plateforme cloud et hébergement de Pulsant. Une partie du travail consistait à configurer des environnements PHP-FPM pour des clients e-commerce et à les régler pour qu’ils aillent vite.

Les intrusions via PHP étaient courantes. Pas de temps en temps. Courantes. Et elles se ramenaient à deux causes : un mauvais déploiement, et aucune séparation entre le front end et le back end.

Le langage fait de la seconde le comportement par défaut. Un site PHP typique, c’est un seul processus. Le template de page, la logique métier et le SQL vivent tous dans le même gestionnaire de requête, souvent dans le même fichier. Ce processus tourne sous un seul utilisateur du système. Il peut lire le mot de passe de la base, parce que ce mot de passe est dans un fichier à côté du code. Et il peut généralement écrire dans sa propre racine web, parce que c’est ainsi que fonctionnent les téléversements et les mises à jour.

Ce n’est pas mon opinion sur la façon dont PHP est déployé. C’est ce que PHP et WordPress documentent.

Relisez cette dernière ligne. L’éditeur vous dit à quoi ressemblerait le moindre privilège, puis vous dit de ne pas le faire, parce que les mises à jour modifient le schéma.

Comparez avec la version séparée. Le front end rend les pages et ne détient aucun secret. Le back end est un service distinct avec son propre utilisateur, une API étroite, et aucun droit d’écriture sur son propre code. Le compte de base de données peut faire ce dont le back end a besoin, et rien d’autre. Les recommandations de l’OWASP disent la même chose avec leurs mots : « The application’s backend database should be isolated from other servers », sur « a dedicated internal network segment »¹². Le propre manuel de PHP dit que les applications « should never connect to the database as its owner or a superuser »¹³.

Rien de tout cela n’est exotique. C’est à cela que ressemble un processus correct. La raison pour laquelle cela compte ici est simple. Dans le modèle séparé, un bug dans le front end donne à l’attaquant un front end. Dans le modèle PHP habituel, un bug n’importe où lui donne les templates, le code, les identifiants et les données, d’un seul coup.

PHP-FPM aide, et le guide d’installation de PHP le présente désormais comme la manière recommandée de faire tourner PHP sous Apache⁸. Ses pools peuvent démarrer des workers « with different uid/gid/chroot/environment »¹⁴. Mais un pool par site, c’est toujours un site par processus, qui détient tout ce que ce site possède. C’est un meilleur mur entre clients. Ce n’est pas un mur à l’intérieur de l’application.

Gardez cette image en tête dans chaque section qui suit. Chaque bug du dossier atterrit sur ce processus.

Vingt-neuf ans de CVE

La National Vulnerability Database liste chaque CVE déposée contre l’interpréteur PHP sous un seul identifiant de produit, cpe:2.3:a:php:php. Posez-lui la question, elle répond 757¹⁵.

Ce total ne concerne que l’interpréteur. Pas de WordPress, pas de Drupal, pas d’extensions, pas de frameworks. Seulement le programme qui exécute votre PHP.

Deux pics ressortent. Le premier est mars 2007, quand un ancien membre de l’équipe de sécurité de PHP a mené le Month of PHP Bugs, divulguant des failles dans le Zend Engine, le cœur de PHP et ses extensions « on a day by day basis »¹⁶. Il avait fondé la PHP Security Response Team, puis l’avait quittée, et avait dit pourquoi : « I dislike the ways bugs are handled »¹⁷. Quand le fondateur de l’équipe de sécurité d’un projet claque la porte et publie un bug par jour, cela vous dit comment les choses se passaient à l’intérieur.

Le second pic est 2016 : 120 CVE, dont 65 de corruption mémoire. Nous y reviendrons plus bas.

Le chiffre de la mémoire est un plancher, pas une estimation. NVD étiquette bon nombre d’anciens bugs « Other » plutôt qu’avec un type de faiblesse, y compris certains des use-after-free de la section suivante. Le vrai chiffre est plus élevé. J’utilise celui que je peux montrer.

Le moteur est écrit en C

C’est ici que l’argument de la sûreté mémoire doit être avancé avec soin, parce qu’un développeur PHP fera remarquer, à juste titre, que son code n’appelle jamais malloc. Les scripts PHP ne gèrent pas la mémoire à la main. Vous ne pouvez pas écrire un dépassement de tampon en PHP comme en C.

Vous n’en avez pas besoin. L’interpréteur qui exécute votre script est écrit en C, et ses extensions sont écrites en C. Chaque octet d’entrée non fiable que reçoit votre site, chaque en-tête, chaque téléversement, chaque champ de formulaire, chaque cookie, est analysé par ce C avant que votre code ne le voie. Quand ce C se trompe, votre PHP soigné ne compte pas. PHP2Shell l’a prouvé : l’avis dit que l’attaque peut se déclencher « before any application code runs »¹.

Le dossier montre ce que ce C a raté :

Ce sont les classes que les agences de sécurité ont en tête quand elles parlent de sûreté mémoire. En novembre 2022, la NSA a conseillé aux organisations « to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible »¹⁸. En décembre 2023, la CISA, avec le National Cyber Security Centre britannique parmi les coauteurs, a mis un chiffre dessus : « two-thirds of reported vulnerabilities in memory unsafe programming languages still relate to memory issues »¹⁹.

Aucun des deux documents ne nomme PHP. Ils n’en ont pas besoin. Ils nomment le langage dans lequel PHP est construit.

Le pire exemple récurrent est unserialize(), la fonction qui retransforme une chaîne stockée en objets PHP. Elle a eu la même classe de bug, au même endroit, plus d’une fois :

Le manuel PHP le sait. Sa page pour la fonction porte l’avertissement : « Do not pass untrusted user input to unserialize() regardless of the options value of allowed_classes. »²³ C’est un langage qui vous dit qu’une de ses propres fonctions intégrées n’est pas sûre à utiliser sur la chose que la plupart du code web manipule toute la journée.

Puis il y a PHP-FPM, le gestionnaire de processus que le propre guide d’installation de PHP recommande plutôt que mod_php. En octobre 2019, CVE-2019-11043 a montré que « in certain configurations of FPM setup it is possible to cause FPM module to write past allocated buffers … opening the possibility of remote code execution »²⁴. La configuration en question était une configuration nginx courante. Elle a été corrigée le 24 octobre 2019²⁵. La CISA l’a ensuite ajoutée à son catalogue des vulnérabilités connues comme exploitées, signalée comme utilisée dans des campagnes de rançongiciel²⁶.

La PHP Foundation a bien commandé un véritable audit de sécurité du code source de l’interpréteur, et c’est à mettre à son crédit. Les résultats, publiés le 10 avril 2025, ont relevé 27 problèmes, dont 17 avec des implications de sécurité²⁷. C’est une bonne pratique et cela devrait être normal. Ce sont aussi 17 de plus, dans l’audit d’une base de code qui avait déjà eu près de trois décennies de rapports de bugs publics.

Le langage a fait les mêmes erreurs un étage plus haut

Le C est une couche. Le langage au-dessus a fait le même genre d’erreur dans sa conception : faire confiance à des entrées auxquelles il n’avait aucune raison de faire confiance, et mettre des années à arrêter.

register_globals mérite sa propre ligne. Pendant des années, n’importe quel paramètre de la requête, ?admin=1 par exemple, devenait une variable de votre script, et si votre code testait $admin avant de l’avoir défini, l’attaquant l’avait défini pour vous. Le manuel PHP lui-même a qualifié sa désactivation de « the most controversial change in PHP »²⁹. Dix ans entre la désactivation par défaut et la disparition. Voilà combien de temps le projet a toléré une fonctionnalité qu’il savait dangereuse, parce que la retirer aurait cassé des sites.

Le cas phar suit le même schéma, une couche plus bas. En 2018, Sam Thomas a montré à Black Hat que de simples opérations sur un chemin phar:// désérialisaient des métadonnées fournies par l’attaquant, amenant le problème d’unserialize() jusque dans des fonctions que personne ne considérait comme dangereuses³⁶. PHP 8.0, fin 2020, a cessé de le faire automatiquement, « to fix potential security vulnerabilities due to object instantiation, autoloading, etc. »³⁴.

Ensuite, le type juggling. Le == de PHP convertit les types avant de comparer, si bien que des chaînes qui ressemblent à des nombres sont comparées comme des nombres. La RFC qui en a corrigé une partie dans PHP 8.0 l’a dit sans détour : « This results in many surprising comparison results, the most notable of which is that 0 == “foobar” returns true. »³⁵

Cette correction était réelle. Elle était aussi partielle. Voici la même vérification lancée dans les conteneurs officiels php:7.4-cli et php:8.5-cli, le second étant 8.5.12, la version corrigée pour PHP2Shell cette semaine, avec les deux sorties côte à côte :

$ php -r 'var_dump(0 == "foobar");'
bool(true)            # 7.4.33
bool(false)           # 8.5.12

$ php -r 'var_dump("0e462097431906509019562988736854" == "0e830400451993494058024219903391");'
bool(true)            # 7.4.33
bool(true)            # 8.5.12

Deux chaînes différentes, égales. Les deux commencent par 0e suivi de chiffres, donc PHP lit les deux comme zéro fois dix à la puissance de quelque chose, et zéro égale zéro. Les deux ont la forme d’un hachage MD5. Comparez un hachage de mot de passe stocké avec == au lieu de === ou de hash_equals(), et n’importe quelle entrée dont le hachage commence de cette façon correspond. C’est documenté depuis des années. Cela fonctionne toujours dans la version la plus récente.

Voilà le langage en un exemple. Une correction qui est entrée, la moitié du problème laissée derrière, et la version sûre qui exige de savoir qu’un autre opérateur existe.

Un shell, presque chaque année

La question qui vaut d’être posée à n’importe quelle plateforme n’est pas combien de bugs elle a eus. C’est à quelle fréquence quelqu’un aurait pu prendre tout le serveur sans mot de passe et sans que personne ne clique sur quoi que ce soit.

NVD note chaque CVE. Filtrez les 757 sur la note qui signifie exactement cela, attaque réseau, aucun privilège, aucune interaction utilisateur, impact élevé sur la confidentialité et l’intégrité, et vous obtenez 172¹⁵.

172 réparties sur 23 des 28 années qui comptent au moins une CVE PHP. Cinq seulement sont vides. 2016 à elle seule en compte 65.

Une note de gravité est une évaluation, pas une effraction. La seconde moitié du tableau est donc le catalogue Known Exploited Vulnerabilities de la CISA, qui ne liste que des failles dont l’exploitation dans la nature est confirmée²⁶. Sur ses 1 754 entrées au 21 octobre 2026, 81 concernent PHP lui-même ou des applications écrites en PHP :

2026 est déjà la pire année pour PHP dans le catalogue, et PHP2Shell n’y figure pas encore. Trois des entrées de cette année sont dans le cœur de WordPress lui-même : deux ajoutées le 21 juillet, et une inclusion de fichier distant le 25 septembre.

Et le catalogue sous-compte PHP lourdement. Il est construit autour des systèmes fédéraux américains et exige une CVE plus une exploitation confirmée. Il contient 3 entrées pour des extensions WordPress. L’écosystème des extensions WordPress a enregistré 11 334 vulnérabilités sur la seule année 2025³⁷. Les 81, c’est la part que quelqu’un d’officiel a mise par écrit.

WordPress multiplie le tout

WordPress représente 39,6 % de tous les sites web, et 58,3 % des sites dont le système de gestion de contenu peut être identifié³⁸. PHP est le langage côté serveur de 69,3 % des sites où on peut le voir³⁹. Quel que soit donc le dossier de PHP, WordPress l’emmène sur une très grande partie du web, puis y ajoute le sien.

Le cœur n’est pas le problème principal. Les extensions, si.

Wordfence, avec sa propre base, en a compté 8 223 pour 2024, une hausse de 68 % sur 2023, et a constaté « Roughly 35% of the vulnerabilities disclosed in 2024 remain unpatched in 2025 »⁴¹. Bases différentes, totaux différents, même allure.

Prenez un moment avec les chiffres de 2025. Près de la moitié des vulnérabilités n’avaient aucun correctif du développeur au moment où elles ont été rendues publiques. Et pour celles que les attaquants visent vraiment, l’écart médian entre la divulgation et l’exploitation de masse est de cinq heures. La plupart des gens ne vérifient pas les mises à jour de leurs extensions toutes les cinq heures. La plupart ne le peuvent pas.

Le modèle des extensions est le multiplicateur. La sécurité d’un site dépend de l’auteur le moins soigneux de tout ce qui y est installé, et Wordfence a constaté que « over one third of developers are unreachable or unresponsive » quand on leur signale une faille⁴¹. Patchstack a compté 1 614 extensions et thèmes retirés du dépôt en 2024 pour des problèmes de sécurité que personne n’a corrigés⁴⁰. Et à cause du modèle à processus unique, chaque extension tourne avec tous les droits du site.

Les incidents forment une longue liste. Voici ceux qui ont des sources primaires derrière eux :

J’ai été prudent avec la ligne 2016. Wordfence a montré que le site du cabinet tournait sur une version du slider trivialement exploitable. Il n’a pas montré que c’est ainsi que les documents ont été pris, et je ne vais pas affirmer plus que ce que les preuves établissent.

Comment le malware reste

Entrer, c’est la moitié. Rester, c’est l’autre moitié, et PHP rend cela facile pour une raison qui ramène tout droit à l’image du processus unique.

L’interpréteur exécutera n’importe quel fichier .php qu’il peut atteindre. La racine web est généralement accessible en écriture au même utilisateur qui exécute le code. Donc dès qu’un attaquant a un moyen quelconque d’écrire un fichier, un formulaire de téléversement, un bug d’extension, un gestionnaire de fichiers, il peut écrire un script qui s’exécute chaque fois que quelqu’un le demande. C’est un web shell : un petit fichier, posé dans votre site, qui prend des ordres.

La CISA dit depuis des années dans quels langages ils sont surtout écrits : « The most commonly observed web shells are written in languages that are widely supported, such as PHP and ASP. »⁵⁰ Les recommandations conjointes de la NSA et de l’Australian Signals Directorate les qualifient de « a long-standing, pervasive threat that continues to evade many security tools », et de difficiles à détecter parce qu’ils sont « easily modified by attackers and often employ encryption, encoding, and obfuscation »⁵¹.

Les chiffres du nettoyage montrent à quelle fréquence ils sont là :

Donc, sur l’année de nettoyage la plus récente, la moitié des sites piratés avaient encore un moyen de revenir, posé sur le disque. Restaurez la base, corrigez l’extension, et l’attaquant revient par le fichier qu’il a laissé.

Il n’y a pas de solution astucieuse à cela. Il y a la solution ennuyeuse et correcte, et la NSA l’a mise par écrit : « web applications should not have permission to write directly to a web accessible directory or modify web accessible code »⁵¹. Cette seule phrase, c’est le modèle à tiers séparés du début de cet article, dit par une agence de renseignement.

Le guide de durcissement de WordPress, pour ce qu’il vaut, ne mentionne jamais le fait d’empêcher PHP de s’exécuter dans le répertoire des téléversements¹¹. C’est pourquoi le tableau cite l’OWASP et la NSA à la place.

Remarquez ce qui ne figure pas dans ce tableau. Les propres réglages de durcissement de PHP. Le manuel est honnête à leur sujet. disable_functions « can be circumvented and should not be considered a sufficient security measure for shared hosting environments », et open_basedir « is just an extra safety net, that is in no way comprehensive, and can therefore not be relied upon when security is needed »⁵⁵. Quand la propre documentation d’un langage vous dit que ses boutons de sécurité ne sont pas des frontières de sécurité, croyez-la. La frontière doit donc venir de l’extérieur du processus.

Même php.net s’est fait cambrioler

Si l’infrastructure du projet lui-même était solide, on pourrait soutenir que le dossier s’explique par un problème difficile bien géré. Elle a été forcée deux fois.

C’est celle de 2021 qui compte. Quelqu’un a poussé du code dans l’arbre source du langage lui-même, en se faisant passer pour les gens qui le maintiennent. Cela a été repéré. La réponse du projet mérite d’être citée parce que c’est la bonne, dite simplement : « maintaining our own git infrastructure is an unnecessary security risk », et les dépôts sont passés sur GitHub⁵⁷.

Rendons à César : c’était une bonne décision, prise vite, et expliquée ouvertement. Mais regardez ce qu’elle reconnaît. Pendant des années, la source canonique d’un langage qui fait tourner l’essentiel du web a vécu sur une infrastructure auto-hébergée que le projet lui-même a jugée être un risque qu’il n’aurait pas dû porter.

La moitié du web tourne sur une version que personne ne corrige

Tout ce qui précède suppose que le site est à jour. Beaucoup ne le sont pas.

php.net prend actuellement en charge quatre branches. 8.2 ne reçoit plus que des correctifs de sécurité, jusqu’au 31 décembre 2026. 8.3, 8.4 et 8.5 sont les autres⁵⁸. Tout ce qui est plus ancien est en fin de vie : 8.1 depuis le 31 décembre 2025, 8.0 depuis novembre 2023, 7.4 depuis novembre 2022⁵⁹.

Voici maintenant la part mesurée de ce qui tourne réellement :

PHP 7.4 à lui seul, hors support depuis près de quatre ans, représente environ un cinquième de tous les sites PHP qui affichent leur version. La page des prérequis de WordPress demande PHP 8.3, puis dit que WordPress « also works with PHP 7.4+ », tout en notant que ces versions « have reached their official End Of Life »⁶³. Un éditeur qui tourne encore sur une version morte est un éditeur qui a décidé de ne pas vous faire bouger.

Deux réserves honnêtes. W3Techs ne voit la version que sur les sites qui l’annoncent. Et certaines distributions Linux rétroportent des correctifs dans d’anciennes versions de PHP, si bien que « non supporté par php.net » ne veut pas toujours dire « non corrigé ». Mais PHP2Shell est le test de cela. Le projet a bien publié des correctifs source pour 7.4, 8.0 et 8.1 cette fois¹, et quelqu’un doit encore les compiler, les livrer et les installer. Sur un hébergement mutualisé qui fait tourner une version dont personne n’est responsable, ce quelqu’un, c’est personne.

J’ai laissé tomber. Vous devriez envisager de partir aussi.

J’écrivais du PHP. Après Pulsant, j’ai laissé tomber le langage, à cause des problèmes qu’il causait et du travail que ces problèmes créaient. Pas un seul mauvais incident. Des années des deux mêmes causes, site après site, et le nettoyage qui retombait sur celui qui était de garde.

Je vais donc le dire clairement. Si le choix vous appartient, envisagez de le quitter. De meilleurs outils existent pour cela aujourd’hui, et Go est celui vers lequel je vous orienterais en premier.

Pas parce que c’est à la mode. Parce qu’il supprime, par défaut, l’essentiel de ce que cet article a compté :

Compilé compte deux fois. C’est plus rapide : les programmes Go « are compiled ahead of time to native machine code », sans machine virtuelle en dessous, et l’un des objectifs de conception affichés est « to approach the performance of C for comparable programs »⁶⁶. Et c’est plus sûr, parce qu’il n’y a pas d’interpréteur sur le chemin de la requête qui analyse du code à l’exécution, ni de moteur en C aux 757 CVE entre le réseau et votre programme. PHP, laissé à lui-même, fait l’inverse. Sans OPcache, il charge, analyse et compile chaque script à chaque requête, inutilement, des milliers de fois par minute sur un site chargé. OPcache existe pour arrêter cela, « removing the need for PHP to load and parse scripts on each request »⁶⁴. Mais il n’est pas actif d’emblée. Jusqu’à 8.4 incluse, c’est une extension partagée séparée que quelqu’un doit charger avec zend_extension et configurer. Seul PHP 8.5 l’intègre : « The Opcache extension is now always built into the PHP binary and is always loaded »⁷⁰. La RFC du projet pour ce changement dit que « running PHP in production without OPcache is generally considered a mistake »⁷¹. W3Techs place 8.5 sur 4,5 % des sites PHP 8⁶⁰, donc pour presque tout ce qui tourne aujourd’hui, le remède à la compilation de chaque script à chaque requête reste un module complémentaire que quelqu’un a dû penser à ajouter. Et même chargé, ce qu’il met en cache, c’est du bytecode que l’interpréteur en C doit exécuter. Go fait la compilation une fois, avant que le programme ne voie la moindre requête.

Plus rapide et plus sûr, à condition d’être correctement codé. Cette dernière réserve, c’est tout l’objet des paragraphes qui suivent.

Le paquet de templates de Go résume sa conception en une ligne : il génère « HTML output safe against code injection », et « The escaping is contextual, so actions can appear within JavaScript, CSS, and URI contexts. »⁶⁷ Son guide des bases de données est tout aussi clair : « You can avoid an SQL injection risk by providing SQL parameter values as sql package function arguments. »⁶⁸ Ce sont les comportements par défaut. En PHP, ce sont des choses qu’il faut savoir aller chercher.

La ligne que je soulignerais est celle du fichier déposé. La moitié des sites piratés que Sucuri a nettoyés en 2023 avaient encore une porte dérobée sur le disque⁵³, et cela ne marche que parce que l’interpréteur exécute n’importe quel script qu’il peut atteindre. Un service compilé ne va pas chercher de scripts. Un fichier déposé n’a rien sur quoi se brancher.

Maintenant la partie honnête, parce qu’un langage n’est pas un remède. Go est plus sûr en mémoire, pas parfaitement. Son propre modèle mémoire dit qu’une course de données sur une slice, une map ou une valeur d’interface « can in turn lead to arbitrary memory corruption »⁷², et Go fournit l’outil pour l’attraper. Compilez avec -race, ou lancez go test -race, et le binaire est compilé avec un détecteur qui signale une course au moment même où elle se produit. Il attrape les courses à l’exécution plutôt qu’à la compilation, et « can’t find races in code paths that are not executed », il a donc sa place dans chaque série de tests et sous une charge réaliste⁷³. PHP n’a rien de tel. Tenir la mémoire d’une requête à l’écart de la suivante est laissé entièrement au moteur, et PHP2Shell, c’est ce moteur qui se trompe : de la mémoire libérée par une requête, lue par la suivante sur le même worker⁶. En dehors de cela, Go arrête la classe de corruption mémoire que cet article a comptée, et fait de la manière sûre la manière facile pour deux autres. Il n’arrête pas une vérification de connexion cassée, un test de permission manquant ou une requête construite en collant des chaînes si vous tenez à le faire. Go publie aussi ses propres avis de sécurité, via sa base de vulnérabilités⁶⁹. Et un service Go lancé en root depuis un répertoire modifiable reste mal déployé.

Ce qu’il change, c’est le comportement par défaut. Le défaut de PHP, c’est un processus qui détient tout. Le défaut de Go, c’est un programme qui fait un seul travail, ce qui est la séparation du début de cet article avec l’essentiel du travail déjà fait. Si Go ne convient pas à votre équipe, Rust est l’autre porte de sortie. Les deux sont compilés à l’avance en code machine natif. Rust fonctionne « with no runtime or garbage collector »⁷⁴, et le compilateur et le runtime de Go sont « implemented in Go and assembler, without C » depuis Go 1.5⁷⁵.

C# et Java figurent aussi sur la liste des langages sûrs en mémoire des agences¹⁸, mais ils ne sont pas une sortie du problème par lequel cet article a commencé. Chacun tourne sur une machine virtuelle écrite en C++. HotSpot, chez OpenJDK, représente « around 3000 C/C++ header and source files, comprising more than 1.2 million lines of code »⁷⁶, et le ramasse-miettes et le compilateur JIT de .NET sont du code source C++ dans l’arborescence CoreCLR⁷⁷. C’est la même forme que PHP : un gros moteur natif entre le réseau et votre code. Et Java charge du code dans une application en cours d’exécution, par conception. Son chargeur de classes standard existe « to load classes and resources from a search path of URLs referring to both JAR files and directories »⁷⁸, et Log4Shell en a fait une exécution de code à distance : quiconque contrôlait un message de journal « can execute arbitrary code loaded from LDAP servers »⁷⁹. La faille est entrée tout droit dans le catalogue de la CISA²⁶. C’est la même porte que celle de PHP, avec plus de cérémonie devant.

Alors prenez Go ou Rust. Migrez d’abord le back end, un endpoint à la fois, et laissez le front end PHP ne détenir rien qui vaille d’être volé jusqu’à ce qu’il puisse partir lui aussi.

Si vous le déployez encore ainsi, pouvez-vous vous dire professionnel ?

Il y a assez de preuves ci-dessus pour que ce ne soit plus une opinion. Voici donc la question, posée directement. Si vous déployez encore PHP comme un seul processus qui détient le code, les identifiants et une racine web modifiable, pouvez-vous vous dire professionnel ?

Cela dépend de laquelle de trois personnes vous êtes. Et savoir laquelle n’est pas quelque chose qui vous arrive. S’assurer de savoir, c’est le métier.

Vous avez une vraie contrainte, et vous l’avez mise par écrit. Un produit dont l’activité dépend n’existe qu’en PHP. Une migration est chiffrée et dans le budget de l’an prochain. Très bien. C’est professionnel, à condition que la raison soit sur papier avec une date à côté, que l’utilisateur d’exécution ne puisse pas écrire le code, que les téléversements ne puissent pas s’exécuter, que le compte de base de données soit réduit, et que vous ayez corrigé PHP2Shell cette semaine. Vous courez un risque connu en connaissance de cause, avec les murs que vous pouvez mettre autour.

On ne vous l’a jamais dit. Personne ne vous a montré le dossier, et le tutoriel avec lequel vous avez appris mettait tout dans un seul répertoire. C’est une lacune, et tout le monde a des lacunes. Cela cesse d’être une lacune au moment où vous avez lu jusqu’ici.

Vous savez, et vous le construisez quand même. Vous avez vu les chiffres, ou assez d’entre eux. Vous savez que le mot de passe de la base est dans la racine web et que la racine web est modifiable. Vous déployez comme ça parce que c’est plus rapide, parce que le client ne paiera pas pour mieux, et parce que personne ne vous a obligé à le justifier. C’est le cas que vise cette question. La faute n’est pas la lacune dans vos connaissances. C’est de construire par-dessus une lacune que vous avez déjà vue et que vous n’êtes jamais revenu combler.

Tout le monde est passé par là. Y rester par choix, c’est la partie qui n’est pas défendable.

La porte a toujours été ouverte

Ce qui me frappe à la lecture de ce dossier, ce n’est pas que PHP ait des bugs. Tous les langages en ont. C’est à quel point peu de choses ont jamais été une surprise.

Le projet savait que register_globals était dangereux en 2002 et l’a retiré en 2012. Son manuel vous dit de ne pas faire confiance à unserialize(), ni à disable_functions, ni à open_basedir. Sa propre documentation dit qu’un script sous mod_php peut atteindre la base sans mot de passe. Les agences répètent depuis des années que le langage dans lequel il est construit est la source des deux tiers des bugs mémoire. Chaque avertissement est là, par écrit, venant des gens qui devraient savoir.

Et il a continué de gagner malgré tout, parce qu’il était bon marché. Bon marché à héberger, bon marché à apprendre, bon marché à vendre à un client qui voulait un site pour vendredi. Un répertoire, un processus, un mot de passe dans un fichier, et un site qui marchait. Son prix affiché, c’était une offre d’hébergement mutualisé. Ce qu’il coûtait n’a jamais figuré sur la facture : les nettoyages, les portes dérobées laissées sur le disque, les numéros de carte des clients siphonnés par du PHP malveillant, la fenêtre de cinq heures entre la divulgation et l’attaque.

C’est cela qui m’exaspère. Pas les bugs. La décision, prise encore et encore par des gens qui savaient, que la manière bon marché suffisait parce que personne ne vérifiait. Une norme, c’est ce que l’on tient quand personne ne vérifie. La séparation entre front end et back end, le code en lecture seule, le compte de base de données réduit : rien de tout cela n’est nouveau, rien n’est cher, et tout cela aurait fait d’un bon nombre des incidents ci-dessus rien qui vaille d’être raconté.

PHP2Shell n’est pas la fin de ce dossier. C’est seulement l’entrée de cette semaine. Le langage le corrigera, les hébergeurs déploieront la mise à jour tôt ou tard, et la part des versions remontera comme elle le fait toujours, lentement. Ce qui décide si le prochain vous coûtera, ce n’est pas PHP. C’est de savoir si vous avez construit les murs qu’il ne vous a jamais donnés, ou si vous êtes passé à quelque chose qui les fournit d’origine.