Blogs on BZHunt

Éditeurs : comment passer d’une faille à une CVE (sans y laisser votre réputation) ?

Tue, 07 Apr 2026 16:21:30 +0200

TL;DR — Éditeurs, les vulnérabilités de vos produits sont inévitables — mais ne pas les traiter, les ignorer ou refuser de les formaliser (CVE) ne l’est pas. Entre divulgation responsable, exigences CRA/NIS2 et attentes clients, vous avez tout intérêt à reprendre la main : corriger vite, communiquer clairement et standardiser votre gestion des failles. À défaut, d’autres le feront à votre place — et rarement à votre avantage.

Transformer une contrainte en levier !

Dans un précédent article (cf. Quand les failles viennent de l’éditeur, le RSSI a des armes juridiques), nous donnions des éléments aux RSSI pour se défendre face à des éditeurs parfois peu enclins à assumer leurs responsabilités en matière de sécurité.

GLPI : Blind XSS → ATO → SSTI → RCE — anatomie d'une chaîne 0-day

Fri, 03 Apr 2026 18:09:52 +0100

Note de transparence — Cette recherche a été conduite avec l’assistance de Claude Opus 4.6 (Anthropic), utilisé par BZHunt dans son processus de R&D. Toutes les vulnérabilités ont été identifiées, vérifiées et exploitées par des chercheurs humains. Nous faisons le choix de la transparence sur l’usage de l’IA dans nos travaux, dans l’attente que des standards clairs émergent sur ce sujet.

TL;DR — CVE-2026-26026 (SSTI→RCE, Critique) et CVE-2026-26027 (Blind Stored XSS, Haute) dans GLPI 11.0.0–11.0.5 permettent de chaîner une Blind Stored XSS non authentifiée avec une Server-Side Template Injection (SSTI) pour obtenir une exécution de code à distance (RCE) sans aucun compte préalable. Score CVSS : 9.1 / Critical (CVE-2026-26026). Patch : GLPI 11.0.6 (3 mars 2026).

NetNTLMv1 : cryptanalyse, rainbow tables et fin de vie — ce que votre SI risque encore

Wed, 04 Feb 2026 18:09:52 +0100

TL;DR — NetNTLMv1 repose sur DES, un algorithme cryptographique symétrique cassé depuis les années 90. Des rainbow tables précalculées permettent de retrouver le hash NT (pass-the-hash ready) depuis un challenge/réponse NetNTLMv1 intercepté sur le réseau — sans GPU dédié, sans FPGA (sous réserve d’un challenge fixe 1122334455667788). Mandiant l’a démontré à grande échelle en ce début 2026. Notre outil shuck.sh, développé par Yann CAM, y est cité. BZHunt a reproduit l’attaque. Si votre SI accepte encore NetNTLMv1, ce n’est plus un risque théorique.

Pentests LAN : quand les failles viennent de l'éditeur, le RSSI a des armes juridiques

Tue, 20 Jan 2026 18:09:52 +0100

TL;DR Cet article s’inscrit dans la continuité de nos travaux avec Me Marc-Antoine Ledieu sur le droit de pentester l’hébergeur du pentesté. Nous transposons ici le raisonnement juridique aux éditeurs de logiciels dont les produits, déployés dans le LAN de nos clients, introduisent des vulnérabilités structurelles.

Le constat qui revient à chaque mission

Chez BZHunt, nous réalisons des pentests d’infrastructures internes pour des entreprises de toutes tailles et de tous secteurs. Et le constat est récurrent, presque systématique : une part significative des vulnérabilités critiques que nous identifions ne provient pas d’erreurs de configuration du client, mais de défauts structurels introduits par les logiciels déployés dans son LAN.

CVSS 3.1, CVSSv4 et EPSS : le guide du RSSI pour prioriser sans se noyer

Fri, 02 Jan 2026 08:00:00 +0100

TL;DR — Un score CVSS élevé ne signifie pas qu’une vulnérabilité sera exploitée demain. Un score EPSS faible ne signifie pas qu’elle ne le sera jamais. La vraie priorisation naît de la combinaison des deux — contextualisée par votre exposition réelle. Ce guide vous explique tout, avec une calculette interactive pour calculer vos score CVSS !

Pourquoi ce guide ?

Chez BZHunt, nos pentesters publient régulièrement des CVE. À chaque publication, la même question revient de la part des RSSI : “9.8, c’est grave ?”. La réponse honnête est : ça dépend. Pas de votre infrastructure en premier lieu, mais de ce que vous lisez réellement dans ce score.