Deux failles du moteur, pas d’une application

CVE-2026-109618 naît dans la gestion des erreurs de mémoire épuisée de l’interpréteur : provoqué à distance, un épuisement laisse la requête abandonnée dans un état invalide que la procédure de fermeture relit. CVE-2026-109619 complète le tableau : un état global pointerait vers une mémoire déjà libérée, relue au fil des requêtes. Enchaînées, elles donnent une exécution de code à distance sans authentification, notée 9,8 CVSS 3.1 par la NVD. Le groupe PHP a corrigé le 21 octobre dans les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ; la CISA a inscrit le couple au catalogue KEV le 26 octobre pour exploitation réelle. La mesure de contournement session.upload_progress.enabled=0 ferme aussi une troisième variante apparue depuis.

Une exploitation confirmée hors des laboratoires

Palo Alto Networks a déclaré le 28 octobre une exploitation active de ses interfaces d’administration PAN-OS exposées à Internet : console web HTTPS et service API XML seulement, les interfaces de données n’étant touchées que si un profil d’administration leur est attaché. Aucune configuration particulière n’est nécessaire pour être à risque, écrit l’éditeur, qui épargne GlobalProtect portail, passerelle et Clientless VPN et voyait, au 30 octobre, chaque branche soutenue dotée de son hotfix. Les clients corrigés, comme ceux qui gardent l’administration hors d’Internet, ne sont pas touchés. L’entreprise Dream avait documenté quelques jours plus tôt une chaîne couplant PHP2Shell à Fragnesia (CVE-2026-46300, noyau Linux, ajoutée au KEV le 28 octobre) : une vingtaine de serveurs pris en main aux États-Unis, au Japon, à Taïwan et en Corée du Sud, dont trois gouvernementaux américains. Unit 42 dénombrait plus de 22,6 millions d’instances exposées potentiellement vulnérables.

Pourquoi les hôtels sont en première ligne

Sites vitrines, moteurs de réservation, espaces clients et back-offices reposent massivement sur PHP, souvent infogérés, rarement inventoriés. S’y ajoutent les appliances : standard téléphonique, contrôleur d’accès réseau, passerelle de messagerie, serveur de serrures embarquent une interface web d’administration, souvent bâtie en PHP, que le support distant laisse parfois ouverte sur Internet. C’est exactement ce que frappe l’exploitation confirmée de PAN-OS. Le contrôle d’accès réseau, ou NAC, décide quels équipements joignent le Wi-Fi clients, les réseaux opérationnels ou la bureautique : le maîtriser livre la carte du réseau de l’établissement, pas une machine.

Fournisseurs : qui est confirmé, qui est présumé, au 30 octobre 2026

• Mitel. L’avis MISA-2026-0008, révision 6.0 du 28 octobre, confirme MiVoice 5000 en R8.4 et antérieures, corrigées par SecurityPatch_R8.X_20, OpenScape Branch et OpenScape SBC jusqu’à V11R3.4.3, MiContact Center Enterprise jusqu’à 9.8 SP0 FP1 et MiVoice Connect jusqu’à R20.0 SP2, correctif ou contournement selon les lignes. Unify Phone et CloudLink, les services cloud exploités par Mitel, sont déclarés non concernés. L’éditeur affiche un bandeau « PHP Security Issue : Some Mitel sites temporarily blocked », mesure provisoire pendant l’évaluation. L’avis frangin MISA-2026-0010 couvre la faille du décodeur Brotli CVE-2026-111497, surnommée node2shell, mais épargne MiVoice 5000.
• HPE Aruba ClearPass Policy Manager. L’avis HPESBNW05171, révision 2 du 23 octobre, déclare pleinement affectées les versions 6.14.1 et antérieures comme 6.11.16 et antérieures. Piège : la montée de version ne suffit pas, il faut poser le hotfix PHP dédié, publié depuis pour les deux branches. HPE demande de retirer portails invités et interfaces d’administration de l’accès public en attendant. Les autres produits Aruba Networking ne sont pas connus comme touchés.
• Palo Alto Networks PAN-OS. Confirmé et activement exploité sur les consoles exposées ; hotfixes achevés au 30 octobre pour toutes les branches soutenues.
• Barracuda. L’Email Security Gateway est déclaré non concerné, soit la passerelle de messagerie la plus courante en hôtellerie ; des correctifs sont sortis pour la Backup Service Appliance (micrologiciel 6.7.00), le Firewall Secure Connector (3.1.2), SecureEdge et Firewall Insights, et les services cloud sont annoncés traités. La troisième faille PHP du moment, CVE-2026-115560, ne touche aucun produit de l’éditeur ; le volet hébergement web est détaillé dans notre fiche CVE-2026-109618.
• dormakaba. L’avis DKSA-26-23-101 du 23 octobre déclare expressément non concernées toutes les gammes exos 9300, MATRIX, evolo, exivo, resivo, B-COMM, skyra, EntriWorX, Keyscan, Ambiance et Community. Le risque résiduel vise le PHP exploité par l’établissement lui-même, hors du périmètre de l’avis.
• À présumer exposé : tout le reste du PHP. Toute interface maison, portail d’intégrateur ou site sur PHP 8.2 à 8.5 non corrigé est dans le périmètre, et PHP 8.1 et antérieurs, hors maintenance, ne seront jamais corrigés. Faute de position officielle, un produit se présume concerné jusqu’à preuve écrite du contraire.

Que faire, dans l’ordre

