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.
Image : Capcom
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.
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.
Photo de rc.xyz NFT gallery sur Unsplash
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.
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).
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.
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.
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.
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.
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.
L’ancienne ministre de la Transition écologique, Agnès Pannier-Runacher, a été la cible d’une attaque via un logiciel espion.
Politico a appris que l’actuelle députée Renaissance du Pas-de-Calais a déposé plainte fin septembre auprès de la DGSI après avoir reçu une alerte sur son iPhone.
Illustration : Flock
Apple lui a en effet envoyé une notification le 13 août que nos confrères ont pu consulter. Celle-ci indiquait que l’appareil avait été ciblé par un « logiciel mercenaire ». La députée aurait déjà reçu des alertes similaires en mars et avril 2025 lorsqu’elle était encore ministre.
« À chaque fois, ce sont mes appareils personnels qui étaient visés », a-t-elle déclaré au Monde en précisant que la DGSI n’avait pas confirmé d’infection des appareils ciblés à l’époque.
Les trois alertes sont regroupées par le parquet de Paris dans une seule et même enquête même si le constructeur a précisé qu’elles correspondaient à des attaques distinctes. Selon Politico, les enquêteurs n’auraient pas encore identifié le logiciel espion qui aurait été utilisé mais ils écarteraient déjà la piste du logiciel Pegasus de l’entreprise israélienne NSO.
Le fait qu’un smartphone ait été ciblé n’implique pas obligatoirement que l’infection ait fonctionné. Agnès Pannier-Runacher a affirmé au Monde que les premières analyses seraient négatives.
GitLab a corrigé la CVE-2026-110264, une faille critique exploitable sans authentification qui touche toutes les versions depuis la 7.0, sortie en 2014.
Fortinet a publié le 22 octobre des correctifs urgents pour FortiOS, FortiManager et FortiAnalyzer, contre des failles critiques détectées grâce à l'IA.
J'ai pas trouvé la màj pour mon Windows Millennium, normal ?
Le mercredi 21 octobre restera certainement gravé dans les mémoires. Plusieurs failles d’importance ont été dévoilées : deux sur PHP permettant d’exécuter du code à distance, huit clés générées n’importe comment permettant de créer des certificats pour n’importe quel site ou application, sans oublier des failles sur Node.js et GitLab. Next revient sur les enjeux techniques et les conséquences à venir.
Il y a des dates qui restent marquées dans les mémoires. Celle du 8 avril 2014 était un bon exemple. Il y a 12 ans, Heartbleed secouait en effet Internet : une faille dans OpenSSL (une brique servant à sécuriser les connexions sur Internet) permettait de récupérer des données en clair directement dans la mémoire des serveurs. Identifiants, mots de passe… tout y passait, notamment des données bancaires malgré le silence des banques.
Ce mercredi 21 octobre 2026 en est désormais une autre.
Ce 21 octobre, une bonne partie des responsables de sites étaient devant leur PC à attendre 16 h (heure de Paris) avec une certaine fébrilité. En cause, l’équipe de PHP avait donné rendez-vous en annonçant que deux méchantes failles PHP allaient être dévoilées, avec les correctifs. Traduction : la mise à jour devait se faire sans attendre.
Dans la journée, les choses se sont accélérées, des prototypes d’exploitation circulant sur les réseaux sociaux (vrais ou pas, le souci n’était même plus là) ; PHP a finalement publié les correctifs avec 15 minutes d’avance. Les versions avec un correctif officiel sont les suivantes : 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
Les deux failles permettent d’exécuter du code arbitraire à distance, sans aucune authentification. Elles permettent par exemple de lire l’intégralité des données, d’obtenir les accès aux bases de données, de récupérer des clés API, de prendre le contrôle de la machine, etc. La gravité dépend de la manière dont PHP est exécuté.
Ces vulnérabilités sont particulièrement graves car elles résident dans un langage de programmation utilisé par 70 % des sites web. L’ANSSI fait le point pour la France : « PHP est un langage de script largement utilisé par les serveurs web, avec plus de 600 000 serveurs l’exploitant sur l’Internet français. Il s’agit d’un moteur permettant aux sites web de générer des pages dynamiques, dont le contenu évolue en fonction des interactions des utilisateurs ou des données du serveur ».
Une exploitation pas simple, mais une faille imparable sauf à mettre à jour PHP
Il reste 84% de l'article à découvrir. Vous devez être abonné•e pour lire la suite de cet article. Déjà abonné•e ? Générez une clé RSS dans votre profil.
Est-ce que vous faites partie de ceux qui pensent qu'un VPN, bah, ça chiffre, ça tourne et tout va bien ? Parce qu'en 2027, les questions à se poser sont un peu différentes (2027 oui, je suis déjà dans le turfu). Même si aujourd'hui vos données sont protégées, est-ce que ce sera encore le cas face à un ordinateur quantique ? (qui n'existe pas encore, mais ça semble vite se rapprocher). Et est ce que vous scannez parfois des QR codes (sur des parcmètres, des tables de restaurant pour charger un menu, etc.) sans réfléchir ?
Si oui, ce que Surfshark vient d'annoncer ces dernières semaines va peut-être intéresser et on va voir ça ensemble.
WireGuard post-quantique : parce que "voler maintenant, déchiffrer plus tard" ça existe déjà
Le premier point est plutôt important : Surfshark vient de déployer une version de WireGuard entièrement post-quantique. Ils seraient même les premiers au monde à avoir implémenté ça.
Comme c'est important de comprendre pourquoi, je vous remets un peu de contexte. On commence à devoir faire à des attaques que l'on appelle "steal now, decrypt later". À l'heure actuelle des acteurs gouvernementaux (ou autres) interceptent et stockent déjà massivement du trafic chiffré. Et quand arriveront les ordinateurs quantiques capables de casser les algorithmes actuels, on pourra remonter et lire vos données partagées depuis hier. Sympa, non ? Alors oui vous allez me dire que ce ne seront pas des données récentes. Sauf que certaines ne changent pas au cours du temps. Vous aurez toujours le même nom, les mêmes antécédents de santé, très souvent la même adresse physique, le même mail, etc.
Pour lutter contre ce type d'attaque, il faut 3 éléments. D'abord le chiffrement, ensuite l'échange de clés et enfin l'authentification. Le problème, c'est que les 3 sont rarement couplés. Le chiffrement est quelque chose d'assez commun maintenant, le ML-KEM (échange de clés post-quantique) commence à se diffuser, mais le ML-DSA (certificats d'authentification post-quantiques) est un autre niveau de galère. Car il demande de revoir tout le système de confiance et cela derrière chaque connexion sécurisée.
Si l'on regarde du côté des grosses plateformes cloud de gestion de clés (AWS KMS, Google Cloud KMS et les autres mammouths du marché), la moitié seulement a déjà intégré ML-KEM et moins d'une sur 10 dispose du ML-DSA. Et l'on parle de géants, pas des applis de petite échelle qui sont encore moins bien préparées. Ni Apple ni Microsoft ne l'ont activé dans leurs logiciels utilisateurs pour l'instant. Quand les ordinateurs quantiques arriveront, un VPN sans authentification post-quantique sera la porte ouverte au session takeover. La machine quantique se fera passer pour le serveur au moment même où vous vous connecterez.
Surfshark combine donc déjà le duo ML-KEM + certificats ML-DSA dans WireGuard. Ce n'est disponible pour l'instant que sur iOS et macOS, mais les autres plateformes sont prévues dans les prochains mois. Et pour rappel,
ils avaient déjà lancé Dausos
, leur protocole maison conçu post-quantique depuis la première ligne de code. Ils ne rigolent pas sur le sujet.
Changer d'IP toutes les cinq minutes, sans couper
Lorsque vous êtes connecté à un VPN, vous avez une adresse IP (Captain Obvious a pris possession de ce corps). Elle ne change pas tant que vous ne vous déconnectez pas. Or une IP fixe, même si ce n'est pas la vraie, c'est toujours un élément qui permet aux annonceurs et aux data brokers de vous recouper entre les sites et de construire votre profil.
La rotation d'IP de Surfshark change votre adresse automatiquement après quelques minutes (5 à 10 minutes selon la région choisie). Et sans couper votre connexion VPN. Pas de microcoupure, pas de "ah bah mon app a planté pendant que l'IP switchait".
L'outil va même encore plus loin en proposant la fonctionnalité Multi IP, qui s'appuie sur leur technologie Nexus. Au lieu d'avoir une seule IP de sortie pour tout votre trafic, chaque site que vous visitez passe par une IP différente, pendant la même session VPN. Concrètement cela veut dire que le site A vous voit avec l'IP n°1, le site B avec l'IP n°2, etc. Les deux sites ne peuvent plus vous corréler. Vous pouvez choisir de limiter cette rotation à un pays, une zone ou le monde entier. Pour l'instant, cette dernière option est encore une fois dispo sur macOS uniquement, dans les paramètres avancés. J'entends les pleurs des windosiens et linuxiens jusqu'ici.
Alors il faut tout de même mentionner que l'option monde (global) peut parfois faire capoter certains sites ou applications qui détestent voir votre IP changer toutes les cinq minutes. C'est une fonctionnalité adaptée pour les gens paranos qui veulent le niveau de vie privée maximum, moins pour binge-watcher tranquillement.
Une petite info rapide supplémentaire pour ceux qui ont (ou prendront) un abonnement One ou One+ et qui bénéficient donc de l'antivirus. Dorénavant la moindre ligne de code passe par plusieurs étapes : peer review (humains + IA), tests internes, analyses de vulnérabilité & co et sont certifiés via le processus de signature Microsoft. Ça ne parait pas flamboyant dit comme ça, mais un driver ou une mise à jour, non signé ou mal testé, reste une porte d'entrée pour pas mal de bouses numériques. Un fournisseur
qui documente ses pratiques
de déploiement, c'est encore trop rare dans l'industrie alors que ça devrait être la base. Ici tout le processus est écrit noir sur blanc et ça va avec la politique d'ouverture de la firme (audits indépendants, politique de non-conservation des logs, etc.)
Le quishing c'est quoi ?
Maintenant, parlons d'une menace qui trouve sa source dans notre vie quotidienne. Le quishing (contraction de QR code et phishing) fait référence aux QR codes malveillants qui redirigent vers de fausses pages de connexion. Ou déclenchent de manière automatique un téléchargement de malware dès qu'il a été scanné. Pourquoi c'est en train de devenir le vecteur à la mode ? Il y a 3 raisons principales et elles sont assez faciles à comprendre :
Déjà vos yeux ne peuvent pas lire un QR code. Si c'est le cas faites-le-moi savoir lol. Un lien de phishing, vous pouvez le survoler pour voir ou il mène avant de cliquer. Un QR code c'est beaucoup moins simple. Le contenu est invisible jusqu'à ce que les dégâts soient faits.
Les filtres de votre fournisseur d'email sont prévus pour scanner du texte, pas des images. Une URL en clair dans un mail se fait flagger tout de suite alors que la même URL encodée dans un QR code passe comme une lettre à la poste.
Le scan est dans 99% des cas effectué via un mobile, hors des protections de votre PC perso ou d'entreprise : pas de filtre DNS, pas d'EDR, rien.
Les chiffres avancés sont probablement bien plus élevés que vous ne le pensez. Les QR codes représentaient déjà plus de 10% de toutes les attaques de phishing en 2025. Leur but est le vol d'identifiants, récupérer vos numéros de CB, de vous faire vous connecter à un fax site bancaire, etc. Et beaucoup de personnes scannent sans même imaginer qu'une arnaque de la sorte est possible. Il faut dire que ce n'est pas très difficile à mettre en place. Il suffit de placer des dizaines/centaines de stickers par-dessus de vrais codes (parcmètres, bornes de recharge, tables de restaurant, dépliants de musée, distributeurs de billets, etc) et le tour est joué.
Les QR Code c'est l'enfer
Les réflexes à avoir ? Penser à lire l'aperçu d'URL avant d'ouvrir (votre caméra la montre parfois) ou installez une appli de lecture de QR qui propose la prévisualisation avant ouverture, se méfier de tous QR code dans un mail (surtout non désiré), vérifier qu'un sticker n'a pas été collé par-dessus un autre. Et passer par l'application officielle plutôt que par le QR code pour tout paiement. La prudence, ça marche souvent.
D'un côté on a un ordinateur quantique (qui n'existe pas encore, mais qui va changer beaucoup de choses en termes de cybersécurité) et de l'autre des QR code malveillants qui se propagent déjà. La menace a plusieurs visages. Entre les deux, disposer d'une suite d'outils qui s'adaptent en continu et qui anticipent le futur, c'est toujours bon à prendre.
L'offre du moment
Les tarifs restent les mêmes et font de la firme au requin l'un des meilleurs rapport qualité/prix depuis de nombreuses années (mon comparatif des meilleurs VPN du moment pour plus d'infos). Sur un engagement 24 mois (+3 mois offerts) l'offre :
Starter (VPN seul) revient à 2,49 € HT/mois
One à 2,99 € HT/mois (VPN + antivirus, Alert, Alternative ID, la protection anti-scam et le web content blocker)
et One+ à 4,49 € HT/mois (avec Incogni en plus de tout ce qui est compris dans One)
Huit certificats intermédiaires d’eMudhra reposaient sur des clés privées devinables en quelques secondes. Mozilla, Google, Apple et Microsoft les bloquent.
