Si vous faites tourner Veeam Agent pour sauvegarder un poste Windows, et surtout si plusieurs personnes s'y connectent, allez vérifier tout de suite son numéro de build parce que depuis quelques jours, un vilain exploit circule pour la faille CVE-2026-32996. Ce dernier est chaud patate parce qu'il permet à un utilisateur local sans droits particuliers de grimper jusqu'au compte SYSTEM, c'est à dire le compte le plus puissant de la machine.

Veeam évidemment ne minimise pas le problème et classe cette élévation de privilèges en gravité haute, avec un score CVSS de 7,3 sur 10. Elle touche l'agent en version 13.0.2.1102 comme toutes les versions antérieures de la branche 13.

Rassurez-vous, ils n'ont pas traîné parce que le correctif est disponible depuis fin mai. Mais visiblement, il y en a beaucoup qui n'ont pas fait la mise à jour puisque, hier, la société de sécurité Arctic Wolf a indiqué que des attaquants l'exploitaient activement. Par contre, on ne sait pas exactement comment.

Alors dans quel cas ça marche vraiment ?

Hé bien il faut que 2 choses réunies. D'abord il faut un accès local à la machine, parce que cette faille ne s'exploite pas à distance. Ensuite, une session d'administration doit être ouverte dans la console de l'agent (celle qui sert à piloter les sauvegardes).

Et de ce que j'ai capté, le souci c'est que cette session ne se shoote pas d'elle-même mais disparait uniquement quand on ferme la console, après un délai d'inactivité plus ou moins long. Ou alors à la déconnexion complète de l'utilisateur. Bref, autrement dit, sur un poste qu'on laisse ouvert toute la journée, c'est open bar !

Du coup, Arctic Wolf conseille de traiter en priorité les postes partagés, les serveurs, les machines d'administrateurs, et plus largement tout ordinateur où un compte sans droits qui tomberait entre de mauvaises mains suffirait à prendre la main sur toute la bécane. Bref, en gros faut patcher en priorité partout où y'a plus d'une personne touche au clavier.

Maintenant pour sécuriser vos machines, en fait tout dépend de la façon dont vous utilisez l'agent Veeam. S'il est piloté par Veeam Backup & Replication, le correctif arrivera de lui-même, donc vous n'avez rien à faire.

Par contre si vous utilisez l'agent tout seul, là c'est un peu plus tordu, parce que la version courante qui est sortie au mois d'août, la 13.1.1.700, n'est actuellement pas publiée sur les serveurs de mise à jour automatique. Donc la notification intégrée dans l'agent ne vous la proposera pas.

Ce qu'il faut que vous fassiez en fait, c'est ouvrir le menu About de l'agent, pour voir à quel numéro de build vous en êtes, et si vous n'êtes pas encore sur la dernière, et bien aller chercher directement l'installateur sur la page de téléchargement de Veeam.

Et si vous ne pouvez pas mettre à jour tout de suite, sachez qu'il n'existe aucune parade officielle côté Veeam. Tout ce que vous pouvez faire c'est restreindre l'accès local et interactif aux machines touchées, et réserver les droits d'administrateur local et d'opérateur de sauvegarde à ceux qui en ont vraiment besoin.

Voilà, vous l'aurez compris, s'il y a un Veeam Agent en version 13 qui tourne chez vous, dans votre entreprise, vérifiez bien que vous êtes sur un minimum, la version 13.0.3.1220.

Bon, entendez, salut !

Source : Security Affairs .

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