1. Inventorier le PHP système par système et poser à l’intégrateur, par écrit, les deux questions qui comptent : quelle version de micrologiciel ou de PHP tourne, et l’interface d’administration est-elle joignable depuis Internet. Réponse écrite, établissement par établissement.
2. Corriger au build près, celui que l’avis nomme : SecurityPatch_R8.X_20 pour MiVoice 5000, hotfix PHP sur 6.14.1 ou 6.11.16 pour ClearPass, hotfix de branche pour PAN-OS, PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 pour les sites, mesure de contournement activée en attendant.
3. Administration jamais sur le WAN : adresses internes de confiance voire machine relais dédiée pour Palo Alto Networks, VLAN dédié pour HPE. VPN, machine relais, compte constructeur par canal sécurisé, tout sauf le port ouvert.
4. Segmenter : plan d’administration séparé des VLAN clients et opérationnels, portail invités isolé dans sa zone. Une brèche sur une interface PHP ne doit ouvrir ni le réseau, ni les étages.
5. Chercher les traces : fichiers ajoutés récemment dans les racines web, processus inattendus du worker, trafic sortant anormal, signatures des web shells. Le KEV impose échéance et investigation aux agences fédérales américaines ; même discipline à s’imposer sur les systèmes critiques de l’hôtel.
6. Faire attester par les hébergeurs et exploitants d’appliances les builds déployés, propriété par propriété, par écrit.

Vérifier son exposition en pratique

Trois vérifications sans équipe de sécurité. Depuis l’extérieur : noter ce qui répond sur les adresses publiques de l’établissement et fermer sans attendre toute page de login d’administration qui n’est pas le site de réservation. En interne : exiger de chaque mainteneur la version exacte installée et la liste écrite des ouvertures pratiquées pour le support distant. Chez les éditeurs : veiller Mitel, HPE, Barracuda et Palo Alto Networks, ces avis sont mis à jour presque chaque jour. Quand le socle du web prend l’eau, les victimes sont les bâtiments où mille petites interfaces s’exposent en silence.

Un écosystème qui se documente

Le constat le plus net du rapport Trustwave 2025 est culturel : dans les forums underground, les groupes Telegram et les places de marché privées, des cybercriminels collaborent, partagent des guides et échangent des accès sur l’exploitation des grandes plateformes de réservation. Des tutoriels détaillés circulent sur l’insertion de données de cartes volées dans des réservations actives, le contournement des vérifications et l’évitement de la détection. Le rapport chiffre aussi la montée des tentatives de force brute : elles ont augmenté d’environ 14 % depuis le précédent rapport de Trustwave sur le secteur, une catégorie qui inclut le bourrage d’identifiants, nourri par les dumps massifs quotidiens et la réutilisation des mots de passe.

L’automatisation vue par Imperva et Visa

Imperva, dans son Bad Bot Report 2023, établit que 37,4 % du trafic web des sites de voyage provenait de bots malveillants, un niveau de retour à l’avant-pandémie après deux années d’accalmie relative. Le rapport détaille comment les bots abusent de la logique métier des moteurs de réservation, du scraping de prix à la prise de compte, et recense la fraude à la carte bancaire parmi les usages fréquents des bots.

Visa, dans son Biannual Threats Report de l’automne 2024, confirme par le versant des réseaux : l’énumération, c’est-à-dire le test automatisé et programmatique d’éléments de paiement via des transactions électroniques pour reconstituer un numéro de carte, un cryptogramme ou une date d’expiration, reste parmi les premières menaces pour l’écosystème, avec des fraudes en cascade significatives. Sur les six mois étudiés, la région américaine a concentré 58 % des transactions d’énumération côté émetteurs, en hausse de 16 % sur un an. Le rapport documente également une affaire de marchand de voyage en ligne dont la page de paiement a été manipulée : des fichiers JavaScript déposés avec des identifiants volés remplaçaient l’URL du processeur de paiement par une fausse page de contrôle qui soutirait les données de paiement des clients.

Le mécanisme, lu côté défense

Le test de cartes suit une grammaire simple à reconnaître sans la détailler opérationnellement. Un moteur de réservation accepte en théorie un volume de transactions proportionné à son activité réelle. Des vagues de micro-autorisations, souvent de quelques centimes, avec des numéros qui se suivent ou des paires carte/cryptogramme variées au sein d’une même adresse IP ou d’une plage voisine, signalent une validation en série de fichiers de cartes volées. Deux variantes préoccupent les équipes de fraude : la validation directe sur la page de paiement, et l’injection d’une carte volée dans une réservation déjà existante, ce que les guides décrits par Trustwave cherchent précisément à rendre invisible en imitant le comportement normal d’un client qui complète ou modifie un séjour.

La conséquence côté établissement est double. D’abord financière et contractuelle : chaque transaction refusée massivement expose à des frais d’interchange, à un déclassement par le réseau, voire à des sanctions si le taux de fraude dépasse les seuils contractuels. Ensuite opérationnelle : une rafale d’autorisations peut saturer le moteur, ralentir la page pour les vrais clients, et brouiller les journaux au moment précis où un skimming réel chercherait à s’y nicher.

Un précédent documenté : le moteur IRM Ng

Le rapport de Bitdefender publié en septembre 2023, « Booking Engine Security Revisited », a documenté une attaque d’un autre type mais sur la même surface. Lors d’une enquête menée à partir de novembre 2022 sur le serveur d’un resort américain, les chercheurs ont isolé XModule, un module IIS malveillant conçu pour l’e-skimming, c’est-à-dire le vol de données de cartes et de mots de passe par injection de code dans un fichier JavaScript du moteur de réservation IRM Next Generation de Resort Data Processing. L’attaque initiale sur ce moteur avait été découverte en 2021. Cinq failles ont reçu des identifiants publics : CVE-2023-39420, CVE-2023-39421 et CVE-2023-39422 pour des identifiants codés en dur dans des composants de l’application, CVE-2023-39423 pour une injection SQL, et CVE-2023-39424 pour une injection dans un composant de téléversement de fichiers. Bitdefender indique avoir tenté pendant plus de 90 jours de joindre l’éditeur sans réponse avant de publier.

Ce précédent compte pour la lecture du risque : la même page de paiement qui attire les tests de cartes peut aussi être percée pour capter les données à la source.

