Le gros câble que vous branchez sur votre voiture électrique, celui qu'il faut soulever à deux mains et qui pèse le poids d'un âne mort, dispose de 2 choses : Du courant, et un réseau. Lionel Richard Saposnik, chercheur chez SaiFlow, a eu la curiosité d'aller voir ce qui traîne sur ce réseau-là et vous allez voir, c'est pas triste...

Quand vous clipsez le pistolet dans la trappe, votre bagnole et la borne montent une liaison IPv6 entre elles, par courant porteur, sur deux broches du connecteur CCS2. Elles se causent en respectant la norme ISO 15118 pour négocier vos ampères, votre tension, le prix de votre kWh.

Le simulateur de véhicule se branche sur la prise et atteint la carte de la borne. Schéma SaiFlow.

Lors de ses tests, sur une borne rapide XCharge C6, il a trouvé un service SSH (Dropbear) qui écoute sur le port 22 et un Telnet (BusyBox) sur le port 23. Et sans surprise, le login c'est root et le mot de passe... bah c'est "root" aussi !! Mdrrrr ! Donc vous branchez votre voiture, vous vous connectez en SSH et vous êtes root !!

La raison c'est que les services d'administration de la borne écoutent sur 0.0.0.0, autrement dit sur toutes les interfaces réseau de la machine. Sauf que parmi ces interfaces, y'a can0 pour le bus CAN interne, eth0 pour le réseau de management... et surtout qca0 et qca1, les deux modems courant porteur des deux pistolets de charge. Écouter partout, ça veut donc dire aussi écouter du côté de votre voiture.

SSH et Telnet à l'écoute sur toutes les interfaces, celles du câble comprises. Capture SaiFlow.

Pour aller taper dessus, il lui a donc fallu seulement 130 $ de matos. De quoi tirer le Control Pilot à 9 V (5 à 10 $) pour faire croire à la borne qu'une voiture est connectée, un modem HomePlug Green PHY genre QCA7000 ou QCA7005 à 70 $, un Raspberry Pi à 50 $, et deux fils à mettre en contact avec le connecteur.

Et hop, avec tout ça, n'importe qui peut se retrouver sur le réseau interne de la borne. Et là, avec l'accès root, un attaquant peut faire tout un tas de choses comme voler le certificat SECC pour se faire passer pour la borne au moment où votre voiture s'authentifie en Plug & Charge, trafiquer le comptage de l'énergie, poser une backdoor dans un cron, rebondir vers le réseau de l'opérateur par le VPN de la borne, ou couper le refroidissement et la protection contre les surintensités.

Ça craint hein ?

Je vous avais raconté comment Charlie Miller a pris le contrôle d'une Jeep sur l'autoroute , ou encore comment une faille d'API permettait d'en déverrouiller à distance mais l'idée que la prise cause du réseau n'est pas neuve puisqu'en 2022 déjà, des chercheurs d'Oxford et d'Armasuisse avaient monté Brokenwire, une attaque qui coupait les charges à distance en brouillant ce même canal courant porteur, avec une radio logicielle LimeSDR et un ampli de 1 W. Ils ont tué des sessions jusqu'à 47 mètres, sur 8 voitures et 20 bornes rapides.

Ce qui change ici, c'est pas le canal, c'est ce qu'on trouve à écouter dessus car personne n'avait pensé à scanner la prise comme vous scanneriez un réseau d'entreprise.

L'avis publié par la CISA à ce sujet liste bien 3 failles sur la borne C6, mais une seule est notée 9,8 sur 10, et c'est celle du firmware qui s'installe sans vérification de signature. Les deux autres qui concernent la prise sont à 7,6, avec accès physique obligatoire. Je tiens à le préciser parce que j'ai vu passer des actus qui annoncent 3 failles à 9,8 partout et je n'y comprenais plus rien.

En tout cas, c'est corrigé. XCharge a poussé la mise à jour sur toutes les bornes concernées, et la CISA n'a constaté aucune exploitation dans la nature. Rassurez-vous donc, votre prochaine charge sur l'autoroute ne va pas transformer votre voiture en bagnole zombie explosive !

La France compte près de 200 000 points de recharge ouverts au public, et XCharge revendique une équipe sur place et plus de 2500 bornes rapides posées en Europe. C'est donc un modèle qui est touché mondialement et surtout, SaiFlow pense que le motif de cette faille se retrouve probablement chez d'autres fabricants, toutefois sans l'avoir démontré.

