Patcher ses runtimes quand on est une PME : PHP, Ruby, Node, sans équipe dédiée

Cette semaine, trois des moteurs d'exécution les plus répandus ont publié des correctifs de sécurité. PHP a corrigé php2shell mercredi 21 octobre, puis a signalé vendredi une troisième faille, pas encore corrigée. Node.js a sorti le 21 octobre des versions de sécurité pour ses trois lignes maintenues. Ruby a publié le 23 octobre les versions 4.0.9, 3.4.12 et 3.3.13. Pour une grande entreprise, c'est une semaine chargée. Pour une PME sans équipe sécurité ni ingénieur dédié, c'est surtout une semaine où l'on découvre que personne ne sait vraiment ce qui tourne où.

Cet article s'adresse à un confrère : vous êtes CTO, responsable technique ou prestataire d'une PME, vous dépendez de PHP, de Ruby, de Node ou d'autres runtimes, et personne n'est payé pour suivre leurs correctifs. Je décris la routine minimale que je mettrais en place, avec les faits que j'ai pu vérifier cette semaine et ce que je n'ai pas pu vérifier. Je n'ai pas traité Python ici : la méthode est la même, mais je n'ai pas contrôlé son calendrier.

Où se cachent vos runtimes

Le runtime est le programme qui exécute votre code : l'interpréteur PHP ou Ruby, Node.js. On met à jour l'application, on oublie ce qu'il y a dessous. Voici où il se loge d'habitude.

• Les images Docker. Le runtime est figé dans l'image au moment de sa construction. Mettre à jour le serveur hôte ne change rien à la version qui tourne dans le conteneur. Une image construite il y a deux ans continue de tourner avec le PHP ou le Node d'il y a deux ans.
• Les serveurs oubliés. Un ancien projet, une préproduction restée en ligne, une machine chez un prestataire dont le contrat a pris fin.
• Les logiciels packagés. Un LMS, un CMS, un outil de ticketing, un webmail. Moodle, Drupal et Chamilo tournent sur PHP, comme je le détaille dans l'article sur les LMS. Et un logiciel peut embarquer sa propre copie du runtime : GitLab, par exemple, a corrigé ses failles en patchant le Ruby qu'il livre, selon l'avis de Ruby.
• Les petits outils internes. Le script Node d'un stagiaire, le service Ruby écrit par un ancien prestataire, la tâche planifiée que personne n'ose toucher.
• Ce que gère quelqu'un d'autre. Votre hébergeur, votre infogérant, votre éditeur SaaS. Le piège relevé par Wordfence : la mise à jour automatique de WordPress ne met pas à jour PHP. Il faut savoir qui est responsable du moteur, et l'avoir par écrit.

Le Centre canadien pour la cybersécurité le formule dans son alerte sur php2shell : identifier les produits tiers, les équipements et les conteneurs qui embarquent PHP. C'est la même logique pour les autres runtimes.

Combien de temps entre un correctif et une attaque ?

Je n'ai pas trouvé de chiffre fiable de délai moyen, et je n'en inventerai pas. Les trois cas de la semaine montrent surtout que la réponse n'est pas « on a le temps ».

PHP. Selon la PHP Foundation, les identifiants des failles ont circulé à partir du 20 octobre vers 17 h, heure de Paris, et la publication a été avancée d'un jour. Toujours selon elle, Chainguard a diffusé le 21 octobre à 9 h 41 des images contenant le correctif, plus de six heures avant la publication coordonnée. Cloudflare dit avoir vu des tentatives avant la sortie des correctifs. Le RSSI d'AWS parle de tentatives d'exploitation massives, dont on ignore combien ont réussi, et Dataminr ne voit à ce stade que du balayage et des exploits non fonctionnels, selon BleepingComputer. Je n'ai trouvé aucune de ces deux failles dans le catalogue des vulnérabilités exploitées de la CISA, dont j'ai consulté le fichier de données ce soir.