Ce que les établissements peuvent surveiller

Les rapports cités convergent vers les mêmes réflexes. Côté détection : seuils d’alerte sur le volume d’autorisations par minute, suivi du ratio entre consultations et réservations, journalisation et corrélation des adresses IP, contrôle renforcé sur les modifications de carte dans les réservations existantes. Côté comptes : authentification multifacteur sur les accès des plateformes de réservation, simulations de hameçonnage pour les équipes, surveillance du dark web lorsque la marque de l’établissement apparaît dans des discussions de fraude, mesure que Trustwave recommande explicitement pour anticiper une exploitation du portail de réservation. Côté relations : vérifier l’état de sécurité des moteurs et passerelles auprès de leurs éditeurs, le cas IRM Ng montrant qu’un éditeur injoignable pendant trois mois fait partie du risque.

Le phénomène ne s’est pas traduit par un naufrage médiatique unique du secteur, et c’est justement le signal à retenir : l’économie du test de cartes fonctionne par usure, une vague permanente sur des milliers de petits établissements plutôt qu’un seul grand titre de presse.

2012: un port de service sans authentification

Les serrures électromécaniques de la série HT d’Onity, introduites en 1993, équipent plus de quatre millions de portes, selon les chiffres présentés à Black Hat. Elles possèdent un port destiné au programmeur portable utilisé par le personnel pour configurer la serrure. Cody Brocious a démontré que la communication sur ce port n’est pas authentifiée et donne un accès direct à la mémoire de la serrure. Avec cette lecture, un attaquant peut ouvrir une porte, créer des passes et même des cartes de programmation valables pour tout un établissement, comme le résumait ZDNet à partir du document de présentation.

La particularité du système tenait à son « sitecode », un identifiant partagé entre toutes les serrures d’une même propriété. La présentation Unsaflok donnée à DEF CON 32 en 2024 confirme la persistance de ce dessin: le port de programmation permet de lire la mémoire de la serrure, y compris le sitecode. Concrètement, une seule clé compromise peut donc dégénérer en maîtrise de toutes les portes.

La réponse d’Onity: un bouchon et des vis

Sur le moment, l’éditeur a minimisé. Le 25 juillet 2012, au lendemain de la démonstration, Onity déclarait comprendre que la méthode était « peu fiable et complexe à mettre en œuvre », tout en promettant une mise à jour du micrologiciel. Aucune CVE n’a jamais été attribuée à cette faille. Le correctif réellement déployé a été mécanique: un capuchon inséré dans le port du programmeur, assorti d’une vis TORX de sécurité sur le couvercle de batterie. Pour une solution définitive, Onity proposait le remplacement du circuit imprimé ou des serrures, aux frais des hôtels.

Le chercheur parlait pour sa part d’une dizaine de millions de serrures installées dans le monde. Ce chiffre reste son estimation, Onity n’ayant jamais confirmé la taille de son parc. Le parc documenté par la BBC, lui, se compte en millions de portes, ce qui suffisait à donner à l’affaire une ampleur industrielle.

L’exploitation criminelle a suivi

L’histoire a vite quitté les amphithéâtres de hackers. Des cambriolages commis dans plusieurs hôtels du Texas, dont l’Hyatt de Houston, ont été reliés à cette technique. La porte n’était ni forcée ni crochetée, et la mémoire de la serrure ne montrait aucune carte de clé légitime utilisée. Un homme, Matthew Allen Cook, a été arrêté et inculpé pour l’effraction de l’Hyatt. L’établissement a durci ses portes en remplissant le trou du port avec de la colle. D’autres chercheurs ont raffiné l’outil: Matt Jakubowski, de Trustwave SpiderLabs, a logé toute l’électronique d’attaque dans un simple feutre de tableau blanc. Les courtiers en assurance s’attendaient alors à être « durement touchés » au fur et à mesure que la technique se diffusait.

SALTO: la même exposition, côté logiciel

Le dossier Onity semblait clos avec ses capuchons et ses cartes mères. Le contrôle d’accès hôtelier a pourtant reproduit le même schéma côté serveur. SALTO ProAccess SPACE 5.4.3.0, la console qui pilote les serrures connectées et la fabrication des cartes, cumule quatre vulnérabilités publiées fin 2019 dans les bases publiques: CVE-2019-19457 (injection XSS), CVE-2019-19458 (traversal de répertoire dans la fonction Data Export), CVE-2019-19459 (écriture arbitraire de fichiers) et CVE-2019-19460 (mauvaises permissions par défaut).

Le mécanisme le plus grave enchaîne les deux dernières. La traversal permet d’atteindre des emplacements interdits, et l’écriture arbitraire autorise un attaquant à déposer un fichier n’importe où sur le serveur, par exemple sous la racine du site web ou dans les scripts de démarrage automatique. Résultat: l’exécution de commandes arbitraires sur le serveur de contrôle d’accès. La quatrième faille aggrave l’ensemble: le serveur web de ProAccess SPACE tourne par défaut en tant que service Windows avec les privilèges SYSTEM, à l’envers du principe du moindre privilège. Une compromission de ce serveur, qui détient les identifiants et les données de fabrication des cartes, équivaut à terme à la maîtrise des portes qu’il administre.

Ce que les exploitants devraient en retenir

Ces deux épisodes, séparés de sept ans, dessinent des leçons durables. D’abord, inventorier les générations de matériel: les parcs hôteliers mélangent souvent des serrures anciennes, des capuchons de fortune et des modèles récents, et les retrofits Onity (capuchon ou carte mère) ne sont pas nécessairement achevés partout. Ensuite, traiter le serveur de contrôle d’accès comme un système sensible: isolation réseau, application des correctifs de l’éditeur, et exécution du service web avec des privilèges réduits plutôt que SYSTEM.

