Journal Failles de sécurité dans PHP, correctifs à 16H (Paris)

Posté par  . Licence CC By‑SA.
Étiquettes :
42
21
oct.
2026

Bonjour !
J'ai vu qu'il y avait déjà un lien sur le sujet, je me suis dit que j'allais rédiger un journal pour donner plus de visibilité à l'évènement.

L'équipe derrière PHP a annoncé la publication très prochaine de deux correctifs pour des failles de sécurité critiques qui permettraient à un assaillant d'exécuter du code à distance sur un serveur faisant tourner PHP. Il suffirait d'un accès à un site exécutant du PHP pour déclencher la faille (donc même une application qui demande une authentification pour être utilisée peut être sensible).

Il y a beaucoup de discussions et de rumeurs sur le sujet (Si ça vous intéresse, vous les retrouverez sur Hacker News ) mais la situation a l'air grave, plusieurs personnes conseillent de désactiver tous les services PHP accessibles depuis l'extérieur si c'est possible ( ex: Dokuwiki, OSM France et Codeberg ont désactivé des services en PHP en attendant la mise à jour).

Certaines contre mesure circulent mais d'après un mainteneur PHP, la seule solution pour être protégé, c'est de mettre à jour.

Un POC circule (vraisemblablement quelqu'un qui a demandé à un LLM de trouver une faille une fois qu'il y a eu l'annonce des patchs), mais on ne sait pas si il couvre réellement les deux failles corrigées. D'après Cloudflare, la/les faille serait activement exploitée.

Si vous avez besoin de sources un peu plus institutionnelles que Mastodon pour convaincre un décideur pressé qu'il faut couper tous vos services en PHP, voici un lien de Cert Europa.eu et un lien vers Next.

Bref, si vous avez des services perso qui tourne avec du PHP, n'oubliez pas de les couper au cas où si c'est envisageable.

  • # Petit oubli

    Posté par  . Évalué à 10 (+13/-0).

    J'ai oublié de préciser, ça touche toutes les versions de PHP de ces ~10 dernières années (jusqu'à la 5) et seule la version 8 sera patchée.

  • # Next

    Posté par  . Évalué à 10 (+9/-0).

    Pour le lien vers Next, le site est en maintenance… (C'est du WordPress - donc du PHP - derrière)

  • # Update now !

    Posté par  (Mastodon) . Évalué à 10 (+9/-0). Dernière modification le 21 octobre 2026 à 15:54.

    Les correctifs sont là. Et au passage Yunohost les a publiés vers 15h45. Ce qui m'arrange parce que je savais même pas quelles applis utilisent PHP. Au top !

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Update now !

      Posté par  (site web personnel) . Évalué à 10 (+8/-0). Dernière modification le 21 octobre 2026 à 16:01.

      je confirme, paquets debian dispos :

      https://lists.debian.org/debian-security-announce/2026/msg00489.html

      S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

      • [^] # Re: Update now !

        Posté par  (site web personnel) . Évalué à 5 (+3/-0).

        Petit info au cas ou, j'ai fait l'update sur mon serveur dédié.

        J'ai vérifié ensuite avec un phpinfo et j'étais toujours en 8.4.26.

        J'ai du faire un

        systemctl restart apache2

        pour que mon phpinfo affiche bien 8.4.27. N'étant pas expert, vous savez pourquoi ?

        Il y a sans doute eu un reload mais pas un restart d'apache.

        S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

        • [^] # Re: Update now !

          Posté par  . Évalué à 7 (+5/-0).

          Tu utilises mod_php probablement?

          • [^] # Re: Update now !

            Posté par  . Évalué à 5 (+3/-0).

            c'est peut être une raison mais est ce une explication ;)

            "Si tous les cons volaient, il ferait nuit" F. Dard

          • [^] # Re: Update now !

            Posté par  (site web personnel) . Évalué à 5 (+3/-0).

            Tout à fait, donc si je comprends ta réponse, ce serait que reload recharge la configuration apache et restart rechargerait tous les modules ? Donc redémarrerait le module php ?

            Si c'est ça, c'est dommage de ne pas le savoir car si je n'avais pas vérifié ma version chargée avec phpinfo, je serai rester avec l'ancien module chargé.
            C'est dommage que debian n'ai pas communiqué là dessus dans le mail de sécurité…

            S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

            • [^] # Re: Update now !

              Posté par  . Évalué à 9 (+7/-0).

              mod_php est un module in-process pour Apache, donc il faut redémarrer Apache pour qu'il soit rechargé, oui.

            • [^] # Re: Update now !

              Posté par  . Évalué à 7 (+5/-0).

              Tu viens de comprendre pourquoi windows insiste autant pour redémarrer après ses mises a jours, meme si techniquement, il pourrait faire sans :)

              Mettre a jour l'executable sur le FS ne recharge pas magiquement toutes les instances du process qui tournaient avant la mise a jour (ou qui l'avaient linké, si c'est une librairie).

              D'ou l'intérêt de forcer un reboot, ca resoud le problème.

              • [^] # Re: Update now !

                Posté par  (courriel, site web personnel) . Évalué à 8 (+6/-0).

                Le redémarrage du système est le moyen le plus sûr de s'assurer que les mises à jour soient appliquées (et que le système soit toujours capable de démarrer) mais, en 2026, si on veut être le moins intrusif possible, on a la technologie pour détecter ce qui a besoin d'être redémarré.

                pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

              • [^] # Re: Update now !

                Posté par  . Évalué à 10 (+8/-0). Dernière modification le 22 octobre 2026 à 08:41.

                Oui enfin, sur Debian par exemple, en fin de mise à jour needrestart est lancé automatiquement pour redémarrer les processus qui le nécessitent.

                Le redémarrage complet de la machine n'est nécessaire en général qu'en cas de mise à jour du noyau.

                EDIT : pardon doublon avec le commentaire de @Krunch

                • [^] # Re: Update now !

                  Posté par  (courriel, site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 22 octobre 2026 à 10:12.

                  Techniquement pour le noyal, il devrait généralement être possible de mettre à jour sans redémarrer avec Oracle® Ksplice™. Il est aussi normalement possible de mettre à jour son noyal sans redémarrer la machine avec kexec mais fonctionnellement, en général, c'est équivalent à redémarrer.

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                  • [^] # Re: Update now !

                    Posté par  (site web personnel) . Évalué à 6 (+3/-0).

                    il devrait généralement être possible de mettre à jour sans redémarrer avec Oracle® Ksplice™.

                    Cela ne s'applique pas à la majorité des correctifs du noyau. Et cela ne résout pas le problème pour les composants de base telles que la libc, systemd, ton shell, etc. où le redémarrage devient in fine le seul choix possible sûr.

                    Le concours du gros uptime n'a plus lieu d'être depuis un moment.

                    • [^] # Re: Update now !

                      Posté par  (courriel, site web personnel) . Évalué à 7 (+5/-0).

                      Cela ne s'applique pas à la majorité des correctifs du noyau

                      {{référence nécessaire}}

                      le problème pour les composants de base

                      C'est couvert par needrestart comme discuté ci-dessus.

                      Le concours du gros uptime n'a plus lieu d'être depuis un moment.

                      Tu dis juste ça parce que t'aime pas perdre. /s

                      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                • [^] # Re: Update now !

                  Posté par  . Évalué à 4 (+2/-0).

                  Ou de la mise a jour d'une appli pas fournie par la distribution, ou qui est mal intégrée, ou parce que t'as un cache des bois qq part, ou que sais je encore.
                  Ou tout simplement que certaines bibliothèques sont tellement utilisée qu'un redémarrage sélectif revient en pratique a un reboot: si libgnome est mit a jour, redémarrer le desktop manager revient en pratique a rebooter.

                  Je vais pas préconiser de redémarrer a chaque mise a jour de la moindre appli, mais quand on parle de mise a jour système, ou d'un composant serveur aussi poutré que PHP, se fader un reboot mange pas de pain et évite des problèmes.

                  On est plus en 1997, un reboot a soit 0 impact sur la production, soit est au pire donne 2 minutes pour aller se chercher un café.

                  • [^] # Re: Update now !

                    Posté par  . Évalué à 3 (+1/-0).

                    Ou de la mise a jour d'une appli pas fournie par la distribution, ou qui est mal intégrée, ou parce que t'as un cache des bois qq part, ou que sais je encore.

                    C'est à l'administrateur système de prévoir le cas avec un processus de mise à jour spécifique et éventuellement d'isolation de l'application.

                    Ou tout simplement que certaines bibliothèques sont tellement utilisée qu'un redémarrage sélectif revient en pratique a un reboot: si libgnome est mit a jour, redémarrer le desktop manager revient en pratique a rebooter.

                    On ne parle pas d'une machine de bureau, le redémarrage n'y est effectivement pas un problème.
                    Dans le cas d'un serveur cela signifie une interruption des services hébergés, puis la vérification que tous sont à nouveau fonctionnels.

                    • [^] # Re: Update now !

                      Posté par  (Mastodon) . Évalué à 5 (+2/-0).

                      Dans le cas d'un serveur cela signifie une interruption des services hébergés, puis la vérification que tous sont à nouveau fonctionnels.

                      Ce que je comprends pas dans ce scénario c'est que si le service en question n'accepte absolument pas 2mn d’interruption, alors il y a de la redondance, de la répartition de charge etc. Il "suffit" donc de ne pas rebooter tout le monde en même temps.

                      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                      • [^] # Re: Update now !

                        Posté par  . Évalué à 3 (+1/-0).

                        le service en question n'accepte absolument pas 2mn d’interruption
                        Cela peut dépendre du moment de la journée.

                        Quand tu redémarres un serveur tu n'as aucune garantie sur le temps avant que les services soient de nouveau fonctionnels. Deux minutes c'est quand tout se passe bien ;-). Donc oui si le service ne supporte pas la moindre interruption, il ya de la redondance

                    • [^] # Re: Update now !

                      Posté par  . Évalué à 3 (+2/-1).

                      C'est à l'administrateur système de prévoir le cas avec un processus de mise à jour spécifique et éventuellement d'isolation de l'application.

                      Ouais, ca va bien se passer ca! La bonne vieille philosophie de "si la machine se fait poutrer, c'est clairement la faute de l'utilisateur" si chère aux années 2000.

                      Dans le cas d'un serveur cela signifie une interruption des services hébergés

                      Tu les déploies comment au juste tes services, pour que le reboot d'une instance cause une interruption de service? Ca fait plus de 20 ans que ce problème est tres largement résolu, et accessible aux masses.
                      Si ya bien un endroit ou un reboot cause 0 problèmes, c'est typiquement sur des serveurs.

  • # Qui doit mettre à jour ?

    Posté par  (site web personnel, Mastodon) . Évalué à 5 (+2/-0).

    Je veux dire, j'ai un hébergement mutualisé, c'est mon hébergeur qui doit même à jour ou moi ?

    Je n’ai aucun avis sur systemd

    • [^] # Re: Qui doit mettre à jour ?

      Posté par  (site web personnel) . Évalué à 7 (+5/-0).

      Pour moi, sur un mutualisé, tu n'as pas accès à l'OS donc tu ne peux pas faire la mise à jour.

      Contrairement à un serveur dédié ou un vps sur lequel tu fais ton installation de php et du serveur web.

      Donc je penses que ton hébergeur l'a fait ou va le faire, si tu veux vérifier quelle version de php tu as, un simple script php te la donnera :

      <?php phpinfo() ?>

      S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

    • [^] # Re: Qui doit mettre à jour ?

      Posté par  . Évalué à 7 (+5/-0).

      Oui: dans 99,9% des cas et s'il est un tant soit peu sérieux, l'hébergeur s'en occupera promptement.
      Et si ça se trouve, il a posté une actu sur son site/blog à ce sujet.

      "Si tous les cons volaient, il ferait nuit" F. Dard

      • [^] # Re: Qui doit mettre à jour ?

        Posté par  (site web personnel, Mastodon) . Évalué à 4 (+1/-0).

        C'est pas encore le cas. Je viens d'ouvrir un ticket, ça ne mange pas de pain.

        Je n’ai aucun avis sur systemd

      • [^] # Re: Qui doit mettre à jour ?

        Posté par  (site web personnel, Mastodon) . Évalué à 5 (+2/-0).

        J'ai une réponse à mon premier ticket, qui ne mentionnait pas la vieillerie de la version de php :

        Concernant la vulnérabilité CVE-2026-109618, nous vous confirmons que des mesures de sécurité ont déjà été appliquées au niveau de notre infrastructure, notamment sur l'environnement PHP utilisé par cPanel/WHM.

        Les versions de PHP utilisées par les sites web étant indépendantes de celles de cPanel, elles conservent pour le moment leur configuration actuelle.
        Cela veut dire que le problème reste présent sur les sites indépendamment de nos services.

        Nous vous recommandons alors fortement de désactiver l'extension uploadprogress depuis votre interface cPanel, en vous rendant dans l'outil « Sélectionner une version de PHP », où il vous suffira de décocher uploadprogress.

        Je n’ai aucun avis sur systemd

        • [^] # Re: Qui doit mettre à jour ?

          Posté par  . Évalué à 7 (+6/-0).

          Je ne sais pas si ton comm appelait une réponse, mais comme tu mentionnais une vieille version de PHP pour ton SPIP, dans le doute je tente une réponse (au pire ça sert à rien, au mieux ça servira à quelqu'un)

          La marche a suivre est donc:
          - s'assurer que ton spip est bien à la dernière version (il y a encore eu un paquet de fix ces derniers jours)
          - passer sur PHP8.2 au minimum (mais EOL en fin d'année donc plus récent serait mieux) dans les réglages de cPanel
          - si pas possible de faire ça, désactiver ce que l’hébergeur t'indique faute de mieux (mais c'est une rustine)

          • [^] # Re: Qui doit mettre à jour ?

            Posté par  (site web personnel, Mastodon) . Évalué à 7 (+4/-0).

            Ça n’attirait pas spécialement de réponse, mais, effectivement, c'est utile. Merci. On peut compléter par cette discussion sur Discuter.SPIP qui déborde du cadre de SPIP puisque ça parle des hébergeurs. Et donc, la mise à jour est faite chez OVH.

            Et pour les mises à jour de SPIP (qui, ces derniers temps ont fini, effectivement, par devenir un poil fatigantes à suivre), il y un plugin en test, Autoupdate que j'ai installé (pour tester, justement) sur un de mes sites. On peut le compléter par MajPlugins qui est stable et qui fonctionne bien.

            Pour les gens chez O2Switch qui ne savent pas où ça se passe cette histoire de version de PHP. Il faut aller sur le CPanel, descendre sur Logiciels et aller sur Version de CPanel, ensuite on choisit la version dans un menu déroulant. La plus récente proposée de PHP est la 8.4.

            uploadprogress a, semble-t-il, été décoché par O2Switch. Je sais pas à quoi ça sert au fait.

            Je n’ai aucun avis sur systemd

  • # est-ce lié ?

    Posté par  . Évalué à 6 (+5/-0).

    Voici ce que je lis sur le canard local : https://c.ledauphine.com/science-et-technologie/2026/10/21/les-sites-de-plusieurs-prefectures-coupes-apres-la-detection-d-une-faille-critique

    Serait-ce lié au problème PHP ? Ils parlent d'une "mise en maintenance préventive de l'ensemble de ses sites internet exposés à une vulnérabilité critique de sécurité, annoncée il y a quelques heures par l'éditeur d'un composant logiciel générique, largement utilisé à travers le monde"

  • # pages perso free

    Posté par  (site web personnel) . Évalué à 9 (+7/-0).

    Un message de Laurent Frigault (de chez free) sur les newsgroup de free proxad.free.services.pagesperso :

    La version 8.5.12 vient d'être déployée sur tous les serveurs de la plateforme des Pages Perso de Free en remplacement de la version 8.5.11. C'est une upgrade qui fixe deux gros bugs de sécurité

    Pour info, sur un de mes comptes j'ai testé avec le .htaccess suivant :

    php85 1

    Et je vois bien la version 8.5.12.

    Donc si vous avez encore des comptes free pour de petites pages, vous pouvez passer sur cette version.

    S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.