Capcom, l’éditeur japonais de jeux comme Street Fighter, Monster Hunter, Resident Evil ou encore Mega Man (et bien d’autres), a été victime d’un vol de données. L’entreprise a détecté le 19 octobre une « activité suspecte » ayant débouché sur un accès non autorisé à la base de données de Capcom ID. Il s’agit de comptes servant à accéder aux services en ligne de Capcom, et dont la création peut être obligatoire pour pouvoir jouer à certains titres.

Dès la découverte de la brèche, la société a bloqué l’accès à la base et lancé des mesures d’urgence pour identifier la méthode d’attaque. Capcom confirme que des informations de joueurs enregistrés avec un ID maison ont été subtilisées. Plus de 11 millions d’adresses e-mail et d’informations propres au système (date et heure de création du compte, nombre de connexions, adresses IP) sont dans la nature. Plus anecdotique, 43 enregistrements de dates de naissance, genres, pays et pseudos ainsi que 196 modifications non autorisées de mots de passe ont été comptabilisés dans la fuite.

Les mots de passe de ces comptes ont déjà été réinitialisés. Capcom ne confirme pour le reste « aucune compromission des mots de passe de connexion aux comptes Capcom ID initialement définis par les utilisateurs eux-mêmes. » Les informations bancaires des utilisateurs ne font pas partie des données volées.

Les utilisateurs de ces comptes ont été notifiés de l’incident par l’entreprise. Des formulaires de demandes d’assistance ont été mises en ligne (ici pour l’Europe). Capcom prévient que les informations en fuite peuvent être exploitées dans des campagnes de hameçonnage. Elle recommande de « faire preuve de prudence » et de ne pas cliquer sur les liens ou les pièces jointes contenus dans des courriels suspects qui pourraient usurper l’identité de Capcom.

CVE-2026-115560 : PHP signale une nouvelle faille RCE. Désactiver Session Upload Progress, déjà conseillé pour PHP2Shell, suffit en attendant le correctif.

Le post PHP signale une nouvelle faille RCE (CVE-2026-115560) : appliquez le même réglage que PHP2Shell a été publié sur IT-Connect.

Signal a corrigé dans RingRTC, sa bibliothèque d’appels, une faille qui empêchait le raccrochage de clore réellement l’appel. Le correctif date du 4 septembre, mais la divulgation publique n’est intervenue que le 20 octobre 2026.

La faille est estampillée CVE-2026-113380 et réside donc dans RingRTC, la bibliothèque logicielle créée par Signal (en open source) responsable des appels vocaux et vidéo. Elle affecte toutes les versions antérieures à la 2.72.0 et est critique, avec un score CVSS v4.0 de 9,3 sur 10.

Avec une version vulnérable, un pirate peut exploiter la faille en saturant la file d’attente de la machine à états finis (FSM) d’un appel pour empêcher le raccrochage local de démonter l’appel. Selon les cas, cela signifie que la piste audio, voire vidéo, continue. Le chiffrement de bout en bout n’est pas affecté, car le défaut porte sur la fermeture de l’appel, pas sur la protection des conversations.

Selon les notes du chercheur a priori à l’origine de la découverte, trois problèmes se cumulent, comme relevé par SecurityWeek. Ils sont loin d’être anodins :

• le raccrochage n’était pas un arrêt immédiat mais un évènement de plus dans la file d’attente ;
• il n’y avait aucune limitation de débit sur les évènements provenant du pair distant ;
• l’évènement de raccrochage n’avait aucune priorité.

Le correctif du 4 septembre ajoute ainsi un indicateur de terminaison séparé, avec sa propre priorité, et limite à 5 secondes les attentes lors de l’arrêt pour que le nettoyage continue même si certaines opérations échouent.

Cependant, la situation sur les nouvelles versions des différentes applications n’est pas claire. On ignore quand le correctif a été déployé, ni même s’il a bien été distribué. Nous avons contacté la fondation Signal et mettrons à jour cet article en cas de réponse.

Le gestionnaire de mots de passe 1Password ajoute une nouvelle corde à son arc. Dans un billet publié le 22 octobre, l’entreprise a présenté une nouvelle plateforme baptisée « 1Password for Agents » pour fluidifier l’utilisation des identifiants stockés dans la base, mais sans les voir.

Dans le scénario décrit par 1Password, un agent arrive sur un formulaire de connexion. Il interroge alors le gestionnaire de mots de passe, déclenchant une demande d’approbation par l’utilisateur. Si ce dernier confirme, 1Password remplit lui-même les champs d’identifiants, l’agent n’ayant pas accès à ces informations.