La recherche récente élargit encore le périmètre. La présentation Unsaflok de DEF CON 32 prolonge cette généalogie jusqu’aux serrures dormakaba Saflok, présentes sur 3 millions de portes dans 13 000 établissements répartis dans 131 pays, et rappelle un épisode comparable chez VingCard traité avec ASSA ABLOY. La sécurité d’une chambre d’hôtel se joue désormais à trois étages: la serrure elle-même, le logiciel qui la pilote, et la carte qui les relie. Tant que ces trois couches ne sont pas auditées comme n’importe quel serveur de paiement, le port de service de 2012 continuera de payer.

Les faits

Kr00K affecte les puces Wi-Fi de type FullMac de Broadcom et Cypress, intégrées dans des téléphones, tablettes, ordinateurs portables, enceintes connectées, liseuses et bornes. Les produits concernés couvrent, entre autres, les marques Apple, Amazon, Asus, Dell, Google, HP, Huawei, Lenovo, Microsoft et Samsung, ainsi que le Raspberry Pi 3 et des routeurs d’Asus ou de Huawei. La faille touche aussi bien le WPA2-Personal que le WPA2-Enterprise, dès lors que la confidentialité des données repose sur le chiffrement AES-CCMP.

Les chercheurs d’ESET ont présenté la faille publiquement en février 2020, en marge de la RSA Conference de San Francisco. Ils la rattachent à la descendance des travaux KRACK de 2017 : Kr00K s’est d’abord manifestée comme l’une des causes possibles de la « réinstallation » d’une clé entièrement nulle observée dans leurs tests.

Le mécanisme, expliqué à un responsable sécurité

Le WPA2 (Wi-Fi Protected Access 2) négocie les clés de session au moyen d’une poignée de main à quatre voies. L’une de ces clés, la clé temporelle de 128 bits, chiffre trame par trame les données échangées entre le client et le point d’accès.

Quand un appareil quitte un réseau, en cas d’itinérance, d’interférence ou d’extinction du Wi-Fi, la session est rompue par une déassociation et la clé temporelle est effacée de la mémoire de la puce, ce qui est normal. L’anomalie est ailleurs : les trames déjà prêtes à être émises et restées dans la mémoire tampon d’émission de la puce sont alors chiffrées avec une clé entièrement nulle avant d’être transmises dans les airs. Une clé nulle rendant le déchiffrement immédiat, toute personne à portée radio qui capture ces trames en récupère des fragments en clair.

Trois détails déplacent le curseur du risque pour un défenseur.

Le premier : la déconnexion peut être forcée. Les trames de gestion de déassociation ne sont ni authentifiées ni chiffrées, si bien qu’un attaquant à portée radio peut déclencher le comportement à volonté sur une cible choisie, en répétant les déconnexions pour accumuler les fragments. Ars Technica, qui a couvert la divulgation, chiffre ce volume à plusieurs kilo-octets de données réémises à chaque déconnexion.

Le second : un client à jour n’est pas à l’abri. ESET le souligne dans son article de recherche, un appareil client patché connecté à un point d’accès vulnérable voit les données transmises par celui-ci rester déchiffrables. Autrement dit, la maîtrise individuelle n’y change rien, la surface d’attaque se reporte sur l’infrastructure, précisément le point d’accès.

Le troisième : la fuite ne se limite pas aux échanges déjà sensibles. Des identifiants de navigation, comme les requêtes DNS ou le nom indiqué par le SNI des sites consultés, peuvent apparaître dans les fragments récupérés même lorsque le site visité est en HTTPS.

Le vrai sujet : la fraîcheur du micrologiciel des bornes

À la divulgation, les correctifs étaient disponibles pour tout ou partie des appareils concernés, mais personne ne savait combien les avaient installés, et Ars Technica notait que les routeurs et points d’accès restent souvent non corrigés indéfiniment. C’est ce point qui rend l’histoire toujours lisible pour un hôtel, analyse que nous signalons comme telle.

D’un côté, la flotte d’appareils des clients, smartphones, tablettes et ordinateurs portables, se renouvelle tous les deux ou trois ans et reçoit des mises à jour automatiques. De l’autre, le parc Wi-Fi de l’établissement, souvent acheté par tranches successives, déployé par des intégrateurs et maintenu au mieux des cycles d’exploitation, peut aligner des modèles vieux de cinq à huit ans. Un attaquant passif posté dans un hall ou une salle de conférences n’a rien à installer sur les terminaux : il lui suffit d’écouter les trames émises par une borne non corrigée. Le risque classique du faux point d’accès, le réseau qui imite le nom du réseau de la conférence, s’ajoute à ce tableau, mais Kr00K rappelle qu’une écoute fonctionne aussi sans leurrer personne.

Que vérifier

Premièrement, inventorier les points d’accès par marque, modèle et version de micrologiciel, puis demander au fabricant ou à l’intégrateur la confirmation écrite que le correctif Kr00K est appliqué. Deuxièmement, suivre le cycle de vie de chaque modèle et remplacer sans attendre ceux sortis de support, faute de correctifs à venir. Troisièmement, séparer le réseau clients des réseaux opérationnels et conserver la règle simple : le chiffrement de bout en bout (HTTPS, TLS) protège le contenu des échanges, Kr00K ne casse pas TLS, il expose des fragments et des métadonnées quand la couche sans fil se dérègle. Quatrièmement, inscrire la fraîcheur du micrologiciel du parc sans fil dans l’audit annuel, au même titre que la migration vers WPA3, qui durcit la protection des trames de gestion et réduit la capacité d’un attaquant à forcer les déconnexions.

Kr00K n’a, à notre connaissance, donné lieu à aucune exploitation documentée contre un hôtel. Elle reste un cas d’école de la dette de micrologiciel : une faille payée cher par les fabricants de puces, et dont l’addition se règle borne par borne, établissement par établissement.

