Le point le plus sensible concerne une vulnérabilité d’injection SQL dans l’extension PostgreSQL — autrement dit, le genre de détail qui transforme une simple maintenance de dépendances en vraie urgence pour les équipes PHP. Les paquets corrigés sont annoncés pour Fedora et Enterprise Linux via les dépôts RPM de Remi.
Pourquoi cette mise à jour mérite-t-elle autre chose qu’un « on verra demain »?
Les trois branches actuellement concernées sont couvertes par cette vague de correctifs, avec une exception technique importante: le bug lié à BCMath ne touche que PHP 8.4 et 8.5 selon les informations rapportées. La vulnérabilité PostgreSQL, elle, concerne la gestion de paramètres dans plusieurs fonctions de l’extension — notamment pg_insert, pg_update, pg_select et pg_delete.
Le problème apparaît dans le traitement de chaînes échappées lors de requêtes PostgreSQL. Dans certaines conditions, une entrée mal contrôlée pourrait sortir du contexte prévu et modifier la requête SQL. Oui, même en 2026, on doit encore regarder très attentivement ce qui se passe entre notre code PHP et la base de données. Le legacy n’a pas disparu: il a simplement appris à vivre dans des pipelines CI/CD.
Le correctif BCMath concerne pour sa part une écriture hors limites déclenchée par certains réglages d’échelle manuels. Quant à Phar, le troisième problème signalé implique une récursion non bornée lors du traitement de liens symboliques circulaires dans une archive. Linux Compatible le classe comme modéré, car le scénario nécessite un accès local et une interaction de l’utilisateur.
Que vérifier côté projet PHP?
Premier réflexe: identifier la version réellement exécutée en production — pas celle déclarée dans un fichier de configuration oublié depuis la dernière refacto. Les versions annoncées sont:
- PHP 8.2.33;
- PHP 8.3.33;
- PHP 8.4.24;
- PHP 8.5.9.
Si vos serveurs Fedora utilisent les paquets de Remi, le média indique que les mises à jour sont disponibles pour Fedora 42 et versions ultérieures. Elles concernent également Enterprise Linux 8 et versions suivantes, avec des paquets proposés pour les installations modulaires et les Software Collections.
Ensuite, il faut regarder l’usage réel des extensions. Les applications qui s’appuient sur PostgreSQL et transmettent des données utilisateur à l’extension pgsql sont directement concernées par le scénario d’injection décrit. Cela ne dispense évidemment pas de valider les entrées et de construire correctement les requêtes, mais rester sur une version non corrigée serait une drôle de stratégie de défense (et pas franchement le genre de pari qu’on veut expliquer pendant un incident).
Les équipes qui utilisent BCMath doivent aussi vérifier leur version si elles ont déjà migré vers PHP 8.4 ou 8.5. La bibliothèque intervient notamment dans des traitements numériques où la précision compte; ici, le correctif porte sur un problème mémoire, pas sur la logique métier de vos calculs.
Et pour les équipes encore en PHP 8.1?
Le signal est moins subtil: Linux Compatible indique que PHP 8.1 est arrivé en fin de vie et que Remi ne fournit plus ses paquets pour cette branche. La mise à niveau n’est donc plus seulement une question de récupérer le dernier patch de sécurité; elle devient un sujet de trajectoire technique.
Dans l’immédiat, on peut commencer par inventorier les versions PHP et les extensions sur chaque environnement, puis planifier le passage vers une branche encore supportée. C’est moins spectaculaire qu’une nouvelle RFC, certes, mais beaucoup plus utile qu’une énième promesse de « refacto sécurité » dans six mois.
La suite dépendra de vos contraintes de compatibilité, de vos dépôts et de votre calendrier de déploiement. Mais une chose est claire: ces versions corrigées doivent maintenant entrer dans la file des mises à jour prioritaires. À nous de décider si la maintenance PHP reste une corvée du vendredi soir… ou devient enfin une partie normale du métier.