Le 6 juin 2024, une CVE critique sort sur PHP : CVE-2024-4577. Score CVSS 9.8. Vecteur : exécution de code à distance via une mauvaise gestion des arguments en mode CGI. Affecte toutes les versions PHP 8.1, 8.2, 8.3 sous Windows mais aussi sur certaines configurations Linux mal isolées.
En clair : si la config est mauvaise, n’importe qui peut faire tourner du code arbitraire sur votre serveur. Pas de phishing, pas d’ingénierie sociale. Juste une requête HTTP bien formée.
Sur un mutualisé classique, le drame en 3 actes
Sur un hébergement mutualisé low-cost, voici ce qui se passe : le prestataire attend un “créneau de maintenance”. Il prévient ses 50 000 clients par mail. Il déploie le patch dans la nuit du week-end suivant. Si vous êtes chanceux, c’est sous 7 à 10 jours.
Pendant ces 10 jours, votre site est exposé. Aux scanners automatisés qui parcourent Internet à la recherche de cibles. Aux botnets qui exploitent les CVE quelques heures après leur publication.
Notre timeline sur la même CVE
06 juin 17:42 UTC ↳ CVE-2024-4577 publiée (NVD)
06 juin 17:55 UTC ↳ Détection automatique par notre agent
06 juin 18:10 UTC ↳ Validation humaine — patch confirmé applicable
06 juin 18:30 UTC ↳ Tests sur environnement de staging
06 juin 21:15 UTC ↳ Déploiement séquentiel sur les clusters
06 juin 21:48 UTC ↳ Tous les sites patchés — clients notifiés
Quatre heures, six minutes. Sans intervention manuelle requise des agences clientes. Sans downtime visible (Proxmox permet le live migration des VMs pendant qu’on patche les hôtes).
Pourquoi c’est possible chez nous
Trois raisons techniques, pas marketing :
- Bare metal Proxmox : on contrôle la stack de bout en bout. Pas de couche d’abstraction propriétaire qui retarde les patches.
- ZFS snapshots avant patch : si quelque chose se passe mal, on revient en arrière en 30 secondes. Donc on peut patcher vite sans peur.
- Cluster HA 3 nœuds : on patche un nœud, on bascule le trafic, on patche le suivant. Aucune interruption visible.
Le vrai sujet : la confiance
Un client agence ne devrait pas avoir à se demander si son hébergeur a appliqué un patch critique. Ça devrait être implicite. C’est pour ça qu’on envoie un rapport automatique après chaque patch de sécurité critique : ce qui a été appliqué, où, quand, et avec quelle vérification.
La sécurité, c’est pas juste avoir des firewalls. C’est aussi être réactif. Et la réactivité, ça se paye en architecture, pas en marketing.