Il y a quelques jours, durant la conférence Hexacon à Paris, un chercheur nommé Quentin Kaiser a rendu publique une faille de sécurité qui traîne depuis au moins 2010 dans la fonction WPS de Broadcom. Je dis "qui traine" au présent parce qu'elle n'est toujours pas patchée évidemment. Alors si vous ne savez pas ce qu'est WPS, c'est une fonctionnalité qui permet de connecter un appareil au WiFi sans avoir taper la clé.

Cela veut dire que quelqu'un à portée du réseau sans fil peut faire exécuter son propre code à une box ou à un point d'accès, sans avoir à connaître la clé du réseau et sans même mener un enrôlement WPS jusqu'au bout.

Son exploit, il l'a filmé sur deux box belges. Chez Orange Belgium (une Askey TCG3000), où son code lit la clé Wi-Fi dans la mémoire de la box et la renvoie via les ondes, ce qui lui permet ensuite de rejoindre le réseau. Chez l'opérateur Proximus (une BBOX3V+), il ouvre un shell à distance au travers des trames Wi-Fi, donc sans avoir recours à un serveur extérieur. L'antenne qu'on voit sur la vidéo ci-dessous ne doit d'ailleurs pas faire croire qu'il faut être collé à la box puisque d'après Kaiser, ça marche de loin !!

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/faille-wps-broadcom-routeurs-wifi/faille-wps-broadcom-routeurs-wifi-1.mp4">lien vers la vidéo</a>.

Hier, GitLab a publié en urgence les versions 19.4.2, 19.3.5 et 19.2.8 pour corriger une faille un peu chaude avec un score CVSS de 10 sur 10 . Référencée sous le code CVE-2026-97229, elle permet à quelqu'un sans compte user d'exécuter du code sur le serveur en glissant tout simplement une expression régulière piégée dans une configuration CI/CD.

GitLab précise que cela ne peut se faire que "sous certaines conditions" sans préciser lesquelles, et il ne dit pas non plus comment un inconnu pourrait faire lire sa config CI forgée par une instance. Gitlab mentionne une histoire de dépassement d'entier dans le compilateur de regex du CI/CD et d'une validation insuffisante des expressions mais on n'a pas les détails techniques qui sortiront dans environ 90 jours. C'est habituel pour laisser le temps à tout le monde de patcher.

Ces dernières semaines, ça enchaine fort ( un peu comme Citrix ) avec fin septembre, la 19.4.1 qui corrigeait déjà deux autres faille sur le même terrain : CVE-2026-93577, pour un dépassement d'entier dans le compilateur, et CVE-2026-89078, pour un double free dans l'analyseur de regex. Notées 9,9 toutes les deux et signalées par le même chercheur (joaxcar), mais celles-là exigeaient au moins un compte. Et la troisième faille (la CVE-2026-85706) découverte aussi courant septembre, était quand a elle aussi notée 10 sur 10 et permettait de lire les fichiers présents sur le serveur sans avoir de compte.

Alors qui est concerné ?

Hé bien toutes les instances auto-hébergées en 19.2 avant la 19.2.8, en 19.3 avant la 19.3.5 et en 19.4 avant la 19.4.2. Une 19.4.1 installée fin septembre n'est donc pas à l'abri. Le service GitLab.com en lui-même est déjà à jour et les clients serveur dédié n'ont rien à faire. Mais pour les autres, l'alerte de sécurité ne mentionne aucun contournement / fix. Faut juste mettre à jour et basta.

Sur une instance mono-nœud, prévoyez donc une coupure, parce que ce correctif embarque des migrations de base qui exigeront un reboot.

Voilà, maintenant que vous êtes au jus, c'est le moment de patcher !!

Source : BleepingComputer .

Je ne sais pas si vous êtes familier avec NetScaler de Citrix, mais c'est un équipement qui sert de passerelle d'accès à distance pour les salariés des entreprises, et qui peut aussi gérer l'authentification SAML.