Le délai de votre distribution. Sur Amazon Linux 2023, les paquets corrigés pour PHP 8.2 à 8.5 sont arrivés le 22 octobre à 6 h, heure de Paris, soit environ quatorze heures après la publication de PHP. Pour PHP 8.1, le statut est No Fix Planned. Sur Amazon Linux 2, seul le dépôt Extras de PHP 8.2 a reçu un correctif le 22 octobre, et la branche principale est marquée No Fix Planned. Amazon Linux 2 n'est plus supporté. Attendre « la mise à jour de l'OS » peut donc vouloir dire attendre un correctif qui ne viendra pas.

Ruby. Le sens est inversé. GitLab a corrigé quatre failles de son côté, dans ses versions 19.4.1, 19.4.2 et 19.5.1, en patchant le Ruby qu'il embarque, puis Ruby a publié ses propres versions le 23 octobre. Les bogues sont dans Onigmo, le moteur d'expressions régulières de Ruby, et ne sont atteints que si une application compile une expression régulière à partir d'une chaîne contrôlée par un attaquant. Les applications qui n'utilisent que des expressions écrites par leurs développeurs ne sont pas concernées. Ruby précise que Regexp.timeout ne protège pas, et que limiter la longueur des motifs non plus. L'avis ne mentionne aucune exploitation. Pour une PME qui héberge GitLab, le correctif est venu par GitLab, pas par une mise à jour de Ruby.

Node.js. Le 21 octobre, le projet a corrigé ses lignes 22, 24 et 26, avec une gravité maximale « élevée ». Parmi les failles, CVE-2026-111497 : le décodeur Brotli peut écrire en dehors de son tampon, ce qui peut mener à une exécution de code si l'application décompresse avec node:zlib des données fournies par un attaquant. Le projet rappelle aussi que les versions en fin de vie sont toujours concernées lors d'une publication de sécurité, sans jamais recevoir le correctif.

Ce que ces cas ont en commun : la fenêtre entre le correctif et l'attaque n'est pas la vôtre. Elle peut s'ouvrir avant la publication, et le correctif arrive chez vous par un canal que vous ne maîtrisez pas toujours. Et le rythme va s'accélérer : OpenAI s'attend à ce que les découvertes de failles par l'IA augmentent fortement, et curl traitera ses failles mineures en public à partir du 26 octobre face à l'afflux de signalements. Ma règle de départ, qui est une règle et non un fait : un correctif critique sur un service exposé à Internet se déploie en quelques jours, au plus 48 heures, et le reste dans un cycle de quelques semaines.

Le calendrier officiel : savoir quand chaque version s'arrête

Premier réflexe utile : connaître la date de fin de support de chaque version que vous utilisez. Elles sont publiques.

• PHP (php.net). La 8.2 reçoit des correctifs de sécurité jusqu'au 31 décembre 2026, la 8.3 jusqu'au 31 décembre 2027, la 8.4 jusqu'au 31 décembre 2028, la 8.5 jusqu'au 31 décembre 2029. Le projet ne publie plus rien pour la 8.1 et les versions antérieures.
• Ruby (ruby-lang.org). Les branches 4.0 et 3.4 sont en maintenance normale, sans date de fin annoncée. La 3.3 est en maintenance de sécurité, avec une fin de vie prévue au 31 mars 2027. La 3.2 est en fin de vie depuis le 1er avril 2026.
• Node.js (calendrier de la version, dépôt nodejs/Release). La 20 est en fin de vie depuis le 30 avril 2026. La 22 s'arrête le 30 avril 2027, la 24 le 30 avril 2028, la 26 le 30 avril 2029. La 26 est encore en statut Current, sa phase LTS est prévue le 28 octobre, et le projet recommande de n'utiliser en production que des versions LTS.

Sur ce calendrier, trois échéances proches : PHP 8.2 dans environ deux mois, Ruby 3.3 dans cinq mois, Node 22 dans six. Si vous en avez une en production, elle doit déjà figurer sur votre feuille de route.