Pour réaliser l’opération, l’agent s’authentifie auprès de 1Password via une clé unique propre. Quand la connexion est faite, le gestionnaire supprime l’identifiant de la page pour que l’agent ne puisse jamais le voir ou le réutiliser. Dans le cas où plusieurs identifiants correspondent à un même formulaire, l’utilisateur est invité à choisir l’agent à utiliser. Ce dernier n’accède pas non plus au reste du coffre.

Ce mécanisme est clairement une évolution du complément 1Password for Claude lancé en juillet. Cette fois cependant, il s’agit d’une plateforme disposant d’intégrations pour Muse de Meta, Claude Duet d’Anthropic, ChatGPT Work et Dots d’OpenAI, Grok Bot de SpaceXSI (anciennement SpaceXAI, encore plus anciennement xAI) et Townie de Town. Selon les cas, la compatibilité est en cours de déploiement ou doit arriver « bientôt ». 1Password prévoit également l’intégration dans Instinct, Browserbase, Browser Use, Dana, KERNEL, Perplexity, Ramp, Tomo et Wajo.

1Password prévient toutefois que ce mécanisme ne sert qu’à protéger les identifiants, pas à contrôler l’agent lui-même. L’entreprise ne peut pas agir sur ce que l’agent fera avec ces identifiants, mais le problème était exactement le même en entrant manuellement les mots de passe pour réaliser une opération.

Mise à jour du 23 octobre : La version finale de KeePassXC est désormais disponible au téléchargement. Comme prévu, elle introduit le remplissage automatique des identifiants dans les applications sur Linux au sein des sessions Wayland (via XDG Portals), marquant une nette hausse du confort d’utilisation pour les personnes concernées.

On y retrouve également le portage vers Qt 6, le déverrouillage rapide via Polkit, des raccourcis configurables, le support de la génération de clés RSA, ECDSA et Ed25519 dans l’agent SSH, améliore l’intégration au bureau pour la version AppImage, ou encore introduit une AppImage pour les configurations ARM64.

---

Article original du 25 septembre  :

Le gestionnaire de mots de passe KeePass XC est une variante multiplateforme de KeePass, avec comme objectif une plus grande richesse fonctionnelle de base, sans passer par des plugins. La version 2.8, en préparation et dont une bêta vient de paraitre, s’annonce déjà comme une mouture majeure.

KeePass XC 2.8 bénéficie en effet d’un portage vers Qt 6, avec à la clé une modernisation de son interface et de ses intégrations dans les différentes plateformes prises en charge. Parmi les améliorations, on note surtout l’arrivée de l’auto-remplissage (fonction Auto-Type) pour les sessions Wayland, c’est-à-dire la capacité à insérer rapidement un identifiant et un mot de passe dans la fenêtre d’une application.

L’ajout est majeur, car Wayland ne permet plus « d’espionner » simplement une fenêtre active pour savoir si elle présente des champs d’authentification. La compatibilité annoncée va se faire à travers les portails XDG, ce qui revient à demander l’autorisation à Wayland d’examiner la fenêtre et d’y insérer des informations. L’équipe de KeePass XC avertit que ce support dépend pour l’instant de l’environnement choisi : support complet pour KDE 6.6 +, initial pour GNOME 48 + et dépendant du support des portails XDG dans les autres (Sway, Hyprland, labwc…).

Les autres améliorations sont nombreuses, avec par exemple l’arrivée d’une version compilée nativement pour les systèmes Windows ARM64 (y compris pour la version portable), une meilleure intégration sur Linux via l’AppImage, la possibilité de montrer des suggestions quand on ajoute des attributs, le support des clés d’accès (passkeys) dans les statistiques, la synchronisation des bases de données distantes via des outils tiers, des raccourcis clavier personnalisables ou encore le déverrouillage rapide sur macOS et Linux, respectivement via le mot de passe et Polkit. Enfin, plusieurs vulnérabilités ont été corrigées.

Pour les utilisateurs aventureux, le téléchargement de cette première bêta peut se faire depuis l’annonce officielle.

Oups ?

La Zero Day Initiative de Trend Micro a envoyé six rapports de failles de sécurité sur des listes de diffusion publiques du noyau Linux, avec de nombreux détails. Le caractère accidentel de ces publications est contesté. Le danger, bien que limité, est réel pour certaines configurations.

Les 21 et 22 octobre, six rapports de vulnérabilités ont été envoyés par Trend Micro sur des listes publiques rattachées au développement du noyau public. Plus précisément, ces rapports ont été adressés à la liste de sécurité privée du noyau, mais les listes publiques linux-kernel, linux-cifs, netdev et dri-devel figuraient en copie. Les détails techniques, avec les chemins de code et les traces KASAN, sont depuis publics alors qu’aucun correctif n’est encore publié.