Et ces derniers temps, l'équipement est un peu mis à mal. À cause notamment de deux failles 0day sorties fin septembre (surnommées PitScaler par le chercheur Kevin Beaumont), qui ont heureusement été patchées. Mais ces derniers jours, des admins ont vu quand même redémarrer en boucle leur NetScaler pourtant à jour dont des 14.1-73.37, la version censée corriger le problème...

Bizarre, bizarre, vous avez dit bizarre ?

Eh oui c'est bizarre ! Encore une vuln !! C'est la seconde vague en moins d'une semaine et c'est le bulletin de sécurité de Citrix qui le dit avec la CVE-2026-88779, qui est, cerise sur le gâteau, activement exploitée dans des attaques au moment où j'écris ces lignes.

Donc voilà, c'est le gros bordel du côté des entreprises clientes de Citrix !! D'après SecurityWeek, avant l'arrivée des correctifs, les files d'attente du support technique de Citrix duraient des heures... Et les contournements provisoires n'empêchaient pas systématiquement les plantages et autres redémarrages à répétition.

De quoi déprimer sévère... Certains clients de Citrix ont même dû débrancher leur matériel durant la première vague de failles. Et aujourd'hui, même ceux qui ont installé le correctif de PitScaler n'y échappent pas non plus s'ils utilisent SAML, puisque Citrix a sorti un nouveau correctif et leur demande de mettre à jour une seconde fois en très peu de temps.

Alors que se passe-t-il exactement ? Est-ce que c'est un simple déni de service ?

Eh bien en tout cas, c'est ce que dit Citrix.

Ce qu'ils expliquent, c'est que le service peut rester indisponible tant que l'attaque se répète et que pour le moment, ils n'ont pas identifié d'impact sur l'intégrité des données. Sauf que le chercheur en cybersécurité Kevin Beaumont a vu l'un de ses honeypots (qui était pourtant patché) faire tourner un binaire malveillant récupéré depuis le web.

Un autre admin a aussi trouvé dans ses logs des noms d'utilisateurs contenant des commandes shell, censées télécharger un fichier puis l'exécuter. Toutefois, ses logs ne prouvent pas que ces commandes ont réellement tourné.

Donc voilà, on est un peu tous dans le flou...

En juin, Citrix communiquait sur la CVE-2026-8452, consistant en un autre débordement mémoire côté SAML, et pouvant provoquer un "comportement imprévisible" ou un déni de service. Et selon la note de la Cloud Security Alliance , watchTowr a démontré en août que cette faille autorisait en réalité une exécution de code root sans authentification.

Donc même si rien n'indique que ce soit le même bug ici (le plantage d'aujourd'hui, c'est le processus nsaaad qui se vautre en boucle), ce n'est pas la première fois que l'explication "c'est juste un déni de service" se fait démonter. Beaumont rappelle d'ailleurs que la CVE-2025-6543 avait suivi le même chemin...

Voilà... donc côté correctif, Citrix a sorti des mises à jour qui règlent la faille (je vous donne les versions plus bas) et en complément, il propose aussi des listes de blocage d'adresses IP malveillantes. La CISA a également ajouté la faille à son catalogue le 4 octobre, avec une échéance de correction exigée pour le 7 octobre pour les agences fédérales américaines. C'est la sixième faille NetScaler exploitée qu'elle y inscrit cette année, d'ailleurs...

Maintenant, voici comment savoir si vous êtes concerné.

En fait, la faille ne touche que les appliances configurées comme fournisseur de service (SP) ou comme fournisseur d'identité (IdP) SAML. Cherchez donc dans votre config une ligne add authentication samlAction ou add authentication samlIdPProfile.

Et si vous en avez une, il faudra installer au minimum la 14.1-73.41 ou la 13.1-64.28 selon votre branche (ou la 14.1-73.41 FIPS, ou la 13.1-37.282 pour les FIPS et NDcPP en 13.1) de NetScaler, comme l'indique le bulletin de Citrix .

Voilà, bon courage à tous.

Merci à Thomas pour l'info !

Source : SecurityWeek

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

Rattrapé par le volume de CVE, le NIST ne promet plus de les enrichir toutes avant de les intégrer à la NVD (National Vulnerability Database).