Les faits, dans l’ordre

Le 30 novembre 2018, Marriott annonce que la base de réservations Starwood a été consultée sans autorisation. L’alerte vient d’un outil de sécurité interne le 8 septembre 2018 ; l’enquête établit un accès non autorisé au réseau Starwood depuis 2014 ; le 19 novembre, Marriott parvient à déchiffrer les données extraites et chiffre l’ampleur : jusqu’à environ 500 millions de clients, dont environ 327 millions avec nom, adresse, téléphone, courriel, numéro de passeport, compte Starwood Preferred Guest, date de naissance, sexe et dates de séjour, selon le communiqué officiel. L’intrusion précède le rachat de Starwood par Marriott en 2016.

Une deuxième fuite est annoncée par Marriott le 31 mars 2020 : environ 5,2 millions de clients touchés, à partir des identifiants de deux employés d’un établissement franchisé, l’activité débutant à la mi-janvier et l’intrusion étant identifiée vers la fin février. Ni cartes bancaires, ni passeports, ni mots de passe dans ce lot.

Un point technique aggravant n’a été rendu public que le 17 avril 2024, dans une mise à jour du communiqué de 2018 : Marriott pensait les numéros de carte et certains numéros de passeport protégés par un chiffrement AES-128 ; l’entreprise a finalement établi qu’ils l’étaient par la fonction de hachage SHA-1, nettement plus faible.

Le régulateur britannique frappe fort

Le 30 octobre 2020, l’Information Commissioner’s Office, l’autorité britannique de protection des données, inflige à Marriott une amende de 18,4 millions de livres pour manquements au RGPD, portant sur jusqu’à 339 millions de clients, dont environ 7 millions de fiches au Royaume-Uni, selon la BBC. Le montant proposé en 2019 s’élevait à 99 millions de livres ; la réduction reflète notamment les progrès constatés après l’incident. La commissaire Elizabeth Denham a résumé le grief : des millions de personnes ont vu leurs données exposées par la faute de Marriott.

Le volet américain : 344 millions de clients et un ordre de longue haleine

Le 9 octobre 2024, la FTC annonce un accord-cadre : Marriott et sa filiale Starwood devront mettre en place un programme de sécurité de l’information complet pour solder des accusations de sécurité défaillante ayant conduit à trois fuites entre 2014 et 2020, touchant plus de 344 millions de clients dans le monde. Marriott accepte en parallèle de verser 52 millions de dollars à 49 États et au district de Columbia. L’accord prévoit un lien de suppression des données personnelles pour les clients américains et la restauration des points de fidélité volés sur demande. L’ordonnance est devenue définitive le 20 décembre 2024, avec en outre une politique de rétention limitant la conservation des données à la durée raisonnablement nécessaire, selon la FTC.

La plainte fédérale dessine un tableau de défaillances internes cumulées : contrôles de mots de passe, de droits d’accès et de pare-feu insuffisants, absence de segmentation réseau, logiciels non corrigés, journalisation et supervision inadéquates, authentification multifacteur déficiente. La FTC ne disposait pas, dans ce dossier, du pouvoir d’infliger des sanctions civiles, d’où le rôle des États.

Ce que l’hôtellerie doit en retenir

D’abord la géographie du risque : l’intrusion de 2014 dormait dans le réseau d’une société rachetée deux ans plus tard. Une acquisition sans audit de sécurité profond, c’est un passif hérité, et la FTC a explicitement rendu Marriott responsable des pratiques des deux marques après 2016. Ensuite le modèle franchise : la fuite de 2020 est partie des identifiants de deux employés d’un établissement franchisé, pas du réseau central.

Enfin la durée de vie des données : numéros de passeport et identités complètes ne s’échangent plus seulement sur les forums de cartes bancaires, ils alimentent l’usurpation d’identité pendant des années. La leçon résumée par les deux dossiers régulateurs est la même : collecter moins, segmenter, surveiller, et traiter la sécurité d’un réseau repris en main comme un chantier du premier jour, pas du lendemain de la signature.

Unsaflok, les faits

La technique est le travail de Lennert Wouters, chercheur en sécurité matérielle au groupe COSIC de l’université KU Leuven, et d’Ian Carroll, chercheur indépendant et fondateur du site Seats.aero, épaulés par une équipe plus large. Leur recherche a commencé en août 2022 dans le cadre d’un événement de bug bounty organisé par des hôtels et casinos de Las Vegas en marge du DEF CON 30. Ils ont signalé les failles à Dormakaba en septembre 2022, remis les détails techniques complets en novembre 2022, et tenu au moins treize réunions avec l’éditeur jusqu’à la divulgation coordonnée de mars 2024. Les premiers hôtels ont été corrigés à partir de novembre 2023. À la date de divulgation, environ 36 % des serrures concernées étaient à jour ou remplacées, un chiffre que les chercheurs confirmaient toujours en août 2024, alors que les modèles les plus courants, Saflok MT et RT Plus, équipent une grande partie des parcs.

Le mécanisme, expliqué côté défense

Le principe, tel que les chercheurs et Wired le décrivent publiquement, tient en quelques phrases et s’apprécie en termes de défense. Une attaque ne passe par aucun système d’information de l’hôtel : elle commence par la lecture d’une seule carte de la propriété visée, y compris une carte expirée jetée dans une boîte de départ express. Avec un lecteur-écriteur RFID d’environ 300 dollars, l’attaquant fabrique une paire de cartes forgées ; la première modifie une zone de données de la serrure, la seconde l’ouvre, et cela fonctionne sur toutes les portes de l’établissement. « Deux impulsions rapides et nous ouvrons la porte », résume Lennert Wouters.

