Les développeurs du jeu Goddess of Victory: NIKKE ont indiqué début novembre 2026 que des fichiers de script du launcher PC pourraient avoir été modifiés par un tiers. D'après un chercheur indépendant, quatre fichiers JavaScript hébergés sur le réseau de diffusion de l'éditeur ont été altérés le 27 septembre 2026 pour télécharger une porte dérobée chez les joueurs. Pour un fabricant soumis au Cyber Resilience Act (CRA, le règlement européen sur la cybersécurité des produits numériques), un incident de ce type entre dans la définition de l'incident grave de l'article 14, applicable depuis le 11 septembre 2026 : alerte précoce sous 24 heures, notification sous 72 heures, rapport final sous un mois.
Ce qui s'est passé
Nous nous appuyons sur l'article de BleepingComputer du 4 novembre 2026, mis à jour le 5 novembre, qui cite le communiqué de l'éditeur et l'analyse d'un chercheur publiée sur GitHub.
- Ce que l'éditeur a confirmé. Dans un message publié sur X, l'équipe de NIKKE indique avoir identifié un problème montrant que les fichiers de script du launcher PC « may have been tampered with by a third party ». Une correction du client et une mise à jour ont été déployées le 4 novembre vers 2 h 30 (UTC+9). Le 5 novembre, BleepingComputer signalait que l'éditeur avait publié des instructions pour vérifier si un ordinateur a été compromis.
- Ce qu'avance le chercheur. Le chercheur indépendant MotherSphere affirme que quatre fichiers JavaScript hébergés sur le CDN (réseau de diffusion de contenu) officiel de Level Infinite, l'éditeur, ont été modifiés le 27 septembre 2026. À chaque ouverture du launcher, le code injecté téléchargeait la suite depuis des serveurs des attaquants.
- Ce que BleepingComputer a vérifié. Le média a examiné deux des fichiers modifiés : ils contenaient un chargeur obscurci qui récupère et exécute du code depuis deux domaines.
- La charge finale, d'après le chercheur. Le code téléchargé faisait exécuter par le launcher un programme LuaJIT qui installait un agent d'accès à distance, K2F : exécution de commandes, accès aux fichiers, captures d'écran, vol des identifiants NIKKE et des données des navigateurs. Une commande pouvait aussi installer une DLL Windows (bibliothèque de code) capable de rester active après la fermeture du launcher, qui, selon BleepingComputer, contient du code de vol de portefeuilles de cryptomonnaie. On ne sait pas si elle a été déployée.
- La correction. Selon le chercheur, trois des quatre fichiers ont été remplacés par des versions saines le 3 novembre, mais une copie altérée du quatrième était encore servie le 3 novembre à 22 h 26 GMT. Pour BleepingComputer, un script compromis a pu rester accessible après la mise à jour du client.
L'éditeur revendique plus de 45 millions de téléchargements depuis 2022. Le nombre de joueurs PC touchés est inconnu.
Comment ça fonctionne
C'est une attaque de la chaîne d'approvisionnement logicielle : l'attaquant modifie un fichier que le logiciel légitime télécharge et exécute de lui-même, depuis une source de confiance, le CDN de l'éditeur.
En principe, deux faiblesses le rendent possible :
- Le launcher exécute du code chargé à distance sans en vérifier l'intégrité, ou avec une vérification que la modification n'a pas déclenchée.
- Le stockage de diffusion est modifiable sans que la modification passe par la chaîne de publication habituelle, ou sans qu'elle soit détectée. Ici, d'après le chercheur, plus de cinq semaines séparent la modification (27 septembre) du remplacement des fichiers (3 novembre).
La façon dont l'attaquant a obtenu un accès en écriture au CDN n'est pas publique.
Ce que dit le CRA
Le CRA est le règlement (UE) 2024/2847. Nous ne savons pas si NIKKE relève du CRA ni comment l'éditeur a traité l'incident vis-à-vis des autorités européennes. Ce qui suit applique le texte à un cas de ce type, pour un produit mis à disposition sur le marché de l'Union.
Les dates
L'article 71, paragraphe 2, fixe l'application générale au 11 décembre 2027, avec deux exceptions : « Article 14 shall apply from 11 September 2026 », et le chapitre IV (organismes notifiés) depuis le 11 juin 2026. L'article 69, paragraphe 3, précise que l'article 14 s'applique aussi à tous les produits du champ du règlement mis sur le marché avant le 11 décembre 2027. Les notifications sont donc obligatoires aujourd'hui, produits déjà en circulation compris.
Un incident « grave »
L'article 14, paragraphe 5, considère comme grave un incident ayant un impact sur la sécurité du produit lorsque :
- (a) il affecte ou peut affecter négativement la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou fonctions sensibles ou importantes ; ou
- (b) il « has led or is capable of leading to the introduction or execution of malicious code » dans le produit ou dans les systèmes d'un utilisateur.
Un launcher qui télécharge et exécute une porte dérobée chez ses utilisateurs correspond au point (b).
Les délais
L'article 14, paragraphes 3 et 4, impose au fabricant de notifier l'incident grave, simultanément au CSIRT (centre de réponse aux incidents de sécurité informatique) désigné comme coordinateur et à l'ENISA (l'agence de l'Union européenne pour la cybersécurité), via la plateforme unique de signalement prévue à l'article 16 :
- une alerte précoce sans retard injustifié et au plus tard 24 heures après en avoir pris connaissance, indiquant au moins si l'incident est soupçonné d'être causé par un acte illicite ou malveillant ;
- une notification d'incident au plus tard 72 heures après en avoir pris connaissance, avec la nature de l'incident, une première évaluation, les mesures correctives prises et celles que les utilisateurs peuvent appliquer ;
- un rapport final dans un mois après la notification, avec une description détaillée, le type de menace ou la cause racine probable, et les mesures appliquées et en cours.
La notification se fait auprès du CSIRT coordinateur de l'État membre où le fabricant a son établissement principal dans l'Union (article 14, paragraphe 7). Pour un fabricant sans établissement principal dans l'Union, le même paragraphe prévoit d'autres règles de rattachement : vérifiez-les dans le texte.
Informer les utilisateurs
L'article 14, paragraphe 8, impose d'informer les utilisateurs touchés, et le cas échéant tous les utilisateurs, de l'incident et, si nécessaire, des mesures qu'ils peuvent prendre, le cas échéant dans un format structuré et lisible par machine. Si le fabricant ne le fait pas à temps, les CSIRT notifiés peuvent informer eux-mêmes les utilisateurs, s'ils l'estiment proportionné et nécessaire.
Les exigences de conception, à partir de décembre 2027
L'annexe I, partie I, point 2, demande notamment que les produits :
- (c) permettent de corriger les vulnérabilités par des mises à jour de sécurité, y compris automatiques le cas échéant, avec notification des mises à jour disponibles aux utilisateurs ;
- (f) protègent l'intégrité des données, commandes, programmes et configurations stockés, transmis ou traités contre toute manipulation ou modification non autorisée par l'utilisateur, et signalent les corruptions.
Un chargement de scripts qui exécute du code modifié sans le détecter pose la question du point (f).
Les sanctions
L'article 64, paragraphe 2, prévoit pour le non-respect de l'annexe I et des articles 13 et 14 des amendes jusqu'à 15 millions d'euros ou, pour une entreprise, 2,5 % du chiffre d'affaires annuel mondial de l'exercice précédent, le montant le plus élevé étant retenu. Le paragraphe 10, point (a), exonère d'amende les micro et petites entreprises pour le seul non-respect des délais de 24 heures de l'alerte précoce.
Qui est concerné
- Les éditeurs de logiciels et fabricants de produits connectés vendus dans l'Union, quel que soit leur pays d'établissement, dès lors que leur produit entre dans le champ du CRA.
- En particulier ceux dont le produit télécharge du code à l'exécution : launchers, agents de mise à jour, modules chargés depuis un CDN.
Se mettre en conformité : contrôles concrets
Les contrôles techniques ci-dessous sont des bonnes pratiques. Le CRA fixe le résultat attendu, pas la technique.
Côté produit
- Signer tout code chargé à distance et vérifier la signature avant exécution, dans le client, avec une clé qui ne se trouve pas sur l'infrastructure de diffusion. Un fichier modifié sur le CDN doit être refusé, pas exécuté.
- Séparer publication et diffusion. Seule la chaîne de publication, après revue, écrit sur le stockage de diffusion. Aucun compte humain n'y a d'accès permanent en écriture.
- Comparer en continu le contenu servi au contenu publié. Une tâche planifiée télécharge les fichiers depuis le CDN public et compare leur empreinte à celle de la dernière version publiée ; toute différence déclenche une alerte. Elle aurait pu signaler le quatrième fichier resté altéré, si l'on en croit le chercheur.
- Journaliser chaque écriture sur le stockage de diffusion, hors de portée des comptes qui écrivent.
Côté processus CRA
- Écrire la procédure 24 h / 72 h / un mois : qui qualifie l'incident au regard de l'article 14, paragraphe 5, qui notifie, avec quels éléments, auprès de quel CSIRT coordinateur.
- Préparer le message aux utilisateurs : un modèle d'avis, et si possible un format lisible par machine, avec les indicateurs de compromission et les gestes à faire.
- Couvrir aussi les vulnérabilités activement exploitées, que l'article 14 soumet à la même alerte à 24 heures.
Méthode de vérification. Sur un environnement de préproduction, modifiez un octet d'un script servi par votre CDN. Vérifiez trois choses : le client refuse de l'exécuter, l'alerte de comparaison se déclenche, et l'équipe sait dire en moins d'une heure si l'événement relève de l'article 14. Puis chronométrez une notification à blanc jusqu'à l'étape des 72 heures.
FAQ
L'article 14 du CRA s'applique-t-il déjà ?
Oui. L'article 71, paragraphe 2, le rend applicable depuis le 11 septembre 2026, et l'article 69, paragraphe 3, l'étend aux produits mis sur le marché avant le 11 décembre 2027.
Qu'est-ce qu'un incident grave au sens du CRA ?
Un incident qui affecte ou peut affecter négativement la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou fonctions sensibles ou importantes, ou qui a conduit ou peut conduire à l'exécution de code malveillant dans le produit ou chez ses utilisateurs (article 14, paragraphe 5).
À qui notifier ?
Simultanément au CSIRT désigné comme coordinateur de l'État membre de votre établissement principal dans l'Union et à l'ENISA, via la plateforme unique de signalement de l'article 16.
Sources
- BleepingComputer, NIKKE PC game launcher hacked to spread remote access, data-stealing malware, 4 novembre 2026, mis à jour le 5 novembre : https://www.bleepingcomputer.com/news/security/nikke-pc-game-launcher-hacked-to-spread-remote-access-data-stealing-malware
- Règlement (UE) 2024/2847 (Cyber Resilience Act), Journal officiel de l'Union européenne, articles 14, 64, 69, 71 et annexe I : https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
Pour préparer votre procédure de notification et vos exigences produit au titre du CRA, WeeSec accompagne les fabricants dans leur mise en conformité CRA.