Bref, la prochaine fois qu'on vous dit qu'une borne c'est "juste" de la grosse électricité, vous saurez maintenant que c'est surtout un ordinateur avec une prise réseau dehors.

Merci à DjeDje pour l'info !

Source

Vous avez un site sous WordPress ? Alors lâchez tout ce que vous faites deux minutes, parce que là c'est du sérieux !!

Cette nouvelle attaque baptisée WP2Shell permet de compromettre une installation Wordpress sans passer par le moindre plugin. Heureusement, un patch est sorti en urgence le 17 juillet !

En temps normal, quand une alerte sécu tombe sur WordPress, le fautif c'est un plugin tiers vérolé , un truc installé un soir de flemme et oublié depuis des lustres. Mais cette fois, rien de tout ça puisque le trou de sécu se trouve dans le cœur de WordPress lui-même.

Dans le détail, WP2Shell enchaîne deux failles. La première, CVE-2026-63030 , est une confusion de route dans l'API REST batch, sur l'endpoint /wp-json/batch/v1. La seconde, CVE-2026-60137 , est une injection SQL bien planquée dans le paramètre author__not_in de WP_Query. Chacune dans son coin, c'est déjà vilain, mais mises bout à bout, elles offrent une exécution de code à distance.

Pas de compte, pas de mot de passe, et encore moins de plugin exotique mais simplement quelques requêtes HTTP et hop, c'est plié !

Côté versions, la chaîne complète touche WordPress 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Si votre site est dans cette fourchette, vous êtes donc exposé. Les correctifs sont arrivés avec les versions 6.9.5 et 7.0.2. Et si vous vous traînez encore une vieille 6.8.x, sachez que seule l'injection SQL vous concerne potentiellement mais qu'elle a été patchée depuis la version 6.8.6.

Derrière cette trouvaille, on trouve Adam Kues, chercheur chez Assetnote (une branche de Searchlight Cyber), qui a assemblé et documenté toute la chaîne avant de la remonter proprement via le programme HackerOne de WordPress. Les détails techniques les plus croustillants restent sous le coude le temps que la planète patche mais l'équipe a mis en ligne un outil, wp2shell.com , pour vérifier si votre site est vulnérable. Allez-y, ça coûte rien !

Autre signal qui ne trompe pas, WordPress.org a déclenché les mises à jour automatiques forcées sur les sites concernés. Une mesure réservée aux failles vraiment graves, comme à l'époque où la faille critique de Really Simple Security avait exposé des millions de sites. Il y a donc de bonnes chances que votre installation toute pourrie dont vous ne vous occupez pas parce que vous êtes un mauvais webmaster ^^ ait déjà été rustinée toute seule. Vraiment, vous ne méritez pas les équipes sécu de Wordpress ^^