Deux réserves. Ces dates sont celles du projet d'origine : votre distribution peut être plus en avance ou plus en retard, comme Amazon Linux le montre pour PHP 8.1. Et ce calendrier ne couvre que le moteur, pas l'application. Drupal 7 n'a plus aucun correctif depuis le 5 janvier 2025, et W3Techs mesurait encore 29,1 % des sites Drupal sur cette version au 20 octobre 2026, comme je l'écris dans l'article sur les LMS. Une version hors support ne reste pas inoffensive : elle reste en ligne.

La routine minimale

Pas d'outil à acheter pour commencer. Un tableau, une boîte mail partagée, un créneau dans l'agenda et quelqu'un de nommé.

1. Un inventaire. Un tableau avec, pour chaque service : le runtime et sa version, l'endroit où il tourne (hébergeur, image, serveur), le responsable, la date de fin de support, et s'il est exposé à Internet. Pour le remplir : php -v, ruby -v et node -v sur les serveurs ; les lignes FROM des Dockerfile dans vos dépôts ; et pour une image déjà construite, la version affichée par le conteneur lui-même. Attention aux correctifs rétroportés par une distribution : php -v ne change pas, il faut lire le journal des modifications du paquet.

2. Une veille, qui ne dépend pas d'une personne. Abonnez une boîte partagée aux annonces de PHP (php.net), aux actualités de Ruby (ruby-lang.org), au blog de sécurité de Node.js, aux avis de vos éditeurs de CMS ou de LMS, et aux alertes du CERT-FR. Cette semaine, PHP a annoncé sa publication la veille. Une alerte lue le matin laisse une journée pour s'organiser.

3. Un créneau de mise à jour fixe. Une heure par semaine, toujours la même, pour les correctifs ordinaires, et une procédure d'urgence écrite pour les critiques exposés : qui décide, qui déploie, qui prévient. Un responsable et un suppléant. Pour PHP, l'avis demande de redémarrer tous les processus après avoir appliqué la mesure de contournement ; après une mise à jour, vérifiez de la même façon que PHP-FPM ou Apache ont bien rechargé la nouvelle version.

4. Des images Docker reconstruites, pas seulement des serveurs mis à jour. Reconstruisez les images régulièrement en récupérant l'image de base à jour, redéployez tous les conteneurs qui en dépendent, puis vérifiez la version dans le conteneur qui tourne. Une image qu'on ne reconstruit jamais est un runtime qu'on ne met jamais à jour.

5. Des tests avant de déployer, même minimaux. Idéalement la suite de tests de l'application. À défaut, une liste courte à dérouler sur une copie : connexion, une page clé, un appel d'API, un paiement ou un envoi de courriel. Un correctif de runtime est en général petit, mais il touche tout ce qui tourne dessus.

6. Un retour arrière prêt. L'ancienne image ou l'ancienne version du paquet conservée, une commande pour la redéployer, et un essai à blanc fait au moins une fois. Une mise à jour dont on ne sait pas revenir en arrière finit par ne plus se faire.

Après une alerte critique, ajoutez une étape : relire les journaux. Le Centre canadien recommande de chercher des processus, des fichiers, des comptes ou des connexions sortantes inattendus liés au serveur web.

Que faire d'un runtime qui n'est plus supporté

Trois options, dans cet ordre de préférence.

Migrer. C'est la seule qui règle le problème. Le vrai coût est rarement le runtime, c'est le framework, les plugins et les bibliothèques qui ne suivent pas. Mon critère : une version qui n'a plus que six mois de support devant elle se planifie comme si elle était déjà hors support.

S'appuyer sur des correctifs tiers, le temps de migrer. Pour PHP, le dépôt communautaire d'Ondřej Surý a publié le 21 octobre des paquets corrigés pour les branches 5.6 à 8.1 sur Debian et Ubuntu. J'ai vérifié que leurs journaux de modifications citent bien les deux identifiants de php2shell. Les réserves sont les mêmes que dans l'article sur php2shell : c'est un dépôt tiers, maintenu par une personne, une rustine et non un plan de migration, il faut lire le journal pour s'assurer que le correctif est là, et cela ne concerne que Debian et Ubuntu. Pour un engagement contractuel, Freexian vend une offre PHP LTS. Quant à la distribution elle-même, vérifiez ce qu'elle fait réellement : Amazon Linux a marqué PHP 8.1 No Fix Planned.