L’agence gouvernementale américaine va prioriser certaines vulnérabilités. En l’occurrence, celles qui :

• Apparaissent dans son catalogue KEV (vulnérabilités exploitées)
• Affectent des logiciels qu’utilise le gouvernement fédéral
• Touchent des logiciels « critiques » selon la définition qu’en donne le décret présidentiel n^o 14028 de 2021

Ce décret définit comme tel tout logiciel qui inclut – ou a des dépendances directes envers – un ou plusieurs composants ayant au moins un des attributs suivants :

• Conçu pour fonctionner avec des privilèges élevés ou pour gérer des privilèges
• Dispose d’un accès direct ou privilégié aux ressources réseau ou de calcul
• Conçu pour contrôler l’accès aux données ou à l’OT
• Assure une fonction de confiance critique ou opère en dehors des limites de confiance normales avec un accès à privilèges

Une liste est annexée au décret. Elle vise assez large. Entre autres : IAM, OS, hyperviseurs, navigateurs web, monitoring, sécurisation du réseau et sauvegarde/restauration.

Jusque-là, le NIST attribuait systématiquement un score de criticité, même si les autorités de numérotation CVE l’avaient déjà fait. Ce ne sera plus le cas. Des demandes pourront toutefois lui être faites par e-mail. Même chose pour la réanalyse de CVE enrichies et ensuite modifiées. Par défaut, l’agence n’y procédera plus que si elle a connaissance d’une modification « sensiblement impactante ».

Il y a 2 ans, les premiers signaux

Au-delà du score de criticité, l’enrichissement des CVE apporte notamment des listes des éditeurs concernés, des renvois vers des bulletins tiers et des liens vers les correctifs disponibles.

Au printemps 2024, le NIST avait commencé à communiquer ouvertement sur l’accumulation des vulnérabilités à traiter. Il affirmait déjà prioriser les plus importantes. Et chercher une solution à long terme, comme la mise en place d’un consortium industriel. L’objectif était alors d’avoir écoulé le backlog pour l’automne.

En fin d’année, l’agence avait admis que cet objectif était trop optimiste. Elle avait invoqué, en particulier, la réception des CVE dans un format difficile à importer et à améliorer.

En mars 2025, ce format modifié, le NIST avait assuré avoir retrouvé son rythme d’avant le printemps 2024. Sauf que dans le même temps, le volume de CVE avait nettement augmenté…
Quelques semaines plus tard, il fut finalement décidé d’attribuer le statut « différé » aux CVE en attente publiées avant 2018. Un indicateur du fait qu’elles ne seraient plus prioritaires pour l’enrichissement.

Début 2026, l’agence avait esquissé les grandes lignes de ce qui est désormais officiellement sa nouvelle politique. Elle y voit une façon de « stabiliser » le programme NVD, le temps « d’améliorer les processus » et de « développer des systèmes automatisés ».

Le NIST sous pression budgétaire… comme le programme CVE

Cette évolution aura des conséquences en aval, sur les solutions qui exploitent la NVD. Parmi eux, nombre de SIEM, d’outils de pentest et de scanners de vulnérabilités.

L’absence de « caution NIST » systématique sur les scores de criticité peut poser question si on considère que certains éditeurs sont autorités de numérotation… et pourraient être tentés de minimiser l’importance de vulnérabilités dans leurs logiciels.

Sous la présidence de Donald Trump, l’agence évolue à budget réduit. Elle est dans le collimateur de Washington pour son « agenda climatique radical ». Emblème : son programme économie circulaire, qui se nourrirait de subventions universitaires pour promouvoir un « alarmisme environnemental ».

Le programme CVE, que gère l’organisation à but non lucratif MITRE, a lui aussi été un temps en danger. Son refinancement in extremis par le gouvernement US avait mis en lumière les travaux de l’Union européenne sur le programme alternatif GCVE (Global CVE Allocation System) et l’EUVD (EU Vulnerability Database).

Illustration générée par IA

The post Le NIST ne peut plus suivre le rythme des CVE appeared first on Silicon.fr.