Si vous avez un site chez un hébergeur qui fait du mutualisé, il y a de bonnes chances que votre machine tourne sous cPanel. Et si je viens vous prendre la tête avec ça, c'est parce qu'il y a 2 jours, l'éditeur a publié un correctif pour une faille assez grave qui permet à un simple client du serveur d'en prendre le contrôle complet.

Le problème c'est une injection SQL dans EmailTrack, la fonction qui suit les statistiques d'envoi de mail. Un titulaire de compte authentifié, à condition d'avoir des droits liés au mail, peut ainsi s'en servir pour écrire les fichiers qu'il veut sur le serveur. Et de là, vous l'aurez compris, exécuter du code en tant que root...

Bref, le lendemain de cette alerte, la CVE-2026-67401 est sortie avec sa note : 9,9 sur 10 ! C'est quasiment un perfect et ce qui fait grimper le score aussi haut, ce n'est ni la difficulté de l'attaque, jugée faible, ni les privilèges nécessaires, faibles eux aussi mais c'est que les dégâts débordent largement du compte par lequel on est entré.

Et c'est ça qui change tout par rapport à une faille web classique. L'attaquant n'a rien à forcer depuis Internet, il lui suffit de s'inscrire chez l'hébergeur et de demander une adresse mail comme tout le monde. Ensuite, il ne choisit pas vraiment sa victime, mais embarque juste tous les sites qui vivent sur le serveur où il a atterri.

Bon, maintenant la partie moins drôle c'est que la CISA n'a encore relevé aucune exploitation, alors que pourtant, un chercheur a mis en ligne le même jour une preuve de concept en Python qui fait tout le taf d'exploitation de A à Z, du compte client jusqu'au root.

Son auteur précise qu'il ne l'a pas essayée sur une vraie cible et qu'il l'a développée à partir des informations dispo publiquement. Mais reste que la marche à suivre est désormais publique.

Rassurez-vous quand même, sur une configuration d'origine, il n'y a rien à faire puisque cPanel applique de lui-même, toutes les heures et via une tâche cron, les mises à jour de sécurité disponibles pour la version majeure en cours.

Sauf si l'admin a figé la version lui-même et n'a pas fait la mise à jour. Dans ce cas-là, ça devient craignos.

Donc si vous êtes chez un mutualisé, demandez vite à votre hébergeur le numéro de build exact de ses machines et comparez-le à la liste plus haut. S'il vous répond une version en 118 ou en 126, il n'y a malheureusement pas de build corrigé dispo pour lui. Il sera donc obligé de faire un upgrade rapidement !

Source : l'advisory de cPanel , la fiche CVE-2026-67401 et The Hacker News .

GitLab a sorti hier (lundi 17 août), un correctif d'urgence , complètement en dehors de son calendrier habituel, pour une faille qui permet à quelqu'un sans compte ni mot de passe de modifier ou de supprimer vos projets publics et des données utilisateur. Hé ouais c'est chaud et c'est pour ça que son score CVSS est de 9,4 sur 10.

5 jours plus tôt, le 12 août, GitLab publiait son patch de routine pour la 19.2, 19.1 et 19.0. C'est un périmètre normal puisque sa politique de maintenance ne couvre que la version stable et les deux précédentes. Mais comme là, on est dans l'exceptionnel, ce correctif du 17 août en couvre une quatrième, la 18.11, dont le support avait pris fin le 16 juillet dernier. Ils sont allés rouvrir une branche morte juste pour patcher ce GROS problème !

La faille elle-même, on n'en sait presque rien par contre. Estampillée CVE-2026-19478, c'est une histoire de directive GraphQL, mais GitLab ne dit ni laquelle, ni dans quelles conditions ça se déclenche. Les détails techniques sortiront vers la mi-novembre, c'est-à-dire 90 jours après le correctif, comme d'habitude, histoire d'être sûr que tout le monde ait patché son install.

Maintenant, la bonne nouvelle c'est que si vous êtes sur GitLab.com ou sa version Dedicated , vous n'avez rien à faire, puisque c'est déjà patché. En fait cette histoire ne concerne que les instances auto-hébergées.

Et parmi elles, tout le monde n'est pas impacté de la même manière. En effet, le vecteur d'attaque passe par le réseau et vise les projets publics. Cela veut dire que votre instance planquée derrière un VPN, sans visibilité publique, risque beaucoup moins que celle qui expose ses dépôts à Internet.

