Youssef Sammouda, un chercheur en sécurité connu sous le pseudo sam0, vient de publier un article détaillant pas moins de 4 vulnérabilités de type XS-Leaks qu'il a découvertes chez Meta. Pour vous la faire courte, ce genre de faille permet à un site malveillant de déduire des informations sur vous sans même avoir besoin de pirater quoi que ce soit. Heureusement, tout a été patché depuis !

La première faille concernait Workplace (la version entreprise de Facebook) et son intégration avec Zoom. En gros, un attaquant pouvait créer une page web qui chargeait le callback Zoom de Workplace dans une iframe, et selon que l'utilisateur était connecté ou non à Meta Work, la redirection se comportait différemment. Et là, pouf, l'attaquant savait si vous étiez un utilisateur Meta Work. Pas besoin d'accéder à vos données, juste de mesurer combien de temps met une redirection. Vicieux, non ? Meta a casqué 2 400 dollars pour cette trouvaille.

La deuxième faille, c'était le bon vieux bouton Like de Facebook. Vous savez, ce petit widget qu'on trouve sur des millions de sites web ? Eh bien si vous étiez connecté à Facebook, le plugin pouvait révéler si vous aviez liké une page spécifique ou pas. Un attaquant n'avait qu'à mesurer le nombre de frames dans l'iframe pour le savoir. Encore 2 400 dollars dans la poche de notre chercheur.

La troisième était plus technique et bien trouvée. Le fichier signals/iwl.js de Facebook utilise Object.prototype pour ses opérations. En manipulant ce prototype depuis la page parente, un attaquant pouvait provoquer des erreurs différentes selon l'état de connexion de l'utilisateur, et même récupérer son ID Facebook. Ça, ça valait 3 600 dollars.

Et voilà, la quatrième concernait l'identification des employés Meta eux-mêmes via les domaines internes. Celle-là n'a pas rapporté de bounty (juste un "informative"), mais elle montre bien l'étendue du problème.

Au total, Youssef a empoché 8 400 dollars entre décembre 2024 et mai 2025, le temps que Meta corrige tout ça. Alors oui, c'est cool que ces failles soient maintenant corrigées mais ça fait quand même réfléchir sur la quantité de données qui peuvent fuiter sans même qu'on s'en rende compte.

Pour ceux qui veulent creuser le fonctionnement des programmes de bug bounty , c'est vraiment un système génial et hyper vertueux où tout le monde est gagnant. Les chercheurs sont payés pour trouver des failles, les entreprises patchent avant que les méchants n'exploitent. Y'a vraiment de quoi faire dans ce domaine.

Bref, bien joué Youssef Sammouda, grâce à lui quelques failles de moins chez Meta, et ça c'est cool !

Source

Si vous pensiez que vos écouteurs sans fil étaient capables de garder vos secrets, j'ai une mauvaise nouvelle pour vous !

Des chercheurs du groupe COSIC de la KU Leuven (les mêmes génies qui avaient déjà hacké des Tesla il y a quelques années) viennent de dévoiler WhisperPair. C'est le petit nom d'une série de vulnérabilités qui touchent le protocole Google Fast Pair, et vous allez voir, ça craint.

Le protocole Fast Pair, censé nous faciliter la vie en appairant nos gadgets en un clic, oublie en fait de vérifier si l'appareil est réellement en mode appairage. Du coup, n'importe quel petit malin situé à portée de Bluetooth (environ 15 mètres dans les tests) peut se connecter silencieusement à votre casque ou vos enceintes, même si vous êtes déjà en train d'écouter votre podcast préféré. Pas besoin de bouton, pas besoin de confirmation, rien. C'est un peu le retour de la faille BlueSpy dont je vous parlais l'année dernière , mais en mode industriel.

Et quand je dis industriel, je n'exagère pas car les chercheurs ont testé 25 modèles différents et 17 d'entre eux sont tombés comme des mouches. Des marques comme Sony, Jabra, JBL, Marshall, Xiaomi, OnePlus, Logitech et même les Pixel Buds de Google sont touchées. Et une fois connecté, le pirate peut faire pas mal de trucs sympas (ou pas) comme injecter son propre audio à fond dans vos oreilles, perturber vos appels, ou pire, activer le micro pour écouter ce qui se passe autour de vous.

