Frigos piratés dans les supermarchés : la même faille existe dans vos logiciels

En bref : dans la nuit du 11 au 12 octobre 2026, des attaquants ont fait chauffer les frigos de plusieurs centaines de supermarchés français jusqu'à 50 °C. Ils n'ont probablement pas eu besoin d'une attaque sophistiquée. Les contrôleurs de froid avaient une interface d'administration accessible depuis Internet, et la plupart tournaient sur un logiciel en fin de vie ou pas mis à jour. Ces deux causes ne sont pas propres à la réfrigération : on les retrouve dans beaucoup de back-offices, d'ERP et d'outils internes de PME. Voici ce qui s'est passé, ce que recommande le CERT-FR, et comment nous traitons ces deux risques sur les logiciels que nous hébergeons.

---

Ce qui s'est passé

• Nuit du 11 au 12 octobre. Le dégivrage automatique, qui dure normalement environ deux heures par jour, est remplacé par un dégivrage forcé et continu. Les températures montent jusqu'à 50 °C, surtout la nuit, magasins fermés (Next).
• Plus de 500 magasins touchés, selon Al Jazeera : au moins 300 Intermarché et Netto, plus de 100 Coopérative U, 80 Carrefour, environ 5 % des Monoprix, et des Leclerc. Un seul Leclerc aurait perdu environ 220 000 € de marchandises (BFMTV, cité par Next).
• Le parquet de Paris a ouvert une enquête et fait état de départs de feu.
• Le matériel : des contrôleurs Danfoss AK-SM 800 et AK-SC 355, que Danfoss décrit comme en fin de vie, et des AK-SM 800A qui n'avaient pas reçu les mises à jour disponibles. Le CERT-FR a ajouté le 13 octobre les contrôleurs Copeland xweb et Dixell xweb (alerte CERTFR-2026-ALE-012).

Un détail compte plus que les autres : en août 2025, l'éditeur de sécurité Claroty recensait déjà 2 765 interfaces AK-SM 800A accessibles depuis Internet, et les failles qu'il signalait avaient des correctifs. Le problème était connu et documenté depuis plus d'un an.

Anecdote : les Pays-Bas ont eu leur propre incident de supermarché le même week-end, sans les frigos. Le dimanche 11 octobre, Ahold Delhaize, maison mère d'Albert Heijn, a coupé des systèmes par précaution après un incident de cybersécurité. Plusieurs de ses centres de distribution néerlandais se sont arrêtés, les livreurs ont été déconnectés de leur application de planning, et les sites d'Albert Heijn, Etos et Gall & Gall sont tombés (NOS, Security.NL, en néerlandais). Aucune installation de froid n'a été touchée, et le centre néerlandais de cybersécurité (NCSC) dit ne voir pour l'instant aucun lien avec l'attaque française (Security.NL). Deux attaques très différentes le même week-end, et la même leçon : ce dont un magasin dépend, aujourd'hui, c'est du logiciel.

Pas besoin d'une faille pour tout casser

Le vecteur exact de l'attaque n'est pas confirmé. Mais comme le souligne Next, changer un cycle de dégivrage se fait avec un simple identifiant valide, sans exploiter la moindre faille. Un mot de passe par défaut jamais changé, un compte de prestataire partagé, un identifiant qui a fuité : il suffit que l'écran d'administration soit joignable.

C'est pour cela que le CERT-FR écrit que « l'exposition d'une interface de gestion sur Internet est contraire aux bonnes pratiques ». Ses recommandations tiennent en quatre points :

1. Supprimer l'exposition Internet des équipements concernés.
2. Vérifier toute la configuration, notamment les plages de dégivrage.
3. Ne rétablir l'accès qu'à travers un VPN sécurisé ou un réseau protégé.
4. Appliquer les mises à jour du constructeur.

Il précise aussi que filtrer par adresse IP les accès du prestataire est acceptable en urgence, mais « ne doit pas être considéré comme pérenne », et qu'un équipement en fin de vie remis aux paramètres d'usine reste vulnérable.

