Mises à jour PHP 8.4.9 et 8.3.21 : Sécurité et correctifs critiques

Selon php.net, les branches 8.4 et 8.3 du runtime PHP reçoivent leurs correctifs: 8.4.9 et 8.3.21. Plusieurs régressions critiques fermées, vulnérabilité colmatée dans le traitement des flux de données. Trois composants de l'écosystème bougent dans la même fenêtre — runtime, PHPMailer, Doctrine ORM. Patch day.

Runtime: 8.4.9 et 8.3.21

Le communiqué reste évasif sur le détail public tant que les administrateurs n'ont pas déployé et remonté du terrain. La vulnérabilité signalée touche le sous-système de streams, c'est-à-dire le chemin de code emprunté dès qu'une application manipule un upload, un socket, un wrapper php:// ou une lecture de fichier volumineuse. C'est précisément la surface où une régression se traduit par une dérive de p95/p99 et des workers qui saturent.

Procédure standard:

• staging d'abord, profilage des routes qui touchent des streams
• comparaison p95/p99 et mémoire résidente avant/après
• php -v pour confirmer la version exacte post-déploiement
• rollback préparé vers 8.4.8 ou 8.3.20

Les équipes encore en 8.2 doivent traiter cette fenêtre comme le bon moment pour planifier la bascule vers 8.3. La fenêtre de maintenance active continue de se réduire release après release.

PHPMailer 6.9.2 — injection de code

Le programme CVE signale une faille d'injection de code corrigée dans PHPMailer 6.9.2. C'est la bibliothèque d'envoi mail la plus installée de l'écosystème Composer, présente dans des millions de composer.lock, le plus souvent via des dépendances transitives — frameworks, CMS, wrappers maison qui ne sont jamais audités.

Le communiqué recommande explicitement la mise à jour immédiate des dépendances. Aucune mitigation applicative sérieuse n'est viable: le fix est dans la lib, pas dans le code appelant.

Procédure minimale:

• composer update phpmailer/phpmailer --with-dependencies
• identifier les consommateurs via composer why phpmailer/phpmailer
• vérifier que la contrainte ne tire pas une version inférieure par héritage transitif
• auditer les points d'entrée mail dans le code applicatif

Une faille d'injection sur le pipeline mail ouvre une surface d'exécution classique via pièces jointes et headers mal filtrés. Temps de réaction: heures, pas jours.

Doctrine ORM 3.2.1: jointures DQL

Doctrine publie en parallèle la 3.2.1 de l'ORM. Les corrections ciblent les requêtes DQL à jointures multiples — exactement le pattern qui pèse sur PostgreSQL et MySQL quand on charge des graphes d'entités profondes ou qu'on matérialise des agrégats métier. Le communiqué mentionne des problèmes de performance résolus sur ce type de requêtes.

Avant de pousser:

• rejouer les requêtes lentes connues en staging
• comparer les plans d'exécution via EXPLAIN ANALYZE avant/après
• valider la compatibilité ascendante: 3.2.1 reste sur la même branche majeure, risque de régression applicative faible mais pas nul

Verdict

Trois composants, une seule fenêtre de maintenance. Ordre recommandé: PHPMailer d'abord (vecteur d'injection actif, communiqué explicite), PHP runtime ensuite, Doctrine en dernier. Patch day. Pas de débat.