Mais attendez ça va encore plus loin car pour certains modèles Sony et Google, un attaquant peut carrément enregistrer votre casque sur son propre compte Google. Et là, c'est le combo gagnant pour le stalker puisqu'il peut vous suivre à la trace via le réseau Find Hub (le "Localiser" de Google). Le plus dingue, c'est que ça fonctionne même si vous utilisez un iPhone et que vous n'avez jamais touché à un produit Android de votre vie.

Si vous recevez une alerte de tracking sur votre smartphone, vous penserez probablement à un bug de votre propre appareil alors que c'est un espion qui regarde vos déplacements en temps réel... C'est moche.

Bref, Google a bien essayé de patcher le truc, notamment pour Find Hub, mais les chercheurs ont déjà trouvé un moyen de contourner le correctif en quelques heures. C'est la course à l'échalote habituelle et le vrai souci, c'est que pour corriger ça proprement, il faut une mise à jour du firmware de chaque accessoire par son constructeur. Et on sait tous comment ça se passe... à moins d'avoir l'application dédiée de la marque (que personne n'installe jamais) et de penser à vérifier les updates, vos écouteurs resteront vulnérables pendant des années.

Du coup, que faire ?

Hé bien déjà, si vous bossez sur des trucs ultra-sensibles, méfiez-vous du Bluetooth dans les lieux publics. C'est moche à dire en 2026, mais la sécurité des objets connectés reste encore trop souvent le parent pauvre de l'ergonomie.

Et si vous voulez creuser les détails techniques, les chercheurs ont tout mis sur leur site dédié .

Source

Les entreprises se concentrent souvent sur les correctifs CVE en se basant uniquement sur les scores CVSS, et ne traitent immédiatement que les vulnérabilités « critiques » (9,0+). Cependant, la CVE-2025-62507 présente un risque important en raison de son ciblage d’infrastructures stratégiques à un risque élevé, avec une exploitation d’une simplicité déconcertante. Tribune – Redis est bien […]

The post Étude JFrog – Vulnérabilité RCE dans Redis first appeared on UnderNews.

Les entreprises se concentrent souvent sur les correctifs CVE en se basant uniquement sur les scores CVSS, et ne traitent immédiatement que les vulnérabilités « critiques » (9,0+). Cependant, la CVE-2025-62507 présente un risque important en raison de son ciblage d’infrastructures stratégiques à un risque élevé, avec une exploitation d’une simplicité déconcertante. Tribune – Redis est bien […]

The post Étude JFrog – Vulnérabilité RCE dans Redis first appeared on UnderNews.

Un rapport inédit de l’Anses, fruit de cinq ans de recherches, révèle comment les réseaux sociaux exploitent les vulnérabilités des adolescents et aggravent leurs souffrances. Grâce aux algorithmes et aux dark patterns, ces plateformes deviennent un terreau fertile favorisant une dégradation de...

Avis aux utilisateurs de n8n, j'ai une bonne et une mauvaise nouvelle à vous annoncer.

Non, je déconne, je n'ai qu'une mauvaise nouvelle à vous annoncer, et malheureusement, elle est du genre à vous faire lâcher votre café direct sur votre clavier mécanique de hipster.

Si vous utilisez cet outil génial d'automatisation (et je sais que vous êtes nombreux par ici, surtout depuis que je vous ai partagé cette énorme collection de workflows ), il faut qu'on parle de la CVE-2026-21877. C'est Théo Lelasseux qui a débusqué le loup, et croyez-moi, c'est pas un petit caniche.

C'est une vulnérabilité avec un score CVSS de 10.0, soit le niveau max mais attention, ça ne veut pas dire que n'importe qui peut rentrer comme dans un moulin sur votre instance. Toutefois, dans certaines conditions, un utilisateur authentifié pourrait réussir à faire exécuter du code non fiable par le service.

Concrètement, c'est une faille de type RCE (Remote Code Execution) liée à un souci de gestion de fichiers (on parle notamment d'écriture/pose de fichiers là où il ne faut pas), et n8n recommande d’ailleurs de désactiver le nœud Git en mitigation si vous ne pouvez pas patcher. Du coup, si l'attaque passe, ça peut mener à une compromission totale de votre instance, que vous soyez en self-hosted ou sur n8n Cloud. Brrrrrr, ça fait froid dans le dos quand on sait tout ce qu'on fait transiter par ces workflows !