Mais ne pariez pas votre site là-dessus non plus... Car si vous avez désactivé les mises à jour auto (et beaucoup d'hébergeurs et d'admins le font), personne n'aura rien poussé chez vous. Sans oublier qu'un bout de PoC circule déjà sur GitHub (les chercheurs gardent pour eux le dernier maillon vers la RCE, mais ça n'arrêtera pas longtemps les motivés), et les scans automatisés ont commencé.

En attendant de patcher, bloquez surtout donc l'accès anonyme à l'endpoint batch de l'API REST via votre WAF ou votre plugin de sécu. Attention, pas seulement la forme /wp-json/batch/v1 : sa variante ?rest_route=/batch/v1 doit sauter aussi, sinon autant laisser la clé sur la porte. Cloudflare propose d'ailleurs des règles toutes prêtes. Et pour durcir le reste de votre config, ma vieille série sur le sujet reste d'actualité.

En tout cas, quand on sait qu'il y a +500 millions de sites actuellement propulsés par Wordpress, même s'ils ne sont pas tous concernés par cette faille, ça reste une surface d'attaque gigantesque !!

Bref, filez vérifier votre version. Sous 6.9.5 ou 7.0.2, vous mettez à jour et vous bloquez le batch en attendant. Deux minutes chrono, et votre site dort tranquille !

Source : Security Affairs

Depuis 16 ans, il y a une énorme faille qui fait dodo dans le coeur de tout ce qui gère la virtualisation sous Linux et personne ne l'avait remarqué, jusqu'à ce que Hyunwoo Kim, un chercheur en sécurité connu sous le pseudo @v4bel débarque. Ce dernier vient de dénicher un use-after-free dans le shadow MMU de KVM, ce bout de code que KVM partage entre les processeurs Intel et AMD. Il a baptisé sa trouvaille Januscape (CVE-2026-53359), et croyez-moi, le scénario a de quoi filer des sueurs froides à n'importe quel hébergeur...

En pratique, quand vous louez une VM dans le cloud, vous y êtes root (normal, c'est votre instance). Mais si l'hôte autorise la virtualisation imbriquée, hé bien la faille vous ouvre en grand la porte vers la machine physique. Le code de démonstration que Kim a publié se contente de faire planter l'hôte, et il garde sous le coude un second exploit, non divulgué publiquement celui-là, qui transforme le même bug en exécution de code root sur l'hôte. Et il n'a pas trouvé tout ça par hasard, puisqu'il participait au kvmCTF de Google, un programme qui paie jusqu'à 250 000 dollars pour une évasion complète d'une VM vers son hôte...

À ce stade, l'isolation censée séparer les locataires d'un même serveur vole en éclats, les VM de vos voisins de palier comprises.

Le code fautif traîne depuis août 2010, du temps du noyau 2.6.36 et Kim présente d'ailleurs Januscape comme la première évasion d'une VM vers son hôte qui fonctionne aussi bien sur Intel que sur AMD, à sa connaissance en tout cas.

Maintenant, avant de couper le wifi et de partir élever des chèvres dans le Larzac, deux petites nuances quand même car l'attaque réclame deux conditions réunies : être root dans la VM invitée, et que l'hôte expose la virtualisation imbriquée. Pas mal d'hébergeurs ne l'activent pas, donc c'est pas non plus une apocalypse universelle. Par contre, pour ceux qui l'activent, c'est game over.

Mais bonne nouvelle, le correctif est déjà là donc si vous administrez des serveurs KVM, mettez à jour maintenant. Et si vous ne pouvez pas patcher tout de suite, la parade consiste à désactiver la virtualisation imbriquée en attendant, avec kvm_intel.nested=0 sur de l'Intel ou kvm_amd.nested=0 sur de l'AMD.

VENOM s'échappait déjà d'une VM en 2015 via un vieux driver de disquette, et plus récemment une faille kernel planquée neuf ans offrait un accès root sur une machine Linux. Ces "fantômes" dorment longtemps dans le noyau, et ils choisissent toujours le pire moment pour se réveiller. Voilà, comme d'autres failles Linux à patcher d'urgence , celle-ci mérite tout de suite votre attention.

Source

Samsung nous vend KNOX comme le gros cadenas de nos smartphones Galaxy mais il semblerait que ce soit un gros fail. Si vous ne connaissez pas encore KNOX, c'est la couche maison de Samsung qui garde un oeil sur tout ce qui tourne dans le téléphone afin de nous PROTÉGER (retenez bien ce mot c'est important...lol).

Et bien je vous le donne dans le mille mes petits Emile, des chercheurs de LucidBit Labs viennent de prouver l'exact inverse à cause d'une faille logée dans KNOX lui-même, qui est restée grande ouverte durant ces 8 dernières années. C'est la CVE-2026-20971, notée 7.8 sur l'échelle CVSS et elle concerne à peu près tous les Galaxy sortis depuis le S9.

Le problème, c'est que n'importe quelle appli, même un machin tout bête sans la moindre permission, pouvait déclencher la faille pour aller ensuite tripoter la mémoire du kernel et cibler par exemple une prise de contrôle totale de l'appareil. Rassurez-vous, le correctif est arrivé dans la mise à jour de sécurité de janvier 2026, donc filez dans Paramètres, Mise à jour logicielle, et vérifiez que vous l'avez bien.

Maintenant si votre Galaxy commence à dater et qu'aucune MAJ ne pointe son nez, c'est le moment peut-être de regarder si Samsung le maintient toujours, sinon opter pour une autre version d'Android ou acheter un smartphone pour les adultes (qui a dit iPhone ?? Rooooh).

Ce qui est fou quand même c'est que toute cette galère sort quand même d'un truc ajouté POUR renforcer la sécurité. Parfois les défenses deviennent la surface d'attaque... C'est à se demander si empiler des couches et des couches de sécurité c'est vraiment une bonne idée alors qu'il suffirait de bien verrouiller le système de base (le noyau Android)...

Bref, comme à chaque salve de failles Android , foncez mettre à jour votre Galaxy !

Source : Security Affairs