Six vulnérabilités, dont deux critiques

Parmi les rapports, deux concernent des failles critiques dans ksmbd. La première, estampillée par Trend Micro ZDI-CAN-33774, réside dans une situation de compétition dans l’affectation de la table de traitement. Si l’on envoie une rafale de paquets SMB1 courts suivie d’un paquet SMB2 dans la même écriture TCP, les processus de travail traitent alors les données SMB1 avec un gestionnaire SMB2, qui va lire au-delà de la mémoire tampon. Une écriture hors limites devient ainsi possible, à condition que le pirate ait accès à un partage, mais aucune autorisation n’est nécessaire, expliquant le score CVSS de 9 sur 10.

L’autre faille, ZDI-CAN-33549, est un dépassement par le bas d’un entier (integer underflow) dans le chemin SMB Direct de ksmbd. Un client peut envoyer des descripteurs de tampon RDMA dont le premier est plus long que la charge annoncée. Le compteur de taille du serveur repasse alors par zéro et une copie mémoire déborde ensuite du tampon alloué. Pour l’exploitation en revanche, il faut réunir trois conditions : une interface compatible RDMA (matérielle ou le pilote logiciel rxe), un partage ksmbd accessible en écriture et un client qui négocie SMB Direct. À noter cependant que le support de SMB Direct est une option, désactivée par défaut. Le score CVSS est quand même de 9, confirmant la criticité de la brèche.

Ces notes sont attribuées via CVSS 3.1, le caractère critique débutant à 9. Trois autres failles – ZDI-CAN-33367, ZDI-CAN-34068 et ZDI-CAN-34076 – sont tout de même dans la tranche élevée, avec des notes comprises entre 7,8 et 8,8. Elles concernent respectivement une élévation locale de privilèges dans skb_zerocopy (réseau), une élévation locale de privilèges dans le pilote de GPU virtuel vmwgfx (VMware) et une divulgation d’informations dans nvmet (un pilote NVMe). La sixième faille, ZDI-CAN-32005, est un dépassement de pile (stack overflow) dans ConnMan, mais aucun score CVSS n’est rattaché.

Bien que le danger soit limité à certaines configurations spécifiques (ksmbd est un serveur compatible Samba mais n’est pas Samba), il est réel. Dans le contexte de publication de ces failles, il est probable qu’aucun correctif ne sera disponible avant plusieurs semaines.

Accident ou respect des nouvelles règles du noyau ?

Phoronix est le premier site à s’être rendu compte de ces publications. Pour nos confrères, il s’agissait clairement d’une bourde importante. D’ailleurs, Greg Kroah-Hartman en personne, le mainteneur principal du noyau Linux, s’est étonné et agacé dans des réponses à ces publications. Sur le pilote GPU VMware par exemple, il a répondu : « Pour une raison quelconque, vous avez envoyé cela dans des listes publiques, sans correctif, donc nous ne pouvons pas faire grand-chose avec ça ». L’agacement est monté d’un cran sur le rapport du pilote NMVe : « Encore une fois, pas de correctif, et envoyé sur une liste publique ? Merci de corriger votre processus de soumission… ».

Mais en dépit de ces réponses, certains médias s’interrogent : s’agissait-il vraiment d’un accident ? Cyber Kendra note ainsi que les rapports attribuent clairement la découverte des failles à TrendAI, le scanner IA de vulnérabilités de Trend Micro. Or, selon la documentation sur les failles de sécurité dans le noyau, réécrite et fusionnée pour le noyau Linux 7.1, indique que toute vulnérabilité trouvée grâce à l’IA doit être considérée comme publique et envoyée aux mainteneurs concernés plutôt que sur la liste privée.

Nos confrères rappellent que cette règle est une conséquence directe de l’agacement de Linus Torvalds sur le caractère « presque totalement ingérable » de la liste privée de sécurité depuis l’émergence des outils IA. Mais selon ces mêmes directives, les découvreurs de failles doivent joindre des correctifs ou des analyses d’impact. Les rapports de Trend Micro ne contenaient ni l’un ni l’autre, expliquant en partie l’agacement de Greg Kroah-Hartman.

The Hacker News évoque les mêmes règles et ne mentionne d’ailleurs jamais le caractère éventuellement accidentel de ces publications.

Nous avons contacté Trend Micro et mettrons à jour cette actualité si nous obtenons une réponse.