Trois propriétés font l’ampleur du risque pour un hôtel. D’abord, la vulnérabilité combine les faiblesses connues du protocole MIFARE Classic et une fonction de dérivation de clés propre à Dormakaba ; les chercheurs estiment, slides du DEF CON 32 à l’appui, que le système était vulnérable depuis 1988, les cartes à bande magnétique reprenant le même format de données. Ensuite, ces serrures fonctionnent hors ligne, sans journal consultable en temps réel à la réception : une porte ouverte par carte forgée n’alerte rien ni personne. Enfin, le pêne dormant contrôlé par la serrure à carte n’offre pas de protection supplémentaire ; les chercheurs le disent explicitement, il peut être rétracté par une carte malveillante, et seul un dispositif mécanique indépendant, comme un verrou à chaîne, dissuade encore une entrée. Dormakaba, interrogé par Wired, indique ne pas connaître d’utilisation de la technique en conditions réelles. C’est une déclaration du fabricant, invérifiable de l’extérieur, et les chercheurs répondent que l’absence de trace ne prouve pas l’absence d’usage : « il est peu probable que nous soyons les premiers à avoir trouvé cela. »

La backdoor des cartes MIFARE

En août 2024, Philippe Teuwen, chercheur chez Quarkslab, publie avec l’article scientifique IACR ePrint 2024/1275 une découverte de nature différente, plus brutale encore. En soumettant à des tests automatiques la puce FM11RF08S du fabricant shanghaïen Shanghai Fudan Microelectronics, une variante « compatible MIFARE Classic » sortie en 2020 et présentée comme résistante aux attaques connues, il découvre une backdoor matérielle permettant de s’authentifier avec une clé inconnue. Pire : la clé secrète de cette backdoor est commune à toutes les cartes FM11RF08S existantes. Une clé en main, quelques minutes de proximité avec une carte suffisent pour en compromettre toutes les clés internes, même correctement diversifiées, donc la cloner. Une backdoor analogue, protégée par une autre clé elle aussi commune, a été retrouvée dans la génération précédente FM11RF08, sur des cartes datant d’au moins novembre 2007, et jusque dans d’anciennes puces NXP et Infineon. Quarkslab a retrouvé ces cartes dans de nombreux hôtels aux États-Unis, en Europe et en Inde, souvent à l’insu des établissements, l’origine réelle de la puce n’apparaissant pas sur le badge. Le chercheur ajoute qu’un acteur positionné dans la chaîne d’approvisionnement pourrait mener ces attaques instantanément et à grande échelle, et le protocole MIFARE Classic reste, selon ses mots, « intrinsèquement cassé » quelle que soit la carte.

Corriger, détecter, cohabiter

La remise à niveau d’un parc Saflok est un chantier lourd : toutes les serrures reçoivent une mise à jour logicielle ou sont remplacées, toutes les cartes clients sont réémises, les logiciels de réception et les encodeurs sont changés, et les intégrations tierces, ascenseurs, parkings, systèmes de paiement, demandent parfois des travaux supplémentaires. Pour un client qui veut savoir, le site du projet donne un repère simple : si la carte remise est une MIFARE Ultralight C et non une MIFARE Classic, l’établissement est probablement passé par la mise à jour, distinction vérifiable avec l’application gratuite NFC Taginfo de NXP. Visuellement, rien ne distingue une serrure corrigée d’une serrure vulnérable.

À deux ans de la divulgation, le parc corrigé reste une minorité, et les recherches de Quarkslab rappellent que la question dépasse un fabricant : les cartes d’accès sans contact héritées sont un actif à inventaire, origine des puces comprise. En attendant, les conseils des chercheurs restent valables pour les voyageurs dans un hôtel non corrigé : verrouiller la chaîne, se méfier du seul pêne dormant, et ne rien laisser de précieux en chambre.

Le chef d’orchestre de la réception

Un PMS, property management system, ou en français logiciel de gestion hôtelière, est le cœur informatique d’un établissement: arrivées et départs, profils et coordonnées des clients, tarification, facturation, et l’essentiel des interfaces avec les autres systèmes, de la serrure connectée au téléphone de chambre. OPERA, édité par Oracle Hospitality, en est une des variantes les plus répandues dans les chaînes internationales. Une faille sur ce niveau de la pile ne concerne donc pas un module périphérique: elle touche le registre central de l’exploitation.

CVE-2018-2957: tout lire sans compte

La fiche NVD publiée le 18 juillet 2018 décrit une vulnérabilité du composant Logging d’Oracle Hospitality OPERA 5 Property Services, version 5.5.x. Elle est qualifiée d’aisément exploitable: un attaquant non authentifié, avec un simple accès réseau en HTTP, peut compromettre le système et obtenir un accès complet à toutes les données accessibles par OPERA. Le score CVSS 3.0 de 7,5 reflète un impact total sur la confidentialité. Traduit en langage hôtelier: réservations, noms, coordonnées, séjours, depuis Internet, sans identifiant ni mot de passe.

Publié le même jour, CVE-2018-3014 vise le composant Reports de la même version 5.5.x. Elle exige un privilège faible, mais débouche aussi sur un accès complet aux données accessibles par OPERA, pour un score CVSS de 6,5. Les deux fiches décrivent des failles « aisément exploitables » sur des interfaces HTTP exposées sur le réseau.

CVE-2023-22087: la prise de contrôle

Le 17 octobre 2023, la base NVD publie CVE-2023-22087, corrigée par la Critical Patch Update d’Oracle d’octobre 2023. Cette fois, la composante atteinte est « Opera » elle-même, sur la version 5.6. Un attaquant réseau doté d’un privilège faible peut, là encore via HTTP, aboutir à la prise de contrôle complète d’OPERA 5 Property Services. Le score CVSS 3.1 atteint 8,8, avec impact sur la confidentialité, l’intégrité et la disponibilité. La classification ajoute une précision de taille: la CISA-ADP range la faille sous CWE-306, « Missing Authentication for Critical Function », une fonction critique à laquelle manque l’authentification.

