En bref : si le site de votre hôtel est piraté, il s'agit moins de la page d'accueil que de tout ce qui y est rattaché : le moteur de réservation intégré, la boutique de bons cadeaux, les formulaires de demande pour fêtes et séminaires. Vérifiez l'état des correctifs et les intégrations, sauvegardez les journaux et avertissez sobrement les clients si leurs données peuvent être concernées.
Quels systèmes PHP fonctionnent dans les hôtels et la restauration
Le site d'un hôtel ou d'un restaurant fonctionne le plus souvent sur WordPress ou un autre CMS PHP. Le moteur de réservation provient souvent de l'éditeur du logiciel hôtelier ou d'un channel manager et est intégré par script ou iframe. À côté, sur le serveur propre, fonctionnent fréquemment une boutique de bons cadeaux basée sur WooCommerce, des formulaires de demandes pour séminaires et mariages, des réservations de tables, des inscriptions à la newsletter et des offres d'emploi saisonnier.
C'est précisément le mélange de briques propres et externes qui rend l'hôtellerie vulnérable : le serveur propre n'a pas besoin de contenir les données de réservation pour mettre les clients en danger. Il suffit qu'il détermine vers où mène le bouton Réserver.
Quelles données de clients sont en jeu
Par les sites d'hôtels transitent noms, adresses, numéros de téléphone, dates de voyage et accompagnants. Les demandes contiennent souvent des souhaits particuliers comme des allergies, l'accessibilité ou des régimes alimentaires. De telles indications de santé relèvent des catégories particulières au sens de l'art. 9 du RGPD. Dans la boutique de bons cadeaux s'ajoutent des données de commande et de facturation.
Les données de cartes se trouvent en général chez le prestataire de paiement ou dans le logiciel hôtelier, pas sur le site web. Mais quiconque peut modifier le JavaScript de votre propre site peut aussi lire les saisies dans les formulaires ou envoyer les clients vers une page de paiement trompeusement authentique.
Les demandes de séminaires et d'événements viennent souvent d'entreprises et contiennent des listes de participants, des programmes et des budgets. Les demandes de mariage indiquent dates, nombre d'invités et noms de famille. De telles informations sont rarement perçues comme sensibles, mais elles ont de la valeur pour des tentatives de fraude ciblées, par exemple une fausse facture d'acompte juste avant la manifestation. Vérifiez donc si les demandes se trouvent durablement dans la base de données du site et si c'est nécessaire.
Site d'hôtel piraté : conséquences typiques pour l'exploitation
- Fausses pages de réservation et de paiement : des clients paient à des escrocs et en tiennent l'hôtel pour responsable.
- Messages de fraude ciblés : avec de vraies dates de voyage, de fausses demandes de paiement paraissent crédibles.
- Perte de réservations directes : un avertissement de Google ou une panne pousse les clients vers les portails de réservation, pour lesquels vous payez une commission.
- Avis : les clients escroqués le racontent publiquement, quel que soit l'endroit où se situait l'erreur.
Après un correctif, vérifiez aussi si l'intégration de votre moteur de réservation pointe toujours vers la bonne adresse. Un script modifié ou un lien redirigé passe à peine inaperçu au quotidien.
Qui est responsable : agence, éditeur de logiciel, hébergeur ?
| Brique | Généralement responsable | Question ouverte |
|---|---|---|
| Site de l'hôtel et boutique de bons cadeaux | Agence et hébergeur | Correctif PHP et redémarrage confirmés ? |
| Moteur de réservation | Éditeur du logiciel hôtelier | L'intégration est-elle inchangée ? |
| Logiciel hôtelier sur place | Éditeur de logiciel ou responsable informatique | Liens avec le site web ? |
| Boîtes de messagerie de la réception | Hébergeur ou responsable informatique | Redirections inconnues ? |
Dans les groupes hôteliers et les établissements en franchise s'ajoutent des directives centrales. Souvent, le siège exploite le site principal, tandis que certains établissements entretiennent leurs propres pages de bons cadeaux ou d'événements que personne ne surveille de façon centralisée.
Saisonniers, accès partagés et bons cadeaux
Dans l'hôtellerie, les équipes changent souvent. Les accès au site web, à la boutique de bons cadeaux et aux plateformes de réservation sont partagés à la réception et rarement modifiés quand quelqu'un part. Après un incident, tous ces accès devraient être renouvelés et, là où c'est possible, remplacés par des comptes personnels.
Un risque sous-estimé concerne les bons cadeaux. Quiconque a accès à la base de données de la boutique peut lire des codes de bons, modifier des valeurs ou créer ses propres codes, qui sont utilisés à la réception. Après un nettoyage, faites vérifier si des bons ont été créés ou modifiés sans pouvoir être rattachés à une commande. Un rapprochement avec votre comptabilité révèle généralement vite de telles anomalies.
Les premières heures après une alerte
- Faire confirmer par écrit par l'hébergeur que PHP est en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou corrigé et que tous les processus ont été redémarrés.
- Sans confirmation : remplacer le site par une page d'information avec le téléphone et un lien direct vers le moteur de réservation du fournisseur.
- Sauvegarder les journaux à partir du 20 octobre 2026 et vérifier les intégrations du moteur de réservation et des pages de paiement.
- Informer l'équipe de la réception afin qu'elle reconnaisse et consigne les questions suspectes de clients.
- En cas d'indices de fraude, avertir sobrement les clients. La page consacrée à la communication de crise propose des aides de formulation.
Comment PHP SOS aide-t-il concrètement ?
- Nous vérifions l'état des correctifs, le redémarrage et le mode d'exécution de votre serveur web et nous nous concertons avec l'agence et l'hébergeur.
- Nous contrôlons le site, la boutique de bons cadeaux et les intégrations à la recherche de JavaScript modifié, de redirections étrangères et de webshells et nous supprimons le code malveillant.
- Nous vérifions si des boîtes de messagerie ont reçu des règles de redirection que vous ne connaissez pas.
- Ensuite, sur demande, nous mettons en place une supervision de sécurité qui signale les modifications de fichiers et de scripts.
Questions fréquentes
Mon moteur de réservation est-il concerné par PHP2Shell ?
De nombreux moteurs de réservation sont exploités par leur fournisseur et seulement intégrés au site de l'hôtel. Le fournisseur est alors responsable de son serveur. Votre propre site reste néanmoins un risque, car un attaquant peut y modifier l'intégration ou rediriger vers une fausse page de réservation.
Des clients ont reçu d'étranges demandes de paiement. Cela a-t-il un lien avec le site ?
C'est possible, mais seule une vérification permet de le prouver. De tels messages peuvent aussi provenir de plateformes de réservation ou de boîtes de messagerie compromises. Conservez les messages, avertissez les clients concernés et faites vérifier le site, les boîtes de messagerie et les accès aux plateformes.
Puis-je mettre le site hors ligne en haute saison ?
Si PHP n'est pas prouvé corrigé, le BSI (office fédéral allemand de la sécurité des technologies de l'information) recommande de déconnecter temporairement les serveurs web du réseau. Une page d'information avec le téléphone et un lien direct vers le moteur de réservation du fournisseur maintient l'activité. Un site compromis à l'insu de tous coûte plus de confiance en saison que quelques heures de maintenance.