Ensuite, pour la mise à jour, ça dépend d'où vous partez. Entre la 18.2 et la 18.10, aucun correctif n'existe sur votre branche. Il faudra upgrader jusqu'à la 18.11.11, en vous arrêtant aux paliers de 18.5 et 18.8 s'ils sont sur votre route.

Si vous tournez déjà en 18.11, prenez la 18.11.11. Sur une 19, c'est 19.0.8, 19.1.6 ou 19.2.4. Et plus ancien que 18.2 ? Bah là, GitLab ne liste pas ces versions parmi les affectées, mais elles ne reçoivent plus de correctif depuis un bon moment, donc ce serait bien de mettre à jour quand même, hein...

Pour le moment, personne n'a signalé d'attaque et aucun exploit ou PoC n'a fait surface sur GitHub. Ça ne veut pas dire grand-chose, je vous l'accorde mais on se rassure comme on peut...

Allez, bon courage !

Source : The Hacker News

Hier, le 23 juillet 2026, la CISA, la NSA et le FBI ont sorti une alerte conjointe avec une douzaine d'agences alliées, et pour une fois leur message est assez court : Si vous auto-hébergez un serveur de messagerie Zimbra pas à jour, considérez que des espions russes lisent peut-être déjà vos mails !!

Voilà, le groupe s'appelle Laundry Bear (aussi connu sous le nom Void Blizzard chez Microsoft, ou TA488 chez Proofpoint), il est lié à l'État russe, et il exploite une faille connue de Zimbra depuis juillet 2025.

La faille, c'est la CVE-2025-66376. Il s'agit d'une XSS stockée dans la vieille interface Classic de Zimbra Collaboration, déclenchée par des directives CSS @import planquées dans un email HTML piégé. Le truc vicieux c'est qu'il n'y a pas besoin de cliquer pour se faire infecter. Vous ouvrez le mail, le JavaScript s'exécute tout seul, et voilà !! NVD note cette vuln 6.1 (interaction requise) quand le MITRE la monte à 7.2 (aucune interaction).

Et ce qu'ils récupèrent nos amis russes, là, c'est du lourd ! Une fois dedans, Laundry Bear siphonne vos 90 derniers jours d'emails, les adresses et mots de passe des comptes, l'annuaire complet de l'organisation (la Global Address List), et surtout vos jetons 2FA et codes de récupération. Autrement dit, même votre double authentification saute. Ils ont carrément développé un outil maison pour ça, baptisé "Ulej" (Улей, "ruche" en russe), qui exfiltre tranquillement les archives par requêtes DNS et HTTPS.

Zimbra a bien sûr corrigé la faille le 6 novembre 2025, dans les versions 10.0.18 et 10.1.13. Le patch existe donc depuis 8 mois ! Sauf que la campagne, elle, tournait déjà comme 0-day depuis juillet 2025, soit 4 mois avant le correctif. Résultat, entre les serveurs jamais mis à jour et ceux compromis avant le fix, on ne s'en sort plus. La CISA a même inscrit cette CVE à son catalogue KEV des failles activement exploitées. L'advisory conjoint des américains ne donne pas de décompte des victimes, mais le casting des cibles fait froid dans le dos puisque vous vous en doutez, l'Ukraine est en première ligne, ainsi qu'une tripotée de gouvernements sans parler des secteurs de la défense et l'énergie côté OTAN.

Si vous êtes concerné, et là je parle aux admins qui font tourner leur propre Zimbra, pas aux gens sur Gmail ou Outlook ^^, la marche à suivre est simple. Vous mettez à jour vers 10.0.18 ou 10.1.13 minimum, tout de suite. Et comme un serveur laissé sans patch durant des mois a de bonnes chances d'avoir déjà reçu de la visite, partez du principe que vous êtes compromis. Donc vous devez remettre à zéro tous les mots de passe, invalider les sessions actives, régénérer des codes 2FA, et jeter un coup d'œil dans les logs à la recherche de la commande CreateAppSpecificPasswordRequest ou de la chaîne "ZimbraWeb". Ce sont les traces que laisse le groupe Laundry Bear.