Le profil de ces deux époques est le même à cinq ans d’écart: des briques logicielles conçues pour un réseau interne de propriété, exposées en HTTP, dont certaines fonctions critiques se passent d’authentification ou s’en contentent d’une trop faible.

Un risque documenté, pas une fuite avérée

À ce jour, aucun cas public d’exploitation de CVE-2018-2957 contre un hôtel identifié n’a été documenté. Ces failles relèvent donc du risque de sécurité, pas d’une violation confirmée, et il faut les décrire comme telles. Le précédent du côté des moteurs de réservation invite toutefois à ne pas les ranger dans un tiroir: le white paper de Bitdefender publié en 2023 sur le moteur IRM Next Generation de Resort Data Processing montre comment des intrusions réussies, exploitant des failles de ce logiciel de réservation, ont permis de capter les données de paiement de clients d’établissements américains via un module malveillant greffé au serveur web. Même famille d’exposition, côté client cette fois.

Ce que la cadence des correctifs change en pratique

Oracle publie ses correctifs de sécurité par trimestre, dans ses Critical Patch Updates, et CVE-2023-22087 porte la marque de celle d’octobre 2023. Pour un responsable informatique d’hôtel ou d’un portefeuille d’établissements, cette périodicité a des conséquences très concrètes.

D’abord, un inventaire de versions est indispensable: les fiches NVD citent OPERA 5 Property Services en 5.5.x et en 5.6, deux lignes de versions encore visibles dans des parcs réels, et chaque CPU peut en corriger d’autres. Ensuite, la revue des expositions réseau prime sur tout le reste: une interface HTTP d’OPERA, qu’il s’agisse de Logging, de Reports ou du cœur applicatif, ne devrait jamais être joignable depuis Internet, et cette vérification mérite d’être rejouée après chaque chantier d’infrastructure ou de télétravail des prestataires.

Il faut aussi traiter chaque CPU comme un rendez-vous, pas comme une formalité: s’abonner aux advisories d’Oracle Hospitality, évaluer en staging l’impact sur les interfaces tierces avant de déployer en production, et documenter les dérogations quand un site doit attendre. Enfin, la récurrence des failles de type CWE-306 incite à auditer systématiquement l’authentification de chaque interface exposée par le PMS aux intégrations, portes connectées incluses, plutôt que de supposer qu’un accès interne vaut autorisation. Un PMS non patché n’est pas un incident en soi, c’est une porte de service laissée ouverte, et l’histoire d’OPERA montre qu’elle peut le rester des années.

Les faits

Otelier, anciennement MyDigitalOffice, est une plateforme cloud par laquelle des milliers d’hôtels gèrent réservations, transactions, rapports nocturnes et facturation. L’entreprise a confirmé la compromission à BleepingComputer et indiqué communiquer avec les clients concernés. Marriott a de son côté confirmé que l’incident Otelier l’avait touchée, suspendu les services automatisés fournis par l’éditeur le temps de l’enquête, et précisé qu’aucun de ses propres systèmes n’avait été percé.

Les échantillons de données examinés par BleepingComputer et par Troy Hunt, le fondateur du service d’alerte Have I Been Pwned, contiennent des réservations d’hôtes, des transactions, des courriels d’employés et d’autres données internes. Bitdefender y ajoute, dans les données reprises par Have I Been Pwned, des noms, adresses postales, numéros de téléphone et des numéros de carte bancaire partiels. Les mots de passe et les informations de facturation complètes ne semblent pas avoir été volés.

Les volumes, analysés par Troy Hunt : la table de réservations compte 39 millions de lignes, la table d’utilisateurs 212 millions. Après dédoublonnage, SOCRadar comme BleepingComputer relèvent au moins 1,3 million d’adresses courriel uniques ; une fois les adresses générées par Booking.com et Expedia écartées, Have I Been Pwned retient 437 000 adresses uniques réellement rattachables à des personnes, intégrées à son service de vérification.

Ce qui reste non confirmé

L’attribution est non confirmée. Aucun groupe n’a été publiquement identifié dans le reporting disponible ; ce sont les attaquants eux-mêmes qui ont décrit leur intrusion à BleepingComputer, sans que l’éditeur en atteste. Deux éléments doivent donc être lus comme des déclarations d’attaquants, et non comme des faits établis : le volume exfiltré, estimé par eux à 7,8 téraoctets, dont des millions de documents hébergés dans les espaces de stockage Amazon S3 gérés par Otelier et appartenant à Marriott (rapports nocturnes, audits de shifts, données comptables) ; et le vecteur initial, une voleuse d’informations ayant capturé les identifiants d’un employé pour entrer dans le serveur Atlassian d’Otelier, les tickets de support servant ensuite à récolter les identifiants des seaux S3, selon l’analyse publiée par SOCRadar. Otelier, interrogé sur ce vecteur, n’a pas souhaité aller au-delà de son communiqué. BleepingComputer a pu vérifier indépendamment, via la plateforme de renseignement Flare, que des informations d’employés Otelier avaient bien été volées par des voleurs d’informations.

Autre prudence : aucune action réglementaire n’a été rendue publique à la date de cet article. Cette absence constatée ne préjuge pas des suites.

Le mécanisme, lu côté défense

Le dossier combine trois briques ordinaires, et c’est ce qui le rend instructif. Une infostealer, malware commodity qui aspire identifiants et sessions sur la machine d’un salarié, a fourni le premier pied dans la porte. Un serveur Atlassian protégé uniquement par ces identifiants a ouvert l’accès interne. Des pièces sensibles, dont des identifiants de stockage cloud, circulaient dans les tickets de support, second coffre-fort improvisé qu’on retrouve dans beaucoup d’organisations.