Une réponse HTTP compressée en Brotli, et du code qui s'exécute dans votre application Node.js : c'est le risque avec la faille Node2Shell (CVE-2026-111497).

Le post Node2Shell : la faille Brotli qui expose Node.js à une exécution de code à distance a été publié sur IT-Connect.

C'est la faute des réseaux sociaux !

eMudhra jette l’éponge : l’entreprise indienne a décidé de mettre « volontairement » un terme à son activité de certification SSL/TLS, après la découverte de son incroyable défaillance cette semaine.

Pointé du doigt et parfois moqué par une bonne partie de la planète tech depuis quelques jours, eMudhra a annoncé ce jeudi 22 octobre son retrait du marché des certificats HTTPS (PDF). Huit clés de chiffrement avaient été très mal générées par l’autorité de certification indienne : leurs valeurs tenaient sur 8 bits, alors qu’elles auraient dû l’être sur 384 bits (48 octets). Une clé portait ainsi le numéro… 4. Juste 4.

• Certificats TLS : n’importe qui pouvait certifier un site via des clés passoires

Une image de marque en miettes

eMudhra s’est défendue en parlant d’« erreurs humaines » à plusieurs étapes du processus. Des erreurs qui permettaient à n’importe qui de générer de faux certificats HTTPS pour des domaines qu’il ne contrôlait pas, permettant ainsi d’usurper un site légitime. Les navigateurs web ont été mis à jour très rapidement pour refuser les certificats générés à partir de ces clés, mais pas forcément certains services en ligne, applications ou objets connectés qui n’y voient que du feu faute de mise à jour.

L’entreprise assure avoir « traité cet incident avec diligence, révoquant les autorités de certification concernées dans les 14 heures suivant sa découverte et le signalant rapidement ». Elle rappelle qu’« aucun certificat destiné à un utilisateur final n’avait été émis par les autorités de certification concernées », que son infrastructure « n’a pas été compromise et aucune donnée n’a été dérobée ».

Alors, tout va bien ? Pas vraiment. Les exigences de souveraineté des données et de conformité rendent cette activé SSL/TLS « de plus en plus complexe et coûteuse au fil des années » alors que d’autres grands acteurs délivrent gratuitement ces certificats. Pour eMudhra, le potentiel commercial et le retour sur investissement ont « considérablement diminué », alors que ce business ne représente que 1 % de son chiffre d’affaires mondial. Un poids faible donc, mais il n’empêche que la défaillance fait courir de sérieux risques aux internautes.

Pour justifier son retrait, eMudhra n’avance pas que l’argument économique. L’autorité vide son sac, et il est lourd : « l’amplification de cet incident sur les réseaux sociaux a suscité une attention disproportionnée par rapport à la place du SSL/TLS dans nos activités ». La réputation du groupe en a pris un coup. Par conséquent, « nous consacrerons nos efforts aux domaines dans lesquels nous créons le plus de valeur pour nos clients, en nous recentrant sur nos principales solutions pour les entreprises et sur les services de confiance autres que le SSL/TLS. »

Les clients d’eMudhra se verront proposer le remplacement gratuit de leurs certificats par des certificats fournis par des partenaires. L’entreprise s’engage à maintenir le bon fonctionnement des services de révocation et de vérification du statut des certificats jusqu’à ce qu’ils aient expiré ou qu’ils aient été remplacés. Elle promet aussi un rapport détaillé sur l’incident.

• 21 octobre 2026 : retour en détail sur cette journée noire pour la cybersécurité

333 relais de sortie Tor compromis redirigeaient les connexions SSH vers des serveurs pirates pour voler les mots de passe et installer le malware Ebury.

Le post Réseau Tor : 333 relais de sortie compromis interceptaient les connexions SSH pour diffuser Ebury a été publié sur IT-Connect.

Plus de 11,7 millions de comptes CAPCOM ID exposés et 196 mots de passe modifiés par un attaquant : Capcom confirme une fuite de données massive.

Le post Capcom piraté : 11,7 millions de comptes exposés et des mots de passe changés par l’attaquant a été publié sur IT-Connect.

Amazon a repéré une tentative d'exploitation de PHP2Shell le 17 octobre 2026, soit quatre jours avant la sortie des correctifs pour ces failles critiques.

Le post PHP2Shell : les attaquants avaient quatre jours d’avance sur le correctif a été publié sur IT-Connect.

Un compte d'accès du LOOF a permis d'extraire 2,9 millions d'enregistrements du fichier I-CAD : noms des détenteurs de chats et identification des animaux.

Le post Fuites I-CAD : 2,9 millions de fiches de chats volées, avec le nom de leurs propriétaires a été publié sur IT-Connect.