View Issue Details

IDProjectCategoryView StatusLast Update
0000254e-comBoxExploitation des sitespublic2026-10-22 14:59
ReporterRobin ANCELIN Assigned Toaporaf  
PrioritynormalSeverityminorReproducibilityN/A
Status acknowledgedResolutionopen 
PlatformÉtablissement scolaireOSLinuxOS VersionAutre version
Summary0000254: Traitement de la faille PHP
Description

Bonjour,

Je souhaiterais savoir si vous avez pu prendre connaissance des vulnérabilités PHP signalées et si vous avez une estimation du délai nécessaire à leur traitement.

Merci d’avance pour votre retour.

Cordialement,

TagsNo tags attached.
Version ciblée
Quantité de mémoire vive (en Go)32
Machine virtuelleOui
Passage par un proxyOui
Qualité de la connexion InternetExcellente
Navigateur(s) éventuellement utilisé(s)Chrome, Edge
Avez-vous tenté de réinitialiser l'environnement ?Non
Moment où l'incident est survenuAutre

Activities

aporaf

2026-10-22 14:34

administrator   ~0001523

Bonjour,

Je cherche depuis hier la meilleure solution car PHP ne se met pas à jour depuis l'intérieur du conteneur. Sa version est celle de l'image !

Voici le contenu de l'issue (https://forge.apps.education.fr/e-combox/e-combox_dockerfile/-/work_items/104) que je mettrai régulièrement à jour :

Reconstruire les images telles quelles ne corrige pas PHP. Les images officielles WordPress, PrestaShop et Mautic n'installent pas PHP depuis les paquets Debian : elles le compilent à partir des sources. La mise à jour système (apt upgrade) faite lors de nos reconstructions met à jour Debian, mais pas PHP.
La version de PHP dépend uniquement de l'image officielle sur laquelle repose la nôtre. Il faut donc :

  • attendre que l'éditeur republie son image avec le PHP corrigé ;
  • les reconstruire en forçant le téléchargement de la nouvelle base.

L'étape 1 bloque dans certaines situations : seules certaines versions ont été republiées. Par exemple, aucune image WordPress 6.8 n'a été mise à jour, seulement wordpress:7.1.3.

Conséquences pour les sites :
Le changement d'image ne modifie ni le contenu, ni la version de WordPress, ni la base de données des sites : seul PHP change.

  • Sites existants. Au prochain redémarrage, le site utilise la nouvelle image. Ses fichiers, extensions, thèmes et données restent tels quels, car ils sont stockés à part. Un site en WordPress 7.1.0 reste en 7.1.0, puis passe en 7.1.3 par la mise à jour mineure automatique habituelle.
  • Nouveaux sites. Ils sont créés à partir de nos sites modèles, dans leur version actuelle, puis se mettent à jour automatiquement en version mineure. Ils bénéficieront de la mise à jour de PHP.
  • Mises à jour majeures de WordPress. Elles restent bloquées, comme aujourd'hui. Un site en WordPress 6.8 reste en 6.8 et ne reçoit que les correctifs de cette branche.
  • Versions 4.1 à 4.3. Le passage à PHP 8.2 peut provoquer des erreurs avec certaines extensions ou certains thèmes.

Deux gros problèmes :

  • Je ne peux rien faire (à priori) pour les sites issus des images 3.x car la version de Wordpress n'est pas compatible avec php 8.x et PHP ne met pas à jour les versions < 8.2.
  • Les modèles utilisent une image local qui contient le PHP vulnérable, et tous les sites créés à partir de lui aussi: même si on met à jour le PHP via un script dans les conteneurs, un redémarrage rebasculera sur l'ancienne version de PHP ==> Il faut impérativement les refaire et redémarrer les sites. je vais regarder si je peux faire ça via un script mais rien de sûr (et il y aura toujours un risque que le modèle ne fonctionne plus). Par ailleurs, ça ne sera pas possible pour les modèles dont la version de WordPress est n'est pas compatible avec, au moins, php 8.2.

Dans tous les cas, un script faisant l'état des lieux sera publié.

Où j'en suis actuellement :

Les images WordPress de l'e-comBox vont être reconstruites sur une base PHP corrigée, sans changer la version de WordPress des sites. La correction des failles PHP CVE-2026-109618 et CVE-2026-109619 est publiée pour les branches PHP 8.2 et 8.4, et l'image officielle wordpress:7.1.3 en profite.

  • Version 5.0 : correctif simple, sans risque pour les sites existants.
  • Version 4.4 : Correctif possible et à priori sans risque : en cours de test.
  • Versions 4.1 à 4.3 : correctif possible, mais il impose de passer de PHP 7.4 à PHP 8.2. Il est en cours de test avant toute diffusion.
  • Autres applications (PrestaShop, Mautic, SuiteCRM, Kanboard, HumHub) : vérification en cours, image par image.

Quand les images seront prêtres, il suffira de mettre à jour les images et de redémarrer les sites. Je ferai un script.

Je vous tiens au courant mais tout cela risque de prendre beaucoup de temps avant que tout ne soit prêt (j'espère avant la fin du week-end quand même). Refaire des images est un gros chantier (non sans risque) et de nombreux tests doivent être effectués. Et même avec ces tests, comme je ne peux pas savoir ce qui a été fait sur les anciens sites, je ne peux pas garantir à 100% de l'opérationnalité de ces derniers suite au passage à une nouvelle version de PHP.

Cordialement,

Robin ANCELIN

2026-10-22 14:59

reporter   ~0001524

Bonjour,

Merci pour ce retour détaillé et pour le travail en cours sur la résolution de ces vulnérabilités.

De notre côté, nous sommes actuellement sur la version 4.4 de l’e-comBox. Si le correctif en cours de test se confirme, cela devrait donc être plutôt rassurant pour notre infrastructure.
Nous prévoyons également de passer à la version 5 dans les prochaines semaines.

Merci de nous tenir informés de l’avancement et de la disponibilité des correctifs.

Cordialement,

Issue History

Date Modified Username Field Change
2026-10-22 10:37 Robin ANCELIN New Issue
2026-10-22 14:25 aporaf Assigned To => aporaf
2026-10-22 14:25 aporaf Status new => assigned
2026-10-22 14:34 aporaf Status assigned => acknowledged
2026-10-22 14:34 aporaf Note Added: 0001523
2026-10-22 14:59 Robin ANCELIN Note Added: 0001524