Ce genre d'attaque qui passe par un client mail, c'est devenu une spécialité des APT russes. Je vous en parlais quand APT28 transformait Outlook en backdoor avec NotDoor , et plus récemment quand des espions russes se faisaient piéger sur Signal . En général, la messagerie, c'est le coffre-fort d'une organisation, et ça ils le savent très bien.

Bref, si un Zimbra traîne quelque part sur votre infra, arrêtez de lire mon site et allez le patcher immédiatement !

Source

Le 26 février dernier, lors d'une réunion d'Austin Hackers Anonymous au Texas, le chercheur Andreas Makris a fait la démo d'un outil qui permet de générer de faux firmwares Unitree, que le robot avale sans broncher comme s'ils sortaient de l'usine de Hangzhou...

Car oui, Mesdames et Messieurs, les robots Unitree ne sont pas capables de déterminer si le firmware avec lequel ils se mettent à jour a été créé par Unitree ou par quelqu'un d'autre.

C'est ouf, non ? Le problème en fait, c'est que les paquets de mise à jour d'Unitree, c'est-à-dire les fichiers .upk qu'un Go2 ou un G1 télécharge tout seul, sont chiffrés avec TEA, un algo hyper minimaliste sorti de Cambridge en 1994.

La clé de chiffrement issue de cet algorithme se calcule ensuite à partir de trois constantes planquées dans le binaire du robot, + une graine aléatoire qui est stockée dans le paquet lui-même. Hop, comme ça vous avez la clé... Tout le monde a la clé, en fait !

Les trois constantes, en clair dans la doc de l'outil.

Et comme TEA est un algo symétrique, la clé qui déchiffre est aussi celle qui chiffre. Unitree s'en sert pour cacher le contenu de ses mises à jour, sauf que le robot, lui, comme il a été programmé avec les pieds, il en déduit que le paquet est légitime. C'est con, hein ? Une vraie signature, avec une clé privée gardée au chaud chez le fabricant, rendrait la contrefaçon impossible même en connaissant tout le reste.

Alors avant que vous ne débranchiez votre robot, je tiens à préciser un truc que Makris dit lui-même dans son dépôt : il n'existe pas de moyen public de livrer un firmware maison au robot. En effet, le canal de mise à jour passe par MQTT et n'accepte pas les paquets persos.

Cette faille a une belle note de 7,8 sur 10 mais exige un accès local et une action du propriétaire. Donc rassurez-vous, personne ne va reflasher votre chien robot qui fait des petits tours dans votre usine depuis un van garé sur le parking.

Le scénario réaliste, c'est plutôt le firmware véreux qu'on vous refile via un prestataire qui "met à jour" votre flotte, ou la clé USB d'un labo partenaire. Vous l'installez, votre robot le valide et vous n'avez aucun moyen de vérifier qu'il sort bien de chez Unitree. Bref, pour du matériel qu'on retrouve dans des labos de recherche et sur des sites industriels, c'est pas terrible !

Les firmwares décortiqués couvrent les gammes Go2 et G1, du Go2 Air au G1 Edu+, plus les modules moteur. Le NVD (National Vulnerability Database), lui, considère que toute l'offre actuelle du constructeur est concernée et surtout gag, y'a pas de correctif !!

On est quand même près de 5 mois après la publication, et y'a toujours rien. Je pense quand même qu'Unitree devrait revoir ses priorités et surtout revoir complètement la façon dont ils protègent leurs mises à jour.

De son côté, Makris n'a pas prévenu le fabricant. C'est pas un oubli, mais un choix car comme il l'explique dans son avis de publication , Unitree a montré une certaine hostilité face aux communications de divulgation. Donc, autant dire que le divorce est acté entre les chercheurs et l'entreprise chinoise.

Du coup ça nous fait quand même un quatrième épisode sur tout ce bordel. Le hack Bluetooth en 1 minute dont je vous parlais en décembre , les deux CVE sur le Go2 que je vous ai remis en mars , le backdoor vers un cloud chinois que Benn Jordan a popularisé en mai, et maintenant les mises à jour.

À l'époque, je me souviens que Benn Jordan conseillait carrément de ne plus jamais toucher au firmware pour garder l'accès root et surveiller ce que le robot envoie, sauf qu'on sait maintenant qu'une mise à jour officielle ne prouve rien, et que chacun peut forger la sienne. Breeeeef... pour du matos vendu à des labos et des industriels, je trouve ça vraiment pas sérieux.

Merci à Sammy pour le tuyau !

Source

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