La même chose, dans vos logiciels

Remplacez « contrôleur de froid » par n'importe quel outil métier et le scénario reste le même. Ce que nous trouvons régulièrement quand nous reprenons une application :

• Un back-office ou une page d'administration à une adresse publique, protégée seulement par un mot de passe, parfois celui créé à la livraison.
• Un outil d'accès à la base de données (phpMyAdmin, Adminer) laissé en ligne « pour dépanner ».
• Une application sur une version qui ne reçoit plus de correctifs : PHP, Symfony ou AngularJS en fin de support, un CMS jamais mis à jour. Nous avons détaillé les dates dans notre article sur la fin de support PHP, Symfony et AngularJS.
• Des accès prestataires ouverts il y a des années, que personne n'a revus.
• Personne qui surveille les changements de configuration : comme pour les plages de dégivrage, une modification malveillante peut passer inaperçue jusqu'au jour où le dommage est fait.

Aucun de ces points ne demande un attaquant brillant. Ils demandent seulement que personne ne soit chargé de s'en occuper après la livraison.

Comment nous traitons ces deux risques

Nous hébergeons et faisons tourner la plupart des logiciels que nous développons, donc ces deux questions sont les nôtres. Voici ce que nous faisons, tel que décrit sur notre page sécurité :

Aucune interface d'administration sur Internet. Les outils d'administration et l'accès aux bases de données ne sont joignables que depuis notre réseau privé Tailscale, jamais depuis Internet. Les serveurs eux-mêmes n'ont pas d'adresse IP publique. Seules les applications destinées aux utilisateurs sont publiques, derrière le répartiteur de charge de Google et des règles Cloud Armor. C'est exactement le modèle « accès uniquement via un VPN ou un réseau protégé » que recommande le CERT-FR.

Des mises à jour qui ne dépendent pas de la mémoire de quelqu'un. Dependabot surveille les dépendances de chaque dépôt, une analyse planifiée revérifie régulièrement la branche principale de toutes nos applications en service, et chaque modification passe par des contrôles de sécurité automatiques qui bloquent la fusion en cas de problème. Ce qui est trouvé devient un ticket, pas un e-mail perdu.

Pas de mot de passe dans le code. Les identifiants vivent dans HashiCorp Vault et Google Secret Manager, et sont injectés au démarrage.

Une configuration versionnée. Toute l'infrastructure est décrite en code (Terraform) et modifiée par des demandes de fusion relues : on sait qui a changé quoi, et quand.

Ce que nous ne prétendons pas : notre réseau privé tient l'administration hors d'Internet, mais il ne restreint pas encore chaque personne à des services précis. Nous l'écrivons sur la page sécurité, parce qu'une liste qui ne contient que des points forts est une plaquette commerciale.

Les questions à se poser cette semaine

1. Qu'est-ce qui, chez nous, est joignable depuis Internet ? Pas seulement le site : le back-office, l'ERP, l'extranet, les outils d'administration.
2. Sur quelle version tourne chacun de ces outils, et reçoit-elle encore des correctifs de sécurité ?
3. Qui est chargé d'appliquer ces correctifs, et quand l'a-t-il fait la dernière fois ?
4. Quels prestataires ont un accès, par quel chemin, et avec quel mot de passe ?
5. Si quelqu'un changeait un paramètre métier cette nuit, qui s'en apercevrait, et quand ?

Si vous ne savez pas répondre aux deux premières, un audit court est le bon point de départ. Si la troisième n'a pas de réponse, c'est un contrat de maintenance qu'il vous manque : chez nous, il démarre à 400 € par mois et inclut les mises à jour de sécurité au fil de l'eau, au lieu d'un rattrapage le jour où un incident fait la une.

À lire aussi : notre page sécurité, la fuite de données des Hauts-de-France via deux sous-traitants, la TMA, avec les prix, et faut-il confier l'hébergement à l'agence qui développe votre logiciel.