Pour un hôtel, client d’Otelier ou de tout équivalent, la leçon ne se joue pas chez soi mais dans la relation fournisseur : exigibilité de l’authentification multifacteur sur tous les accès distants d’un prestataire, question écrite sur le stockage des secrets (un ticket n’est pas un coffre), et clause de notification d’incident avec délais.

Conséquences et perspectives

Le premier effet concret pour les clients des hôtels touchés est le phishing : BleepingComputer recommandait aux personnes dont l’adresse figure dans la fuite de se méfier des courriels imitant les enseignes concernées, l’exposition d’un nom, d’un numéro de téléphone et du détail d’une réservation offrant un appât de qualité. Le second effet est structurel. Marriott, Hilton et Hyatt n’ont rien subi d’intrusif et se retrouvent malgré elles dans des échantillons circulant chez les attaquants, parce qu’un maillon intermédiaire accumulait leurs données opérationnelles dans des seaux S3 mal gardés.

À la suite de l’incident, Otelier a indiqué avoir terminé l’accès non autorisé, désactivé les comptes impliqués et mandaté une équipe d’experts en cybersécurité pour une analyse médico-légale complète. Les hôtels n’ont, eux, qu’un levier : traiter la sécurité de leurs prestataires comme un poste d’audit à part entière, avec preuves à l’appui, plutôt que comme une ligne de contrat.

Deux groupes frappés coup sur coup

MGM Resorts a déclaré l’attaque début septembre 2023. Le groupe a indiqué dans un document réglementaire déposé auprès de la SEC, la gendarmerie des marchés financiers américains, que des régulateurs fédéraux et de l’État du Nevada examinaient l’incident, selon son rapport annuel déposé à la SEC en février 2024. Sur place, l’effet a été immédiat : des systèmes entiers des établissements de Las Vegas se sont arrêtés, le tapis vert et les services numériques ont fonctionné au ralenti pendant environ dix jours, selon Group-IB, et des systèmes sont restés indisponibles après l’incident, selon l’AP relayée par The CyberWire.

Chez Caesars Entertainment, une attaque par ingénierie sociale confirmée par l’entreprise en septembre 2023 a touché les données de membres du programme de fidélité, dont des numéros de permis de conduire et de sécurité sociale, selon le Form 8-K déposé par l’entreprise le 14 septembre 2023. Les deux attaques portent la marque du même écosystème : Scattered Spider est décrit par Group-IB comme une affiliation anglophone d’ALPHV, le groupe qui se cache derrière BlackCat.

Le mécanisme : la victime, c’est le helpdesk

La technique n’exploite aucun bogue. Elle exploite un process. Group-IB résume la méthode : « ils ne passent pas par le pare-feu, ils appellent le helpdesk ». Les opérateurs réunissent d’abord des informations publiques sur des employés réels, profils LinkedIn et annuaires d’entreprise, pour construire un prétexte crédible. Ils contactent ensuite le service d’assistance et demandent une réinitialisation de mot de passe ou une désactivation de l’authentification multifacteur au nom de cet employé.

Une fois la porte d’entrée identité ouverte dans l’environnement Okta de MGM, les attaquants se sont déplacés dans le système en utilisant des logiciels de connexion à distance courants et l’accès au VPN d’entreprise, ce qui leur a permis d’échapper à la détection, comme l’a décrit le Financial Times repris par The CyberWire. Le rançongiciel déployé est BlackCat/ALPHV. Des serveurs ESXi auraient été chiffrés, et les attaquants affirment avoir dérobé environ six téraoctets de données chez les deux groupes, selon The CyberWire, des chiffres invérifiés à ce stade.

Group-IB décrit Scattered Spider comme un réseau lâche de jeunes anglophones des États-Unis et du Royaume-Uni, sans parrainage étatique, et identifie plus de quatorze sous-groupes. Leurs autres outils sont le phishing par SMS, la prise de carte SIM pour intercepter les codes de validation et l’épuisement MFA, le bombardement de notifications jusqu’à ce que l’utilisateur cède. Des interpellations et des inculpations aux États-Unis comme au Royaume-Uni ont suivi en 2024 et 2025, sans éteindre la méthode, selon Group-IB.

Des issues différentes : payer ou encaisser

MGM a refusé de payer et a payé ailleurs : plus de 100 millions de dollars de pertes estimées par Group-IB et repris par la presse spécialisée, dont MGM avait attribué une part importante à la perte d’exploitation. Caesars, selon plusieurs sources concordantes reprises par Group-IB, The CyberWire et le cabinet McGriff, a négocié et versé une rançon estimée à 15 millions de dollars, tout en indiquant ne pas attendre d’effet matériel sur sa situation financière. L’entreprise n’a jamais publiquement confirmé ce paiement.

Le volet judiciaire a rattrapé MGM : le 21 janvier 2025, l’entreprise a accepté de verser 45 millions de dollars pour solder plus d’une douzaine de recours collectifs couvrant les compromissions de 2019 et de 2023, qui ont touché ensemble plus de 37 millions de clients, selon l’avis officiel du règlement et les dépôts judiciaires.

Ce que l’hôtellerie doit en retenir

Le périmètre n’est plus le pare-feu, c’est l’identité. Trois défenses se dégagent des analyses de Group-IB : une procédure de vérification d’identité stricte et auditée pour toute réinitialisation demandée par téléphone, y compris pour un dirigeant ; une surveillance temps réel des journaux du fournisseur d’identité, création de comptes privilégiés, changement de configuration MFA, authentifications de masse depuis des localisations inhabituelles ; et une authentification résistante au phishing, l’application d’authentification ou la clé physique plutôt que le SMS.

Le mode opératoire s’est diffusé : Group-IB rattache au même playbook des attaques contre les détaillants britanniques M&S, Harrods et Co-op ou encore Qantas en 2025. Pour un hôtel, la ligne d’assistance informatique est désormais une surface d’attaque à traiter comme telle, avec la même rigueur qu’une borne réseau.