Unraid OS 7.3.4 est sorti le 22 octobre 2026. À première vue, les notes de version ressemblent à une mise à jour de routine : 44 paquets changent de numéro, quelques pilotes sont rafraîchis, rien n’est marqué comme urgent. Mais une ligne du changelog sort du lot. PHP passe de 8.4.26-1_LT à 8.4.27-1_LT, exactement la version que l’équipe sécurité de PHP a publiée la veille pour corriger deux failles critiques, non authentifiées, que des chercheurs ont surnommées PHP2Shell.
Ce que contient vraiment la 7.3.4
Les notes de version officielles décrivent la mise à jour PHP comme un correctif pour « plusieurs vulnérabilités PHP signalées », sans jamais citer de CVE ni le nom PHP2Shell. Ça vaut la peine d’être précis là-dessus : Unraid n’a confirmé le lien avec PHP2Shell dans aucune communication officielle. Ce qui colle, c’est le numéro de version et le calendrier. Les mainteneurs de PHP ont corrigé la faille dans la version 8.4.27 (ainsi que dans 8.5.12, 8.3.36 et 8.2.35) le 21 octobre. Unraid a livré cette build patchée le lendemain. Un délai aussi court rend l’hypothèse raisonnable, mais ça reste une déduction à partir de la correspondance des versions, pas une annonce du fournisseur.
PHP n’est pas un détail accessoire sur Unraid. L’interface web du système tourne dessus, et selon la configuration du serveur, plusieurs plugins aussi. C’est exactement le type d’exposition que vise PHP2Shell.
Pourquoi PHP2Shell a fait autant de bruit
PHP2Shell est le nom donné à deux failles liées, répertoriées sous CVE-2026-109618 et CVE-2026-109619, détaillées le 21 octobre par BleepingComputer. Les deux sont exploitables sans authentification et peuvent mener à une exécution de code à distance, ce qui classe ces bugs parmi les plus sérieux qu’un composant web public puisse subir.
- CVE-2026-109618 : une chaîne de faiblesses qui déclenche une condition de dépassement mémoire à la fin d’une requête anormale, corrompant la mémoire d’une manière qui peut être retournée en exécution de code.
- CVE-2026-109619 : un bug use-after-free qui exploite un état global périmé laissé par une requête précédente, provoquant une fuite mémoire puis l’exécution de code.
Le niveau de risque dépend de la configuration du serveur. Mod_php sous Apache est cité comme le pire des cas, mais PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont aussi exposés, à des degrés variables. Certaines estimations situent la part de PHP dans l’infrastructure web mondiale autour de 70 %, ce qui explique pourquoi des correctifs d’urgence sont sortis le jour même plutôt que d’attendre une publication planifiée.
Les 43 autres paquets
PHP n’était pas le seul composant concerné par des CVE dans cette version. Parmi les plus notables :
- curl 8.22.0 à 8.23.0 — 21 CVE
- openssl 3.5.8 à 3.5.9 — 13 CVE
- xorg-server 21.1.24 à 21.1.25 — 11 CVE
- libXi 1.8.3 à 1.8.4 — 8 CVE
- libX11 1.8.13 à 1.8.14 — 4 CVE
- nginx 1.30.4 à 1.30.6 — corrige CVE-2026-15176
- libpng 1.6.58 à 1.6.59 — corrige CVE-2026-46675
- libXtst, libXpm et libXrender — une ou deux CVE chacune
À côté de ça, la 7.3.4 fait aussi passer le noyau Linux à 6.18.54-Unraid, met ZFS à jour en 2.4.4, passe Docker Engine en 29.8.2 et l’API Unraid en 4.37.5-2, et rafraîchit plusieurs pilotes réseau Intel, MediaTek et Realtek, avec quelques améliorations côté Hyper-V. Rien de tout ça n’est critique en soi, mais ça représente beaucoup de terrain couvert pour une simple version mineure.
Faut-il mettre à jour maintenant ?
Oui, et il n’y a pas vraiment de débat à avoir. Si l’interface web du serveur est accessible depuis l’extérieur du réseau local, même derrière un reverse proxy, le correctif PHP justifie à lui seul de passer à la 7.3.4 sans attendre. Si le serveur reste strictement sur le réseau local, le risque immédiat est plus faible, mais les quelque 50 autres CVE corrigées dans curl, OpenSSL et les bibliothèques X11 restent utiles à avoir. La mise à jour est disponible dès maintenant depuis l’interface Unraid, sous Tools > Update OS, ou via le chemin de mise à jour habituel pour une distribution communautaire du système.
Unraid a déjà sorti des correctifs de sécurité rapidement dans le passé, et son modèle économique à licence payante et code fermé fait partie de l’explication derrière cette réactivité. On revient sur l’origine de ce choix dans notre histoire d’Unraid.