Isoler. Si ni l'une ni l'autre n'est possible : retirer le service d'Internet, le placer derrière un VPN ou une liste d'adresses autorisées, le passer en lecture seule ou l'arrêter. C'est la dernière branche de l'arbre de décision de l'article sur php2shell.

Ne comptez pas sur les exceptions. Cette semaine, PHP a publié des rétroportages minimaux du code source pour les versions 7.4, 8.0 et 8.1 « vu la gravité », et Ruby a inclus les correctifs dans la 3.3.13 alors que cette branche n'est censée recevoir que des correctifs de sécurité, « à titre d'exception ». Ce sont des gestes, pas un engagement.

La checklist

Inventaire

• Chaque service avec son runtime, sa version exacte, son hébergeur et son responsable.
• Les images Docker et leur date de construction, les serveurs de préproduction et ceux d'anciens projets.
• Les logiciels qui embarquent un runtime (LMS, CMS, GitLab, outils internes).
• La date de fin de support de chaque version, et celles qui tombent dans les douze mois.

Veille

• Une boîte partagée abonnée aux annonces de PHP, Ruby, Node, de vos éditeurs et du CERT-FR.
• Un responsable et un suppléant nommés.

Mise à jour

• Un créneau hebdomadaire, une procédure d'urgence écrite, un délai cible pour les critiques exposés.
• Des images reconstruites avec une image de base à jour, tous les conteneurs redéployés, la version vérifiée en production.
• Tous les processus redémarrés après un correctif ou une mesure de contournement PHP, et la version vérifiée.
• Une liste de tests, un retour arrière essayé.

Hors support

• Un plan de migration daté pour toute version qui s'arrête dans moins de six mois.
• Pour les versions déjà arrêtées : un correctif tiers vérifié, ou l'isolation, avec une date de fin.
• Après une alerte critique : relecture des journaux.

Si vous voulez faire relire votre inventaire et votre routine par un regard extérieur, c'est une partie de mon travail de CTO indépendant, et vous pouvez me contacter.

Sources

• PHP, Security advisory: Critical remote code execution vulnerabilities, update now, 21 octobre 2026, annonce préalable, 20 octobre 2026, et Informational advisory: Session upload progress, 23 octobre 2026.
• PHP, Supported Versions, consulté le 23 octobre 2026.
• PHP Foundation, Today's PHP Security Release, and How We're Strengthening PHP Security, 21 octobre 2026.
• Ruby, Regexp compilation fixes related to GitLab's CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264, 23 octobre 2026, et Ruby Maintenance Branches, consulté le 23 octobre 2026.
• Node.js, Wednesday, October 21, 2026 Security Releases, Node.js Releases et calendrier des versions, consultés le 23 octobre 2026.
• Amazon Linux, CVE-2026-109618 et CVE-2026-109619, bulletins ALAS2023-2026-3301 à 3304 et ALAS2PHP8.2-2026-015, consultés le 22 octobre 2026.
• BleepingComputer, PHP shares mitigation for new RCE vulnerability with no patch, 23 octobre 2026.
• Centre canadien pour la cybersécurité, AL26-026, mise à jour 1, 23 octobre 2026.
• CISA, Known Exploited Vulnerabilities, fichier de données, consulté le 23 octobre 2026.
• OpenAI, Patch the Planet: global response coordination as agents uncover critical vulnerabilities, 21 octobre 2026.
• Daniel Stenberg, Do minor curl vulnerabilities in the open?, 20 octobre 2026.
• Dépôt PHP d'Ondřej Surý, packages.sury.org/php, et Freexian, PHP LTS.
• W3Techs, Historical trends in the usage of Drupal versions, consulté le 22 octobre 2026, et Drupal, Drupal 7 End of Life, cités dans l'article sur les LMS.