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.

Coucou Amazon, coucou NVIDIA

Alors qu’AWS vient de lancer son TorchNeuron pour permettre aux entreprises intéressées d’entrainer leurs modèles sur les puces maison Trainium, Google a fait une annonce similaire avec TorchTPU. Comme le nom l’indique, il s’agit cette fois d’orienter les calculs vers les puces TPU fournies par Google. Celle-ci met cependant en avant son partenariat avec Meta pour PyTorch.

Google propose désormais sa propre pile logicielle permettant d’exécuter PyTorch directement sur ses TPU, sans passer par une couche d’adaptation. L’annonce, faite durant la PyTorch Conference 2026, suit de près celle d’Amazon Web Services avec son TorchNeuron.

• Avec TorchNeuron, Amazon veut faciliter l’entraînement des modèles sur ses puces Trainium

Rappelons que PyTorch est une bibliothèque permettant, entre autres, de construire et d’entrainer des modèles IA. Comme nous l’indiquions dans notre actualité sur TorchNeuron, PyTorch a besoin d’une couche intermédiaire pour traduire les opérations en instructions reconnues par le matériel. Dans la grande majorité des cas, cette couche est CUDA, une technologie propriétaire que NVIDIA travaille depuis longtemps pour s’assurer que tous types de calculs pourront être exécutés sur ses GPU.

• Pourquoi tout le monde se jette encore sur les GPU NVIDIA pour l’IA

Au tour des puces TPU

Si l’objectif d’AWS avec TorchNeuron était de pouvoir rediriger ces calculs facilement vers ses puces Trainium, Google fait maintenant de même avec ses TPU.

• Avec ses TPU Ironwood, Google passe à « l’ère de l’inférence »… avec de gros chiffres

Jusqu’à présent, pour exploiter ces puces dans le cloud de Google depuis PyTorch, il fallait passer par XLA, une solution que Google présente désormais comme peu naturelle. Le dépôt GitHub de XLA a d’ailleurs été mis à jour pour indiquer que le projet est à présent déprécié et remplacé par TorchTPU. Il sera archivé le 15 novembre, tout va donc aller très vite.

Le dépôt de TorchTPU est bien sûr déjà en ligne, le projet étant sous licence Apache 2.0 et donc open source. Deux modes d’exécution sont proposés. Le premier, eager, consiste à exécuter immédiatement le programme ligne par ligne, un cas jugé notamment utile pour chercher une erreur. Le second, torch.compile, analyse au contraire l’ensemble du programme avant de l’exécuter. TorchTPU permet de commencer avec le premier et de basculer dans le second si besoin.

Comme pour TorchNeuron, TorchTPU permet d’utiliser les puces de Google aussi bien pour l’entraînement que pour l’inférence. Google met largement en avant la compatibilité avec l’écosystème existant. TorchTitan, conçu pour répartir les calculs d’entraînement sur des milliers de puces, est par exemple de la partie. Selon Google, son fonctionnement a affiché une montée en charge linéaire jusqu’à 8 129 TPU. VeRL, pour l’apprentissage par renforcement, Ray, pour la répartition des étapes des chaînes de traitement, vLLM, un serveur faisant tourner les modèles de langage, ou encore SDLang et llm-d sont cités.

Pour Google, il s’agit d’un point clé dans son annonce. Cette logique de compatibilité apparait clairement dans plusieurs cas. Pour vLLM et SGLang par exemple, l’annonce précise que les ordonnanceurs, les modèles de travail et les serveurs d’API d’origine sont conservés, et que les piles d’inférence existantes peuvent être reprises telles quelles. Pour VeRL, le code des modèles et des algorithmes reste indépendant du matériel. Pour Hugging Face, également de la partie, un paramètre (device_map= »tpu ») suffit.

Le même goulot que chez Amazon

Les problématiques et les enjeux sont à peu près les mêmes que chez AWS. Google a tout intérêt à appuyer dans cette direction pour réduire la dépendance très présente de l’écosystème IA à NVIDIA. En réduisant autant que possible les frictions à utiliser les puces TPU, Google cherche donc à s’assurer une nouvelle place de choix dans l’entraînement des modèles comme dans leur inférence.

Il y a tout de même une différence notable dans TorchTPU : Meta participe directement au projet. Ayant créé PyTorch initialement (le projet est géré par la Linux Foundation depuis 2022), l’entreprise reste très impliquée dans son développement. Selon Digitimes, Meta est l’un des plus gros clients de NVIDIA. Elle chercherait donc activement à réduire sa dépendance, l’entreprise ayant également testé la location de capacité TPU auprès de Google Cloud.

Notez que Google, pas plus qu’Amazon, ne parle ouvertement de lutte contre NVIDIA. Mais il est difficile d’évoquer un PyTorch « plus indépendant » sans faire un clin d’œil à la firme de Santa Clara.