Bon, pas de panique, mais faut agir.

Les versions touchées sont toutes celles comprises entre la 0.123.0 et les versions antérieures à la 1.121.3. Si vous êtes dans cette fourchette, vous avez donc un petit trou dans votre raquette de sécurité.

Pour corriger le tir, hop, on file mettre à jour vers la version patchée 1.121.3 ou une version supérieure. Et si une raison obscure (et sûrement très relou) vous ne pouvez pas patcher tout de suite, il est recommandé de désactiver fissa le nœud Git et de restreindre l'accès à votre instance uniquement aux gens en qui vous avez une confiance aveugle.

Et pendant qu’on y est : il y a aussi une autre saleté qui circule en ce moment, surnommée Ni8mare (CVE-2026-21858), décrite comme exploitable sans authentification via certains scénarios autour des Forms / webhooks, et patchée à partir de la 1.121.0. Moralité : si vous passez en 1.121.3+ (ce que vous allez faire là, maintenant ^^), vous vous couvrez aussi contre ce deuxième cauchemar.

Voilà, à vous de jouer maintenant ! On sauvegarde tout et on lance l'update avant de retourner à ses bidouilles !

Allez, kiffez bien (mais en sécurité) !

Source

Si vous utilisez MongoDB, accrochez-vous bien parce que là, c'est du lourd. Une faille critique baptisée MongoBLEED vient d'être découverte et elle touche à peu près toutes les versions de MongoDB sorties depuis 2017. Sept ans de versions vulnérables, c'est un chouette record, je trouve ^^.

Le problème avec cette CVE-2025-14847, c'est qu'elle exploite la compression zlib des messages. En gros, quand un attaquant envoie un message compressé mal formé avec des paramètres de longueur trafiqués, MongoDB se met à recracher des bouts de sa mémoire heap sans broncher. Et dans cette mémoire, on peut trouver des trucs sympa genre des mots de passe, des tokens d'authentification, des clés de chiffrement... Bref, le jackpot pour un attaquant.

Le pire dans tout ça c'est que y'a pas besoin d'être authentifié pour exploiter la faille. Si votre instance MongoDB est accessible depuis le réseau, n'importe qui peut s'y connecter et commencer à siphonner votre mémoire. C'est exactement le même genre de cauchemar que Heartbleed en 2014, d'où le petit surnom affectueux.

Du coup, qui est concerné ?

Hé bien à peu près tout le monde... Les versions 3.6.0 jusqu'à 8.0.16 sont touchées, ce qui représente selon les chercheurs de Wiz environ 42% des environnements cloud. Il y aurait donc plus de 87 000 instances MongoDB exposées sur Internet et le problème, c'est que depuis le 26 décembre 2025, des exploitations actives ont été détectées dans la nature. Joyeux Noël !!

La bonne nouvelle, c'est que le fix est simple. Soit vous mettez à jour vers une version patchée (8.2.3+, 8.0.17+, 7.0.28+, 6.0.27+, 5.0.32+ ou 4.4.30+), soit vous désactivez la compression zlib en attendant. Pour ça, c'est dans la config réseau de MongoDB, paramètre compressors qu'il faut virer le zlib.

Pour vérifier si vous êtes vulnérable, un petit nmap sur le port 27017 avec le script mongodb-info vous dira quelle version tourne. Vous pouvez aussi regarder les logs réseau pour détecter des connexions suspectes avec des messages compressés anormalement petits suivis de réponses anormalement grandes. C'est le signe qu'un petit malin est en train de vous pomper la mémoire.

Bref, si vous avez du MongoDB qui traîne quelque part, c'est le moment de faire un petit tour dans vos infras. Parce que là, c'est quand même d'une faille qui permet à n'importe qui d'aspirer vos données sensibles sans même avoir besoin d'un mot de passe. Ubisoft en a fait les frais et ça pique !

Source

Microsoft corrige 63 failles dont une exploitée activement dans Windows, incluant une vulnérabilité critique du noyau.

Faille critique CVE-2025-8489 dans King Addons for Elementor : des pirates exploitent activement la vulnérabilité pour compromettre des sites WordPress.

Deux failles 7-Zip (CVE-2025-11001/11002) permettent l’évasion de répertoire via symlinks. Mettez à jour vers la build 25.00.

— Permalink