En bref : avec un serveur managé, le fournisseur assume une partie de la sécurité, en général le système d'exploitation, les paquets PHP et les services standard. L'application, les extensions, les accès et la responsabilité au regard de la protection des données restent le plus souvent à votre charge. Après PHP2Shell, vous devriez clarifier les deux par écrit : qu'a fait le fournisseur, et qu'est-ce qui relève encore de vous ?
Ce que « managé » signifie et ne signifie pas
Le terme n'est pas protégé. Un fournisseur entend peut-être par là seulement l'installation des mises à jour du système d'exploitation, un autre suit aussi le serveur web, PHP, la base de données et les sauvegardes. Certaines offres incluent une supervision 24 h/24, d'autres seulement un interlocuteur aux heures ouvrables.
C'est précisément dans une situation comme PHP2Shell que l'on voit la précision de la description des prestations. Les deux failles CVE-2026-109618 et CVE-2026-109619 se trouvent dans PHP lui-même. Que votre fournisseur entretienne PHP comme élément de sa plateforme ou que PHP soit considéré comme « votre logiciel » est précisé dans le contrat. Ne partez pas du principe que quelqu'un s'en occupe sûrement.
Sécurité d'un serveur managé : répartition typique des tâches
Le tableau suivant montre une répartition fréquente. Il ne remplace pas la lecture de votre contrat, mais aide à poser les bonnes questions.
| Domaine | Le plus souvent chez le fournisseur | Le plus souvent chez vous |
|---|---|---|
| Matériel, réseau, virtualisation | oui | non |
| Mises à jour du système d'exploitation | oui | non |
| Paquets PHP de la plateforme | souvent | s'ils sont installés par vous |
| Redémarrage de PHP-FPM et du serveur web | souvent | pour les services propres |
| Configuration PHP globale du serveur | souvent | pour les demandes particulières |
| CMS, boutique, extensions, code propre | non | oui |
| Comptes administrateur de l'application | non | oui |
| Sauvegardes | fréquemment | vérification de la restauration |
| Évaluation et notification des violations de données | non | oui |
| Surveillance des attaques | selon l'offre | selon l'offre |
Les cases floues sont le véritable risque. Là où vous devriez écrire « selon l'offre » ou « souvent », il manque une règle.
Les questions à poser dès maintenant
Envoyez à votre fournisseur une demande brève et factuelle. Demandez une réponse sous forme écrite, afin de pouvoir la présenter plus tard. Ces points devraient y figurer :
- Quelles versions de PHP tournent sur notre serveur, et sont-elles protégées contre CVE-2026-109618 et CVE-2026-109619 ?
- Depuis quand, et tous les processus PHP ainsi que le serveur web ont-ils ensuite été redémarrés ?
- La correction a-t-elle été appliquée sous forme de backport ? Si oui, quelle version de paquet le prouve ?
- Y a-t-il eu des indices de tentatives d'attaque ou de processus anormaux sur notre serveur ?
- Les journaux du serveur web sont-ils conservés à partir du 20 octobre 2026, et comment les obtenir ?
Un modèle rédigé figure sous Demander à l'hébergeur l'état du correctif. Le numéro de version affiché dans l'espace client n'est pas une preuve : avec les backports, il reste souvent inchangé, par exemple à 8.2.34.
Même si le fournisseur a corrigé PHP, votre application doit encore être contrôlée. Un correctif ne supprime pas les logiciels malveillants introduits avant la mise à jour et ne prouve pas que rien ne s'est produit.
Ce qui reste à votre charge
Votre part concerne surtout l'application. Vérifiez que le CMS, la boutique et les extensions sont à jour, supprimez les extensions qui ne sont plus utilisées et contrôlez la liste des administrateurs. Soyez attentif aux nouveaux fichiers dans les dossiers d'envoi, aux redirections étrangères et aux tâches planifiées inhabituelles dans l'application.
S'y ajoute l'aspect juridique. Si, lors d'un incident, des données personnelles tombent entre de mauvaises mains, c'est en règle générale votre entreprise, en tant que responsable du traitement, qui est tenue de notifier, et non le fournisseur. Celui-ci doit vous informer sans délai en tant que sous-traitant. Les grandes lignes sont expliquées dans Obligation de notification RGPD : 72 heures. Il s'agit d'une information générale, pas d'un conseil juridique ; le cas particulier doit être évalué par le délégué à la protection des données ou par des avocats.
Un autre point est souvent négligé : les logiciels que vous ou votre agence avez installés vous-mêmes sur le serveur managé, par exemple une version de PHP supplémentaire issue d'une source tierce, un conteneur ou un programme auxiliaire, ne relèvent généralement pas de l'entretien du fournisseur. Demandez donc aussi si le fournisseur sait ce qui tourne en dehors de la configuration standard. Et clarifiez qui mène l'enquête en cas de soupçon. De nombreux fournisseurs rétablissent la plateforme, mais n'examinent pas si des données ont été touchées et lesquelles. C'est pourtant précisément cette réponse qu'il vous faut pour évaluer d'éventuelles obligations de notification.
Améliorer les contrats pour l'avenir
Profitez de la situation pour fixer la répartition des tâches par écrit. Sont utiles des règles sur les mises à jour de sécurité, redémarrage compris, sur l'information en cas de failles critiques, sur la conservation et la remise des journaux et sur le soutien en cas d'incident. Demandez aussi si le fournisseur vous prévient activement ou si c'est à vous de vous renseigner.
Un serveur dédié sans suivi est l'alternative, mais il reporte tout le travail sur vous. Ce que cela implique est décrit dans Sécuriser soi-même un serveur dédié et un vServer.
Comment PHP SOS aide-t-il concrètement ?
- Nous lisons votre description des prestations et établissons une matrice des tâches qui fait apparaître les lacunes.
- Nous formulons les questions techniques à votre fournisseur et évaluons ses réponses.
- Nous examinons la partie applicative qui relève de vous à la recherche de traces et de composants obsolètes.
- Ce que le fournisseur ne couvre pas, nous le prenons en charge sur demande par un contrat de maintenance sécurité ou le complétons par une supervision de sécurité.
Questions fréquentes
Un serveur managé est-il automatiquement sécurisé ?
Non. Managé signifie que le fournisseur assume certaines tâches définies par contrat, le plus souvent le système d'exploitation et les services standard. L'application, les extensions, les accès et les logiciels propres restent fréquemment à votre charge.
Où est-il écrit de quoi mon fournisseur est responsable ?
Dans la description des prestations et les conditions contractuelles, souvent aussi dans un document de répartition des tâches. Pour les données personnelles, s'ajoute le contrat de sous-traitance. Si les mises à jour de sécurité ne sont pas clairement réglées, posez la question par écrit.
Dois-je quand même agir moi-même au sujet de PHP2Shell avec un serveur managé ?
Oui. Obtenez une confirmation que toutes les versions de PHP sont corrigées et que les processus ont été redémarrés. Recherchez en outre des traces dans votre application et clarifiez s'il existe une obligation de notification.
Qui déclare une violation de données si l'hébergeur a été concerné ?
En règle générale, c'est le responsable du traitement, c'est-à-dire votre entreprise, qui est tenu de notifier l'autorité de contrôle. L'hébergeur, en tant que sous-traitant, doit vous informer sans délai. Faites évaluer le cas particulier par votre délégué à la protection des données.