Veille Cyber #6 : froid, Ivanti et Next.js

Le CERT-FR signale de nombreuses compromissions de contrôleurs de réfrigération Danfoss AK-SM et AK-SC, Copeland xweb et Dixell xweb. L’alerte date du 12 octobre et a été étendue le 13. Le point commun : des interfaces de gestion accessibles depuis Internet. L’alerte ne donne ni CVE unique ni preuve d’un mécanisme identique pour tous les modèles. Pen Test Partners décrit notamment un ancien accès Danfoss fondé sur la date et insiste sur les firmwares obsolètes, sans que cela se généralise aux autres marques.

Pourquoi ça compte ? Ici, l’impact touche aussi un procédé physique. Un dégivrage déréglé peut compromettre la chaîne du froid, et Pen Test Partners rapporte des pertes de denrées. La réponse du CERT-FR tient en une logique : retirer l’exposition publique, vérifier toute la configuration, dont le dégivrage, puis, si l’équipement est compromis, restauration usine et reconfiguration. L’accès passe ensuite par un réseau protégé ou un VPN sécurisé, avec firmware maintenu et identifiants durcis.

Ce qui me marque, c’est le piège du réflexe. Un reset ne corrige pas la vulnérabilité d’un appareil en fin de vie resté exposé, et un filtrage IP d’urgence n’est pas une solution durable. Surtout, on ne coupe pas à l’aveugle : il faut coordonner avec le métier et le frigoriste, parce que l’arrêt a lui aussi un coût physique.

Source : CERT-FR, alerte 012 ↗. Recoupement : Pen Test Partners, 14/10 ↗.

Début octobre, Volexity observe une chaîne d’exploitation sur Ivanti Connect Secure 22.8R2.4, alors à jour. Son rapport date du 13 octobre, et le CERT-FR confirme le 14 l’exploitation active de CVE-2026-104935. La chaîne associe un contournement d’authentification avec exécution de code (cette CVE) à une élévation de privilèges distincte pour obtenir les droits root. Au 13 octobre, Volexity indique que cette seconde étape attend encore un correctif.

Pourquoi ça compte ? Corriger la CVE ne corrige donc pas toute la chaîne. Volexity constate vol de secrets, reconnaissance, accès aux données d’Active Directory et nettoyage de traces. L’outil de contrôle d’intégrité d’Ivanti (ICT) peut manquer cette chaîne, notamment ses modifications en mémoire : un résultat négatif n’établit pas l’absence de compromission. Le CERT-FR demande d’isoler l’équipement des réseaux externe et interne, de préserver mémoire, disques et journaux avant toute opération destructrice, puis d’investiguer. Si l’appareil est compromis : reconstruction, correctif, renouvellement des secrets et certificats concernés, recherche de mouvements latéraux.

Honnêtement, c’est la leçon la plus utile du numéro : supprimer la porte d’entrée, éradiquer l’intrus et retrouver la confiance sont trois étapes différentes. Côté versions, le CERT-FR cite 22.8R2.5, 25.1.1.2 et 25.1.3.1 selon les branches. Pour la 25.1.2, je ne tire aucune conclusion : suivez la matrice de l’éditeur avant toute consigne opérationnelle.

Source : Volexity, investigation du 13/10 ↗. Recoupement : CERT-FR, alerte 013 ↗.

Le 14 octobre, Next.js publie des correctifs exceptionnels pour deux exécutions de code à distance sans authentification et un déni de service, liés à des composants amont. Les versions de remédiation sont 16.4.1 et 15.5.28 selon la branche. Trois chemins distincts : le cache (App Router, Cache Components et fonction use cache renvoyant plusieurs tableaux typés, versions 16.0.0 à 16.4.0), l’optimisation d’images (SVG, Linux glibc, avec sharp 0.35.5 ou supérieur comme contournement indiqué) et les Server Actions (saturation CPU, App Router avec au moins une Server Action).

Pourquoi ça compte ? Les avis lus ne documentent aucune exploitation observée : ce n’est pas un incident confirmé, c’est une fenêtre de risque à fermer. Pour le cache, l’éditeur demande une mise à jour immédiate, même sans fonction similaire identifiée, et aucun contournement n’est connu. Pour les Server Actions, Pages Router ou l’absence de Server Actions écartent ce chemin, mais seulement celui-là.

Mon avis : le réflexe « on utilise Next.js, donc concernés » est aussi faux que « on ne l’utilise pas comme ça, donc tranquilles ». Il faut inventorier versions, fonctions et environnement, mettre à jour, reconstruire, redéployer, puis contrôler les dépendances réellement embarquées dans l’artefact de production. Modifier un manifeste ne prouve pas que la production est corrigée.

Source : Next.js, bulletin du 14/10 ↗. Avis des mainteneurs : cache ↗, images ↗, Server Actions ↗. Ce sont d’autres documents primaires du même éditeur, pas une confirmation indépendante d’attaques.

À vendredi prochain. En attendant, un bon réflexe : avant de corriger, demandez-vous ce qu’il faut d’abord comprendre, isoler ou conserver. Lénaïck