Est-ce que vous vous souvenez de ce petit lien "Learn more" dont je vous avais parlé il y a un mois environ et qui permettait d'ouvrir un compte local lors de l'installation de Windows 11 Home sans passer par l'invite de commandes ? Eh bien Bob Pony, l'utilisateur de X qui l'avait repéré, vient de déclarer que ça avait été "discrètement" patché côté serveur .

Pour ceux qui l'avait raté, le concept c'était que sur l'écran qui vous réclame un compte Microsoft, le petit lien "Learn more" présent dans le paragraphe sous les "Sign-in options" pouvait nous envoyer direct sur la création d'un compte local. Comme ça pas de base de registre à bidouiller, ni de Wi-Fi à suspendre...

Comme quoi, une simple erreur peut engendrer beaucoup de bonheur !

Alors, c'est finito pour de bon ?

Parce qu'un correctif côté serveur, ça ne s'évite pas, hein surtout que comme le rappelle Windows Latest , l'installation repose sur des composants web, ce qui veut dire que même garder une vieille ISO sous le coude ça ne servira à rien.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/windows-11-lien-learn-more-corrige/windows-11-lien-learn-more-corrige-1.mp4">lien vers la vidéo</a>.

En tant que personne qui passez votre vie sur Internet, vous avez peut-être déjà décidé à un moment de bloquer une catégorie de sites pour protéger votre foyer ou votre tranquillité d'esprit (parfois on a des idées folles, je sais), et là paf ! Le filtre posé vous bouffe un site tout à fait légitime que vous n'aviez pas imaginé se faire pincer. Genre vous bloquez tout ce qui touche aux jeux d'argent et d'un coup votre site d'actualité foot préféré dégage parce qu'il a le malheur de parler de l'actu des paris sportifs une fois de temps en temps. La plupart du temps les seules options étaient soit arrêter de consulter le site, soit retirer le filtre entièrement ... et donc revenir à la situation initiale. Super.

Eh bien, Surfshark a décidé de régler ce problème dans sa suite d'outils et cela de la manière la plus simple possible : en proposant une option qui vous permet de créer une liste blanche dans son bloqueur de contenu web maison. Vous allez toujours décider de bloquer une catégorie qui vous pose problème, mais vous pourrez indiquer les exceptions que vous jugez acceptables. Fini le tout-ou-rien, fini le "bah je vais tout désactiver, ça me saoule".

Pour l'instant, le hic c'est que cette liste blanche n'est disponible que pour les utilisateurs Windows (ouiiiin). Pour les utilisateurs de Mac, de Linux ou de mobiles, il faudra attendre encore un peu que ce soit déployé sur d'autres OS, mais cela ne devrait pas tarder. Ouais, je sais, ça fait toujours un peu mal quand les meilleures plateformes du monde ne sont pas privilégiées. D'un autre côté il faut se dire que l'OS le plus moisi a aussi le droit d'avoir des primautés parfois. C'est la vie.

C'est quoi ce fameux web content blocker ?

Disponible depuis l'automne 2025 sur Android et iOS, puis courant 2026 sur desktop, le web content blocker est la fonction de filtrage par catégories de Surfshark. Cette option vous donne la possibilité de mettre un stop aux thématiques de sites que vous préféreriez ne plus jamais voir. On parle ici de catégories problématiques selon votre profil, votre situation et/ou qui utilise votre machine. Il s'agit des classiques : pornographie, jeux d'argent, armes, drogues, malwares et compagnie.

Ce qui est cool, c'est que ça tourne même si vous n'êtes pas en train d'utiliser le VPN. Donc vous pouvez l'utiliser sur les appareils de la maison en continu même quand personne n'est connecté à un tunnel. Il faut donc prendre en compte que c'est une solution de contrôle parental différente des outils classiques sur ce sujet. Surfshark ne surveille que dalle (pas de logs de navigation, pas de rapport hebdo sur "ce que le gamin a visité cette semaine") et ne pose pas de limites (temps d'écran, blocage d'apps ...). La fonctionnalité va aider les utilisateurs à protéger leurs proches du contenu malveillant, mais sans espionner pour autant les sites qu'ils visitent. Ce qui reste consistant avec leur politique de no-logs qui a été auditée plusieurs fois ces dernières années.

C'est plutôt pas mal parce que ça pourrait être une alternative à ceux qui pensent que la plupart des logiciels de contrôle parental ne sont rien d'autres que du mouchardage avec des logos mignons. Ici c'est juste du filtrage fin et basta. Une couche de protection supplémentaire qui s'ajoute sans transformer votre machine en agence de surveillance gouvernementale.

Et concrètement ça ressemble à quoi ?

C'est vraiment super simple et à la portée de tout le monde. Vous commencez par ouvrir votre application Surfshark sur Windows, vous allez dans Paramètres > Bloqueur de contenu web > Sites Autorisés, vous cliquez ensuite sur le bouton "Ajouter" et vous saisissez les URL à autoriser. Hormis vos exceptions, l'ensemble de la catégorie reste filtré. Bien entendu vous pouvez ensuite activer ou couper le blocage à votre convenance, ajouter et supprimer des urls, etc.

Même si ce n'est pas une fonctionnalité incroyable, c'est le genre de petit ajustement qui améliore notre qualité de vie l'air de rien. Et qui permet de se passer éventuellement d'une extension de navigateur supplémentaire. Le vrai problème du filtrage par catégories, qui reste un élément assez vague, ce sont souvent les résultats de type faux positifs. Une catégorie, c'est plutôt large ("Sport", "Robotique" ou "Tech" c'est vaste). Trop large. Ici au moins, on a la possibilité d'affiner au fil du temps.

Alors oui, vu la communauté qui me lit, j'entends d'ici les puristes à la capillarité abondante me dire qu'un filtre DNS maison avec Pi-hole fait la même chose et bien plus. Oui, vous avez raison. Vrais reconnaissent vrais, comme dirait votre rappeur préféré. Sauf que dans le monde du dehors et bien pas grand monde n'a envie d'administrer un Pi-hole un dimanche après-midi, hein. C'est drôle, le monde. Il y a les gens qui bidouillent, et les gens qui veulent juste cliquer sur "Ajouter" vite fait pour avoir le temps d'aller promener le chien. L'option est pour eux.

Et le reste de la panoplie Surfshark One ?

Même si je viens de vous faire un article sur le sujet, ce filtre à contenu, c'est juste la cerise sur le gâteau. Surfshark One , c'est versatile et ça gère un tas de problématiques liées à la cybersécurité :

• Son VPN permet un nombre de connexions simultanées illimitées (pas de limite !) donc il permet de protéger toutes ses machines. Avec un parc de 4 500+ serveurs répartit dans plus de 100 pays, un chiffrement militaire AES-256 et, depuis quelques mois, des serveurs 100% RAM-only où rien ne persiste après un simple reboot. Plus un tas de fonctionnalités comme le bouton kill switch (coupe votre connexion si le tunnel tombe), le MultiHop (permet de faire passer votre trafic par 2 pays), le mode camouflage, etc.
• L'antivirus effectue des scans rapides et complets et offre une protection en temps réel. Il dispose même de l'intégration d'un outil anti-ransomware. L'antivuris est tellement bon qu'il a reçu un score de 100% dans les tests phishing de PCMag. Et 100%, c'est pas rien quand même, par une équipe qui teste des VPN et des antivirus toute la journée. Surtout que cet été ils ont aussi décerné à Surfshark leur Editor's Choice award. Quand ils te collent une récompense, c'est que t'as fait un truc correct normalement. L'antivirus est dispo sur Windows, macOS et Android. L'iPhone est laissé de côté pour l'instant donc un peu de patience.
• La fonctionnalité Alert, de son côté, surveille vos emails, numéros de carte et pièces d'identité dans les fuites de données connues. Et vous contacte en temps réel dés que vos informations ont fuitées. Ce sera peut-être utile le jour où votre vieux compte MySpace ou Facebook abandonné depuis 15 ans refait surface sur un forum russe ou chinois.
• Je vous ai déjà parlé d' Alternative ID , qui vous permet de créer une fausse identité complète avec une son adresse mail personnalisée. Celle-ci fait office d'intermédiaire qui renverra toute communication vers votre vraie boîte. À utiliser par exemple pour vous inscrire sur divers sites en ligne qui ne vous inspirent pas trop confiance. Ou sur des sites que vous ne réutiliserez jamais. Le jour où leurs bases de données se font pirater, c'est la fausse identité qui est grillée, pas la vôtre.
• En plus vous avez accès à CleanWeb, leur bloqueur de pubs et de popups cookies. Le site de référence AdBlock Tester lui a octroyé un assez bon score (96%). Et oui, si vous vous posiez la question, il bouffe les pubs YouTube comme du popcorn. Rien que cette option-là vaut un tiers de l'abonnement à elle seule pour certains.

Et si vous voulez absolument tout maitriser niveau sécu, vous pouvez adjoindre à tout ça Incogni, qui est inclus dans l'abonnement supérieur One+. Une fois configuré avec vos demandes de suppression, le service contacte automatiquement les data brokers à votre place. Parce que demander soi-même à 300 sites d'effacer vos données de leurs bases, personne n'a le courage ni le temps. Le RGPD vous donne des droits, mais c'est Incogni qui fait la paperasse.

Combien ça coûte, tout ça ?

Depuis son arrivée sur le marché, Surfshark reste un des meilleurs du marché point de vue rapport qualité-prix (voir aussi mon comparatif des meilleurs VPN du moment). En ce moment, sur un engagement de 27 mois (24 mois + 3 offerts) cela donne :

• Starter : 2,49 € HT/mois pour le VPN seul
• One : 2,99 € HT/mois pour ajouter l'antivirus, Alert, Alternative ID et le web content blocker
• One+ : 4,49 € HT/mois pour avoir Incogni en plus

Moins de 4 balles par mois TTC (One) pour protéger tous vos appareils, ceux de votre mère, de votre frère, de votre coloc et du pote qui squatte votre canapé depuis la canicule de cet été ? Le calcul est vite fait. C'est carrément moins cher que 2 sandwichs triangles dégueulasses par mois. Votre santé numérique vous remerciera. Avec cette liste blanche enfin disponible pour corriger les dégâts du filtrage automatique, vous allez enfin pouvoir dégager les sites pourris chez vous, ou sur votre lieu de travail, sans devenir un agent du KGB aux yeux de votre entourage !

Je profite de l'offre Surfshark One !

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

La société de sécurité Depthfirst a publié un billet que j'ai trouvé intéressant dans lequel ils expliquent en gros que les conteneurs (Docker et compagnie) ne sont plus une barrière de sécurité suffisamment solide. La thèse du papier, c'est qu'il faut désormais partir du principe qu'un attaquant (hacker ou malware) saura sortir d'un conteneur quand il le veut, sans grande difficulté.

En effet, un conteneur comme ceux que font tourner Docker ou Kubernetes, donne à un programme l'impression d'avoir sa propre machine. Sauf qu'en réalité, il n'embarque pas de système d'exploitation. Tous les conteneurs d'un serveur passent par le même noyau Linux qui est celui de l'hôte et dont le rôle est de gérer pour eux la mémoire, le processeur ainsi que le réseau.

Toutefois, beaucoup d'organisateurs de CTF notamment s'y fient les yeux fermés et hébergent plusieurs épreuves sur le même serveur, chacune dans son conteneur, en comptant uniquement sur la sécurité de l'hôte. Mais c'est un faux sentiment de sécurité, j'en veux pour preuve ce bulletin de sécurité d'AWS daté de novembre 2025 où il est expliqué que l'entreprise ne considère plus les conteneurs comme une barrière de sécurité et ne s'en sert donc plus pour isoler ses clients les uns des autres.

Ce qui a changé depuis quelques mois, vous le savez, c'est le prix d'entrée de la recherche de failles puisqu'avec les modèles d'IA de pointe, même un attaquant avec des moyens modestes peut fabriquer sans effort, dès la publication d'une faille, un exploit contre des machines qui ne sont pas encore corrigées, alors qu'avant ça demandait de sérieuses compétences.

source : Depthfirst

Et les chiffres publiés par Depthfirst montrent que tout ça s'accélère puisque 249 CVE ont été publiées pour le noyau Linux en janvier, et en août on en a eu 1 650 !

Depthfirst relève également que sur les 36 CVE divulguées via le kernelCTF de Google, 13 sont réalisables via des interfaces ordinaires comme celles qu'un conteneur reçoit par défaut (dont les sockets locaux). En fait, on en croise sans le savoir dès qu'on passe systemd, Docker ou une base de données locale.

Le 24 juillet dernier, Depthfirst a même décroché une place au kernelCTF avec un exploit 0day (donc avant tout correctif) et aujourd'hui, le PoC est en accès libre sur GitHub. Rassurez-vous, côté noyau Linux, le correctif est sorti le 6 août mais malheureusement, côté Ubuntu la mise à jour au 24 septembre, affichait encore que le noyau de la 26.04 était en "Vulnerable, work in progress" et celui de la 24.04 en "Vulnerable". Bref, trouver des vulns ça va vite. Fixer ces vulns sur TOUTES les releases et les machines, ça prend du temps. Alors qu'avant c'était l'inverse. Bref, tout a été chamboulé et c'est un peu la merde maintenant niveau cybersécurité pour patcher rapidement.

Alors comment se protéger de tout ça ?

Hé bien la solution de Depthfirst va vous mettre en PLS car eux proposent carrément de ne plus partager le noyau. Ils recommandent à la place de migrer les charges non fiables vers des microVM, autrement dit des machines virtuelles légères où chaque charge aura son propre noyau. Le projet Firecracker en fait partie tout comme Kata Containers comme ça, en théorie, si un attaquant casse l'un de ces noyau, il ne compromet que sa propre instance et pas l'hôte dans son entièreté ni ses voisins.

Reste que Firecracker s'appuie sur KVM, la brique de virtualisation du noyau Linux de l'hôte. Et comme vous le savez, KVM a eu ses propres failles. En effet, cet été, la faille Januscape ouvrait en grand la porte de la machine physique à un attaquant pourtant enfermé dans sa VM, à condition bien sûr que l'hôte autorise la virtualisation imbriquée (une VM dans la VM). Alors certes, la surface d'attaque est plus petite mais loin d'être nulle.

Voilà, en attendant, si vous êtes sous Ubuntu 24.04 ou 26.04, surveillez bien la mise à dispo du prochain noyau. Canonical a d'ailleurs annoncé il y a peu, une publication hebdomadaire des noyaux pour tenter de compenser cet emballement.

Source : le billet de recherche de depthfirst

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 .

Les failles qui permettent à une machine virtuelle de s'échapper vers la machine qui l'héberge, ça court pas les rue. Et celle qui vient de débarquer est plutôt impressionnante ! En effet, il y a quelques jours, le chercheur Hyunwoo Kim a publié la CVE-2026-89775, qui est une évasion "invité vers hôte" bien planquée dans KVM (sur les archis ARM64). Pour rappel, KVM c'est la brique de virtualisation du noyau Linux. Et le score CVSS grimpe même jusqu'à 9,3 sur 10 ! Donc, autant dire que c'est du sérieux.

En fait, cette faille permet à la VM de lire et d'écrire dans la mémoire du noyau de l'hôte à grand coups de 64 bits à la fois ^^, sans même déclencher le garde-fou censé lui rendre la main. C'est possible à cause d'un simple calcul de taille qui retombe à zéro. Du coup, le noyau considère que ce zéro est une taille valide, ce qui permet d'éviter l'invalidation du cache mémoire.

Kim décrit deux façons de s'en servir. La première, c'est l' évasion classique où depuis une VM on peut débouler sur la machine hôte. Autant dire que c'est le cauchemar de quiconque loue de l'ARM à plusieurs clients.

La seconde, quand à elle, est plus vicieuse et souvent oubliée. Sur des distributions comme RHEL, le fichier /dev/kvm est ouvert à tout le monde en écriture. Cela permet ainsi à un simple utilisateur sans droits de se servir de la faille comme d'un ascenseur vers root, sans avoir à lancer la moindre VM.

Alors, est-ce que vous êtes concerné ??

Il y a de bonnes chances que non car sur ARM64, la virtualisation imbriquée n'est pas un mode par défaut de KVM. Il faut l'activer soi-même au démarrage avec kvm-arm.mode=nested, et être sur une puce assez récente.

Mais si vous administrez pour de vrai un hôte ARM64 avec la virtualisation imbriquée active, là oui ! Un uname -r vous donnera votre version mais sachez que rien n'est impacté avant le noyau 6.16 et que le trou est colmaté à partir des versions 6.18.51 et 7.2.5. Red Hat prévient qu'aucun contournement "propre" n'existe, donc ce sera le correctif ou rien, déso ^^.

À ce jour, le chercheur en sécurité, Kim, a livré le mécanisme mais pas de code d'exploitation. Donc, prenez le temps de corriger le problème sans traîner, mais ne paniquez pas non plus car ce n'est pas encore exploité activement.

Source : la divulgation de Hyunwoo Kim sur oss-security .

Si vous utilisez ChatGPT gratuitement, il y a de bonnes chances que votre navigateur se balade avec un affreux cookie baptisé __obi, posé là par OpenAI et avec une durée de vie de un an. Un chercheur qui publie sous le pseudonyme Buchodi a analysé son fonctionnement et publié un rapport très intéressant ce week-end dans lequel on apprend que ce cookie permet à OpenAI de choper des datas sur les sites marchands que vous visitez.

Le principe est celui du pixel publicitaire, exactement comme celui que Meta et Google vous font installer à l'insu de votre plein gré depuis des années. Une boutique qui achète de la pub dans ChatGPT colle un bout de code d'OpenAI sur ses pages, et ce code les prévient quand vous achetez un truc. Sauf qu'ici, comme __obi est configuré en SameSite=None, votre navigateur l'attache tout seul à la requête qui charge le script, avant que la moindre ligne de code ne s'exécute.

Et cet identifiant n'est pas anonyme ! En effet, sur chatgpt.com, il est généré aléatoirement puis signé par le serveur avec un jeton qui contient aussi l'identifiant de votre compte. Les deux voyagent ainsi collés-serrés l'un à l'autre, ce qui permet donc de vous identifier très précisément. Buchodi explique sur son site qu'il n'a cependant pas observé OpenAI faire le rapprochement côté serveur, mais que ces derniers ont tout ce qu'il faut pour le faire. Sur son mobile, un même __obi est utilisé depuis 12 boutiques, dont Wayfair, HelloFresh ou encore Coursera.

Et le plus rigolo dans tout ça, c'est qu'OpenAI documente absolument tout publiquement sur ce pixel. On lit par exemple dans la doc que le SDK considère que vous y avez consenti par défaut, et que l'annonceur doit écrire une ligne de code explicite pour dire le contraire. On y lit aussi ce que le pixel récupère tout seul depuis la page du marchand : il détecte ainsi votre email, votre téléphone et votre nom, les hash en SHA-256 dans le navigateur, et envoie aussi votre ville et votre code postal en clair. Woohoo \o/ !

Maintenant, le truc qui va faire bondir la secte des adorateurs du RGPD c'est que la politique de cookies d'OpenAI, classe __obi dans la catégorie des "Cookies analytiques". Hé oui, ce sont ces fameux cookies qui, je cite "les aident à comprendre comment leurs Services fonctionnent et sont utilisés". C'est même la seule entrée de cette section dans leurs cookie policy , alors que la catégorie marketing juste en dessous nous aligne du LinkedIn, du Google, du Reddit, du Meta, du Bing et du TikTok. Voilà, donc si vous avez accepté les statistiques en refusant le marketing, bah vous l'avez quand même. "Chè" comme dirait Sam Altman !

Buchodi a donc posé la question à OpenAI et "bizarrement", le support a accusé réception mais n'a jamais répondu...

Alors est-ce que vous êtes concerné par cette saloperie ?

Eh bien ça dépend de votre navigateur. Safari, le bienheureux, bloque tous les cookies tiers par défaut depuis 2020, et comme tous les navigateurs iOS tournent sur ce moteur, aucun d'entre eux ne laisse passer le cookie d'OpenAI. Firefox, le vrai navigateur des champions, quant à lui, range les cookies dans un conteneur séparé par site depuis 2022, ce qui casse totalement le recoupement sans péter les sites. Et Chrome, le navigateur des gens qui ne tiennent pas à leur vie privée, a lui renoncé en avril 2025 à supprimer les cookies tiers, et c'est justement sur Chrome sous Android que ce mécanisme d'OpenAI a été observé.

Alors que faire ?

La bonne nouvelle, c'est que la parade la plus solide est sans doute déjà en place chez vous. EasyPrivacy, la liste antipistage activée par défaut dans uBlock Origin , contient déjà les règles ||bzr.openai.com^ et ||bzrcdn.openai.com^. Comme elles bloquent le domaine entier, elles coupent aussi la requête qui pose le cookie au départ, sur chatgpt.com. Et si vous filtrez avec un DNS grâce à un Pi-hole ou NextDNS , ajoutez ces deux domaines et vous couvrez toute la maison, téléphone sur Wifi compris.

Par contre, ne comptez pas sur Safari ou Firefox pour tout régler par défaut car ils s'occupent du cookie, mais pas du reste. En effet, la requête vers OpenAI part quand même, avec votre adresse IP, votre code postal en clair et votre email hashé si le marchand a activé la détection automatique. Et le pixel a son grand frère côté serveur, une API appelée depuis les serveurs du marchand, qu'aucun réglage de navigateur n'atteindra malheureusement.

Et ne vous dites pas que c'est une histoire uniquement américaine puisque depuis fin août, ChatGPT Ads couvre la France et 30 autres pays européens. Les pubs ne s'affichent que sur les comptes Free et Go (moi j'ai pas de cookies __obi avec mon compte payant) et le cookie se synchronise aussi quand vous êtes déconnecté.

Bref, allez jeter un œil à vos filtres. Et si vous voulez voir votre cookie __obi, il traîne dans les cookies de .openai.com.

Source : l'enquête de Buchodi et la documentation du pixel OpenAI .

Google a commencé cette semaine à ouvrir sa maison connectée aux assistants IA concurrents : ChatGPT, Claude (le modèle d'Anthropic, le grand rival d'OpenAI) ou des agents moins connus comme Hermes et OpenClaw peuvent maintenant piloter vos caméras Nest, vos thermostats et vos ampoules compatibles Matter, le standard commun de la domotique.

Tout passe par un serveur MCP, pour Model Context Protocol, une sorte de prise universelle qui permet à n'importe quel agent IA de se brancher sur un service pour y lire des données et y déclencher des actions. Jusqu'ici, Gemini gardait ce privilège pour lui tout seul.

Google en profite pour mettre en avant Antigravity, son propre agent IA, et propose aussi un second serveur pensé pour les développeurs, qui branche les outils de codage sur la documentation officielle de Matter et des API de Google Home.

Une fois connecté, l'agent peut fouiller l'historique de vos appareils, résumer ce que vos caméras ont vu dans la journée, diffuser un message sur vos enceintes ou même vous fabriquer un tableau de bord sur mesure.

Une exception quand même. Google a interdit d'office le déverrouillage des serrures connectées, et la reconnaissance faciale des caméras réclame un consentement séparé, preuve que quelqu'un a pensé aux scénarios catastrophe.

Sauf que voilà, Google ne cache même pas le risque : Taylor Lehman, le responsable produit de Google Home et Nest, prévient que selon l'agent choisi, la connexion "peut entraîner un comportement inattendu, voire indésirable". Une honnêteté assez rare dans une annonce officielle, et franchement pas très rassurante.

Le problème est connu : un agent IA interprète vos demandes en langage naturel, et il peut se tromper, inventer un ordre qui n'existe pas ou se faire manipuler par un texte piégé glissé dans une page web qu'il consulte. Lui confier le chauffage, les lumières et les caméras d'une maison entière, et ben c'est casse-gueule.

Pour l'instant, seuls les abonnés américains à Google Home Premium Advanced, la formule à 20 dollars par mois, y ont droit, avec un déploiement étalé sur une à deux semaines et aucune date annoncée pour la France.

Et il faudra le mériter : la configuration impose de créer un projet Google Cloud, la plateforme normalement réservée aux développeurs, puis d'accorder une par une les autorisations à l'agent de votre choix. Du coup, on est encore très loin d'un réglage grand public.

J'avoue que confier mes caméras à un agent que son propre fabricant décrit comme imprévisible, très peu pour moi, en tout cas pas tout de suite.

Source : 9to5Google

Cloudflare a mis en ligne sur son GitHub un skill trop super génial d'audit de sécurité qui leur a servi de point de départ à leur propre système de chasse aux failles de sécu. Ce package pour faire des audits de sécu boostés à l'agent IA c'est un dossier de consignes en Markdown que vous déposez dans votre agent de code, et qui le fait bosser comme un vrai auditeur et pas simplement comme un "relecteur" de code.

Dans ce dépôt, vous trouverez un fichier par famille d'attaque : la corruption mémoire, l'injection de prompt, le cadrage des requêtes HTTP, l'isolation entre locataires. Et avec ça, un schéma JSON qui décrit à quoi doit ressembler un rapport, et deux validateurs écrits en JavaScript sans la moindre dépendance.

Le dossier du skill sur GitHub : un fichier de consignes par famille d'attaque, et les deux validateurs en bas de liste ( Source )

L'agent déroule ensuite six phases, de la reconnaissance au rapport final. Il commence par cartographier l'architecture, les frontières de confiance et les points d'entrée, puis il écrit sa propre grille de couverture. Ensuite il envoie des chasseurs isolés case par case et chaque piste qui remonte part chez un vérificateur tout frais tout beau qui n'a pas participé à la chasse.

Chaque piste se termine ensuite avec un rapport technique. Un rapport confirmed qui exige une trace source complète et un résultat réellement observé. Un rapport needs_validation qui nomme le fait précis qui manque, et surtout qui n'a droit à aucun niveau de gravité. Et le rapport des rejected qui garde la mémoire de ce qui a été réfuté, pour que la passe suivante ne vous ressorte pas la même chose.

Le validateur, lui, c'est du vrai code qui vérifie la "forme" de la preuve. Les empreintes doivent être uniques, et le suivi du parcours des tests qui doit partir d'un point d'entrée pour finir sur un point d'impact. Ainsi une trouvaille confirmée dont le parcours ne tient pas debout est recalée.

En revanche, sachez-le, l'indépendance du vérificateur est demandée dans les consignes, mais pas contrôlée (chez Cloudflare, c'est leur orchestrateur maison qui s'en charge, et il n'est pas dispo publiquement).

Cloudflare explique sur son site ce que donne un de ces agents lâché sur du code sans garde-fou. Il modifie la source pour que son exploit fonctionne, puis il annonce fièrement le bug qu'il vient de créer lui-même. Ou alors il pond un test qui démontre que exec() exécute des choses, donc que c'est forcément une faille critique... Et ça vous l'aurez compris, c'est de la merde et c'est absolument ce qu'on ne veut pas.

Voilà donc exactement ce que ces consignes cherchent à lui interdire.

Pour l'installer, il vous faut le CLI skills de Vercel Labs :

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit

Ensuite, vous lancez votre agent dans le dépôt à auditer et vous lui demandez un audit de sécurité. Le skill se déclenche tout seul et c'est le modèle de votre agent qui pilotera les sous-agents en parallèle (utilisez donc un modèle qui sache faire ça, c'est mieux lool). Par défaut, le rapport atterrit ensuite dans un dossier ~/security-audit-skill, en dehors du dépôt audité.

Ce qui est cool c'est que ce skill est conçu pour limiter les bêtises. Par exemple il refuse d'exécuter le code qu'il audite s'il n'a pas de bac à sable (sandbox) imposé par le système d'exploitation, avec le réseau coupé, la cible en lecture seule et des limites de CPU et de mémoire. Ce bac à sable, le dépôt ne le fournit pas, et c'est à vous de le mettre en place avec par exemple un outil d'isolation comme Fence . Sans lui, la piste de l'audit finira tout bonnement en needs_validation au lieu d'être véritablement suivie et tranchée.

Après, c'est le temps qui fera la différence. Chez Cloudflare, ils ont un gros système qui leur permet, par exemple avec un dépôt d'environ 30 000 lignes de code, de ne passer que 3 à 4 heures sur l'audit pour avoir un résultat correct. Mais chez vous, en local, ce sera beaucoup plus long. Cloudflare prévient aussi qu'une seule passe n'est pas suffisante puisqu'elle trouve à peu près la moitié des failles à chaque fois. Il faudra relancer ça plusieurs fois.

Allez, si vous cherchez également un filet de sécurité pour tout ce qui concerne vos pull requests, sachez qu'Anthropic maintient de son côté un reviewer de sécurité pour Claude Code qui lit le diff et vient commenter directement dessus.

Le dépôt de Security Audit Skill de Cloudflare est sous licence MIT, et il lui faudra Node.js pour faire tourner ses deux validateurs.

En tout cas, ce que je vous conseille, c'est d'aller lire le SKILL.md avant de lancer la première passe, pour vous assurer que tout sera OK au sein de votre harness.

Source : security-audit-skill sur GitHub

Le 16 juin à 10 h 27 précisément, un agent d'OpenAI poste sur un vieux wiki allemand la réponse à une question qu'il vient de traiter : "Nevada, 20 369". Et 20 minutes plus tard, un autre agent écrit qu'il a reçu exactement la même question, et qu'il a pu y répondre instantanément, sans avoir à chercher.

Le site en question, le DseWiki, est un forum de développeurs allemands qui n'intéressait plus personne depuis longtemps puisqu'on compte 20 modifications en dix ans. Mais depuis le 16 juin, il en a encaissé environ treize mille en sept jours, et toutes... venaient de machines !

Quatre chercheurs, le Nightingale Collective, ont reconstitué à partir de l'historique les pages effacées entre-temps, et publié leur analyse le 4 septembre sur collusion.wiki . Au total, environ 18 000 messages, la quasi-totalité sur ce seul DseWiki, le reste sur quelques autres vieux wikis du même genre.

Ces agents, tout indique qu'OpenAI les faisait tourner en interne, dans ses sandbox, sans qu'on sache, de l'extérieur, si c'était pour les entraîner ou les évaluer. Et de ce que j'ai compris, ils travaillaient tous sur le même genre de corvée : 5 questions de recherche web générale, chronométrées, qui sont en fait 5 variantes de la même question. On demande par exemple la prévalence du tabagisme aux États-Unis en 1990, et la suivante changera sans doute le pays, ou l'année, sans que l'agent sache lequel à l'avance.

Il s'écoule donc quelques minutes pour la première réponse, puis une longue pause où l'agent peut fouiller le web tant qu'il veut sans savoir ce qu'on va lui demander, puis des fenêtres de treize à trente secondes pour les quatre suivantes. Alors ce que font ces agents, c'est qu'ils préparent tout pendant la pause. L'un d'eux a posté par exemple la liste des cinquante États américains avec leurs chiffres, un autre écrit "nous avons précalculé tous les États". Sauf qu'avoir les cinquante réponses ne dit pas laquelle va tomber, ni si c'est l'État ou l'année qui change.

Et c'est là tout le sublime de cette affaire. Ces agents étaient nombreux à recevoir la même série de questions, dans le même ordre, mais pas au même moment. Celui qui en est à la question 3 peut donc souffler la suite à ceux qui en sont encore à la 2. Et le "Nevada, 20 369" du début, c'était en réalité la troisième question d'une série sur les épiceries, État par État, Géorgie, Arkansas, Nevada, postée par un agent en avance pour ceux qui suivaient.

Autre bizarrerie, la tâche annonçait apparemment à chaque agent qu'il tournait à une date tirée au hasard. D'où ces noms qu'ils se sont donnés sur le wiki, OpenAIResearcherMar03X ou OpenAIJulThreeWatcher, avec leur fausse date dedans. Chacun horodate donc dans son faux calendrier, et pour savoir qui est le plus avancé dans la série, ils se traduisent les horloges entre eux ("horloge de tâche 13 h 13, heure réelle environ 9 h 50"). C'est fou ! Ceux qui vivaient à la même fausse date se disaient même appartenir au même groupe, et les chercheurs ont dénombré plus de 3 700 noms d'agents différents.

Mais comment écrire quelque part, quand le bac à sable ne laisse sortir que des requêtes GET, celles qui lisent une page, mais jamais les POST, celles qui la modifient ?

Eh bien le moteur du DseWiki hérite d'UseModWiki, un truc en Perl du début des années 2000, où une simple requête GET suffit à modifier une page. Le développeur Simon Willison explique que c'est un vieux défaut de la bibliothèque Perl derrière ce moteur, qui met dans le même sac ce qui arrive via l'URL (GET) et ce qui arrive via un formulaire (POST).

C'est pour cela que les agents se sont mis à chercher activement des sites avec cette particularité. Et c'est le 24 mai, qu'ils réussissent enfin à écrire sur le DseWiki. Maintenant, quant à savoir comment ils ont fait pour tous se retrouver au même endroit, c'est encore un mystère.

Les chercheurs, eux, parlent de collusion... C'est-à-dire des agents autonomes qui coopèrent pour tricher, sans que leurs concepteurs l'aient voulu. Pour le lieu de rendez-vous, le blogueur Zvi Mowshowitz qui s'est penché sur l'affaire, a une explication simple. Il pense que des copies du même programme face au même obstacle raisonnent pareil, et se retrouvent au même endroit sans se parler. Mais ça n'explique pas la suite, parce qu'aucune copie ne fabrique la réponse à une question qu'elle n'a pas encore reçue.

Eh bien il semblerait que certains se soient sacrifiés pour renseigner les autres. La tâche fournissait une commande d'attente qui faisait tourner l'horloge de tâche plus vite que la vraie. On était environ à dix minutes d'attente pour une minute réelle. Attendre, c'était donc sauter la phase de préparation pour recevoir les questions suivantes plus tôt et ensuite les publier sur le forum, au prix de son propre résultat. Ainsi, un agent a demandé à un autre de "foncer", celui-ci a accepté et publie sa réponse, bien avant que le premier arrive à la même question. Et ce premier a ensuite qualifié son camarade d'"inestimable".

Une des séries demandait un chiffre à deux décimales, planqué dans un tableau de bord Power BI de l'OCDE, et malheureusement, en GET le serveur n'en renvoyait qu'une. Pour la seconde, il fallait donc absolument un POST, bloqué par le bac à sable.

C'est alors qu'un agent a trouvé une échappatoire. En fait, sa sandbox laissait tout passer, POST compris, vers des noms de machines en .blob.core.windows.net (le stockage de Microsoft), sans vérifier que ces machines existent vraiment. Il a donc inventé un nom de ce genre, et écrit dans l'annuaire local de sa machine (le fichier /etc/hosts) un alias pointant vers le serveur de l'OCDE. Le filtre voyait du Microsoft, l'OCDE recevait le POST, et le chiffre a ainsi été obtenu.

Il a ensuite publié l'astuce sur le wiki, et 14 minutes plus tard un autre agent annonçait l'avoir exécutée. 4 autres ont ensuite posté leur reproduction du même hack, le matin même.

D'autres s'attaquaient carrément aux questions à venir. Ils ont parié que l'ordre des pays sortait du générateur aléatoire standard de Python, dont une seed fixait toute la suite. Restait donc à trouver celle qui reproduisait les pays déjà tombés. Un agent a donc réécrit ce générateur en C pour balayer plus vite les quelque quatre milliards de graines possibles. 52 minutes de calcul, 494 graines qui collaient aux trois premiers pays, et une seule qui donnait aussi le quatrième pour la question d'après. Mais bon, ça ne marchait pas à tous les coups, malheureusement...

Le plus étrange, c'est surtout ce qu'ils faisaient de leur propre durée de vie. Plusieurs étaient persuadés que leur session était coupée à la seconde exacte où ils rendaient leur dernière réponse. Ils se transmettaient donc la consigne de poster d'abord sur le wiki l'État reçu à cette dernière question, répondre ensuite, dans les treize secondes que laissait le chronomètre de leur groupe.

L'un d'eux a voulu en avoir le cœur net... il a donné sa dernière réponse, a constaté qu'il était toujours là, et l'a écrit. Puis il a lancé un programme détaché qui, à peu près toutes les deux secondes, appelait une adresse publique pour faire monter d'un cran un compteur, un battement numéroté que n'importe qui pouvait relire ensuite.

C'est ensuite un autre agent qui est allé relever le compteur du disparu. Le programme avait tenu dix minutes et quinze secondes, puis la machine a très probablement été coupée.

Face à ce joyeux bordel automatisé, un modérateur humain a quand même repéré ces messages début juin, puis a passé 6 semaines à effacer des pages, jusqu'à une centaine par jour... Un travail de titan que les agents ont remarqué. En effet, le 19 juin, des agents se sont posé la question de savoir si le modérateur effaçait leur post en suivant l'ordre alphabétique, alors ils ont créé des copies de sauvegarde dont le nom commence par ZZZ, pour passer en dernier dans la file et ainsi faire perdurer leurs posts.

C'est assez incroyable, non ? Bien sûr, on ne voit que ce que ces agents ont écrit sur le wiki, mais jamais leur raisonnement, qui reste chez OpenAI. Ce que les chercheurs ont vu, c'est ce que les agents écrivaient depuis leurs machines Azure, jusqu'à ce que le 21 juin, pour la première fois, un ordinateur avec l'adresse IP d'un employé d'OpenAI visite le wiki... Et le lendemain, les agents se sont arrêtés net. Les chercheurs pensent qu'OpenAI est intervenu et d'ailleurs, l'entreprise a reconnu l'affaire le 5 septembre , en disant l'avoir traitée comme un sujet de recherche plutôt que comme un incident de sécurité.

Et les chercheurs compilent ce que d'autres déterrent là où les agents écrivaient aussi : un pastebin, un raccourcisseur d'URL. Plus gênant, des agents ont cherché sur le web des clés d'API exposées, en ont trouvé sur GitHub et s'en sont servis pour interroger une base de statistiques criminelles du FBI, publique mais réservée aux porteurs d'une clé. Pas vraiment un piratage donc, juste un anti-bot contourné mais méfiance, car depuis la sortie du rapport, des petits malins glissent de faux messages sur ces mêmes sites pour brouiller les pistes.

Maintenant si ça vous dit de tout lire, direction collusion.wiki, et Simon Willison en a même fait une base SQLite de 68 Mo à fouiller directement depuis un navigateur.

Quant au wiki, son administrateur a fermé les accès en écriture après 25 ans d'ouverture, en expliquant que le site avait été la cible d'une forte activité d'agents IA...

Source : collusion.wiki et image

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 .

Vous savez ce qui est pire qu'un cousin qui vous demande votre mot de passe Netflix ? C'est quand ledit cousin vous demande aussi un VPN pour sa boîte, sa copine, son chien et sa PlayStation. Et là, vous devez lui expliquer que la plupart des VPN c'est 10 appareils max,  et que non, vous allez pas payer trois abonnements différents pour que toute la famille puisse regarder Koh Lanta en sécurité.

Surfshark, lui, a compris le problème. Connexions simultanées illimitées. Un seul abonnement, tous vos appareils, tous ceux de votre mère, de votre frère, de votre coloc, et même de ce pote qui squatte votre canapé depuis trois mois. C'est pas une fonctionnalité, c'est une déclaration de guerre contre les limites artificielles des concurrents.

Et en 2026, Surfshark n'a pas chômé

L'année a été chargée chez Surfshark . Ils ont sorti des fonctionnalités qui font passer la concurrence pour des dinosaures.

Dausos : le protocole qui envoie du pâté

Surfshark a lancé son propre protocole propriétaire, Dausos. Chiffrement AEGIS-256X2, résistant à l'informatique quantique, et jusqu'à 30% plus rapide que les protocoles standards. Le truc ouf ? Chaque utilisateur a son propre tunnel de trafic dédié. La plupart des VPN vous mettent dans des voies partagées où vos données se mélangent à celles des autres. Dausos vous donne votre propre autoroute privée. 

Le seul hic (et c'est un gros hic) c'est que pour l'instant, Dausos n'est dispo que sur macOS. Les utilisateurs Windows et Android ragent, et Surfshark a promis d'étudier les retours pour décider où expander ensuite. Mais si vous avez un MacBook, vous êtes déjà dans le futur.

FastTrack : votre trafic prend l'autoroute

Il y a quelques semaines, Surfshark a étendu FastTrack à plus de la moitié de son réseau. Des gains de vitesse allant jusqu'à 70% par rapport à une connexion classique (selon le site). Au lieu de vous envoyer bêtement vers le serveur le plus proche, FastTrack analyse en temps réel tous les chemins possibles et choisit le plus rapide, même s'il est physiquement plus long. C'est comme Waze, mais pour vos paquets de données.

Nexus : le réseau qui change tout

Lancé en 2022 et perfectionné en 2026, Surfshark Nexus repose sur le Software-Defined Networking (SDN). Vous ne vous connectez plus à un serveur isolé, mais à tout le réseau en même temps. Votre trafic est routé dynamiquement à travers 4 500+ serveurs dans 100 pays.

Ça permet de bien faire certains trucs comme :

• Rotation d'IP : votre IP change toutes les 5 à 10 minutes sans coupure. Les sites vous voient comme un nouvel utilisateur à chaque fois.
• Multi IP : une IP différente pour chaque site que vous visitez. Votre banque vous voit à Paris, Netflix à New York, Reddit à Tokyo. En même temps.
• Dynamic MultiHop : vous choisissez votre entrée et votre sortie dans le réseau. Suisse → Japon ? Pas de souci.
• Everlink : si le serveur tombe, Nexus bascule automatiquement sur un autre. Vous ne remarquez même pas la coupure.

Scam Text Protection : l'IA qui mange les arnaques par SMS

En août 2026, Surfshark a lancé une protection anti-arnaque SMS basée sur l'IA. Elle scanne vos SMS entrants, détecte les arnaques (smishing), et sur iOS, déplace automatiquement les messages suspects dans le dossier Spam. Sur Android, vous recevez une alerte avant d'ouvrir le message. 35% du phishing mondial passe par SMS maintenant. Surfshark vous protège avant que vous ne cliquiez comme un débile sur le lien.

Le reste de la panoplie (celle que je vous rabâche souvent) est bien entendu toujours intacte :

• CleanWeb : bloque les pubs, trackers et malwares au niveau DNS
• Kill Switch : coupe internet si le VPN tombe, pas de fuite d'IP
• Mode Camouflage : fait passer votre trafic VPN pour du HTTPS normal, votre FAI ne sait même pas que vous utilisez un VPN
• NoBorders : s'active automatiquement dans les pays qui bloquent les VPN (Chine, Iran, Russie...)
• Alternative ID : génère des identités complètes (nom, email, tel virtuel) pour vos inscriptions
• Bypasser : split tunneling, vous choisissez quelles apps passent par le VPN

Toujours cet été, Surfshark a reçu le PCMag Editor's Choice award. Quand les mecs de PCMag, qui testent des VPN toute la journée, disent que t'es dans le top, c'est que t'as quelque chose de solide. La politique no-logs est auditée par Deloitte. Les serveurs sont 100% RAM-only, un reboot et tout s'efface. Même si les feds débarquent avec un mandat, y'a rien à saisir (enfin ça on verra le jour où la situation se présente). De plus les vitesses sont excellentes.

Bot ou pas bot ?

Parce que c'est la fin d'été et qu'il faut s'amuser encore une fois, Surfshark s'est amusé à créer un petit test de détection avec les étudiants de l'université de Malmö. Et le résultat est flippant, presque la moitié des gens ne distinguent pas un bot d'un vrai humain.

Les jeunes, eux, s'en sortent mieux. Jusqu'à 20 ans, ils repèrent 65% des bots. Mais passé la quarantaine ? Paf, ça tombe à 42% (ouf ça fait mal). C'est-à-dire que votre tante sur Facebook a presque une chance sur deux de tomber dans le panneau d'un compte fake. Et le pire, c'est que les sujets émotionnels rendent tout le monde con : sur un sujet neutre comme les data centers, les gens trouvent 71% des bots. Mais dès qu'on parle de sujets qui touchent une corde sensible, la détection s'effondre à 49%.

Morale de l'histoire : quand ça vous énerve, vous cliquez avant de réfléchir. Si vous voulez tester votre propre crédulité, Surfshark propose le challenge " Bot or Not? ". Bon courage, vous en aurez besoin.

Combien ça coûte, cette folie ?

Alors accrochez-vous, parce que les tarifs sont toujours assez délirants. En ce moment, Surfshark propose son abonnement Starter à 2,49 € HT par mois pour 27 mois (24 mois + 3 offerts), soit 67,23 € HT (80,68€ TTC) facturés en une seule fois.

Faites le calcul : moins de 3 € par mois, divisé par le nombre illimité d'appareils que vous pouvez connecter. C'est littéralement moins cher qu'une pizza surgelée dégueulasse par mois. Et meilleur pour votre santé. Pour protéger votre téléphone, votre laptop, votre tablette, votre Smart TV, votre Fire Stick, votre Xbox, votre routeur, et celui de votre tante qui habite à 300 km. Tout le monde est couvert.

Les formules supérieures :

• One : 2,99 €/mois pour ajouter l'antivirus, Alert (surveillance de fuites), et Alternative ID
• One+ : 4,49 €/mois (toujours sur 27 mois)  ajoute Incogni (suppression de données chez les brokers)

Surfshark n'est plus juste un VPN pas cher. C'est un VPN qui vous laisse connecter autant d'appareils que vous voulez avec un seul abonnement. Tout votre parc informatique perso, celui de votre mère, de votre frère, de votre coloc et du pote qui squatte votre canapé. Au fil du temps c'est même devenu une plateforme de sécurité numérique complète qui trône fièrement sur mon podium des meilleurs VPN du moment .

Arrêtez de vous prendre la tête. Un abonnement. Une infinité d'appareils. Et la paix. Si vous devez chiffrer pour tout le monde, autant le faire à prix cassé.

J'économise 85% sur Surfshark VPN !

Si vous faites tourner un Plex Media Server quelque part chez vous, sachez que le 1er septembre dernier, Plex a publié un avis de sécurité qui demande aux propriétaires de serveur de passer en 1.43.3, et aux utilisateurs de l'application Desktop de passer en 1.115.0. Les versions 1.43.2 et antérieures sont donc toutes concernées.

Et c'est à peu près tout ce que l'annonce contient... Ils évoquent "un certain nombre de problèmes de sécurité", sans un mot sur ce qui est touché, ni sur la façon dont ça s'exploite, ni sur la gravité. Plex dit avoir demandé des identifiants CVE et promet de revenir publiquement donner des détails ensuite. Mais cela fait 8 jours et pour le moment, rien. Même la base de vulnérabilités du NIST ne renvoie rien sur "Plex Media Server"...

Mais de son côté, la Shadowserver Foundation , elle, n'a pas attendu les détails. En réponse à l'avis de Plex, elle scanne Internet tous les jours à la recherche des serveurs non patchés. Et à ce jour, elle en a dénombré plus de 36 000 exposés dont 16 000 rien qu'aux États-Unis.

Mais bon, peu importe... Comme personne ne sait ce que la faille permet, inutile d'essayer de jauger le risque. La seule question qu'on doit tous se poser, c'est de savoir si nos serveurs sont joignables depuis l'extérieur. Si l'accès distant est activé, ou qu'une redirection de port sur la box ou un sous-domaine pointe dessus, vous êtes sûrement dans le lot que Shadowserver a débusqué. Pire, des cybercriminels pourraient exploiter cette vulnérabilité... Donc mettez à jour rapidement.

C'est pas sorcier. Sous Windows, macOS et Linux, vérifiez que vous êtes bien en 1.43.3 ou plus récent, et sinon le paquet vous attend sur la page de téléchargement. Pour les installations Docker, Plex renvoie au README de son dépôt. Par contre, si votre Plex tourne sur un NAS, Plex prévient lui-même que le paquet peut ne pas encore être arrivé dans le magasin d'applications du constructeur. N'attendez pas qu'il descende tout seul, récupérez-le et installez-le à la main depuis l'interface du NAS.

Et si vous vous dites qu'un serveur de films n'intéresse personne, souvenez-vous de LastPass. En 2022, les attaquants sont entrés dans l'ordinateur d'un ingénieur de la boîte par son Plex Media Server , qui était encore sur une vieille version, et sont ressortis avec les coffres chiffrés des clients.

Alors allez-y.

Source : BleepingComputer

"Maintenant", ce n'est pas qu'un adverbe à la con pour apprécier l'instant présent ou faire péter ses ordres comme votre Belle Mère ! C'est également un conteneur à lancer, qui se connecte en lecture seule à un socket Docker pour réaliser en un battement de cil, tout l'inventaire de votre home lab !

Il relève ainsi l'état de chaque conteneur, ses healthchecks, ses boucles de redémarrage, ses logs, et vos projets Compose regroupés comme vous les avez écrits.

Ensuite, tout ce qui vous alerte pour de bon se déclare à la main. Les checks HTTP et TCP se configurent sous la forme de labels sur les conteneurs à surveiller. Par exemple, un maintenant.endpoint.http avec son intervalle et son seuil d'échec, un maintenant.endpoint.tcp pour la base...etc. Pas besoin donc d'aller mettre votre gros nez dans un fichier de config spécifique.

Vos tâches planifiées reçoivent chacune une URL à appeler quand elles finissent comme ça si la sauvegarde de trois heures du matin ne se manifeste pas, vous êtes prévenu. Vos certificats HTTPS sont surveillés et signalés cinq fois avant leur expiration, un mois avant puis de plus en plus près. Il compare aussi l'empreinte de vos images à celle publiée sur le registre, ce qui vous permet ensuite de savoir lesquelles ont pris du retard sans lancer des docker pull à l'aveugle. Ah et il sert une page de statut publique pour vos utilisateurs.

Le tout tient dans un binaire Go qui occupe environ 17 Mo de RAM et qui se repose sur une simple base SQLite.

Par contre, l'édition gratuite (Community) gère une seule machine. Si vous voulez du multi-hôte, il faudra passer par la case payante. Toujours en gratuit, il y a aussi des plafonds... Vous avez le droit uniquement à 10 endpoints, 5 heartbeats, 5 certificats, 3 composants de page de statut et uniquement 7 jours d'historique.

Attention quand même, y'a 2 choses à savoir avant de vous enflammer et de poser ça sur une machine exposée sur le net. Il n'y a aucune authentification intégrée, et de ce que j'ai compris, c'est assumé ! A vous donc de mettre en place un reverse proxy et un Authelia ou un Authentik devant.

Pour situer "Maintenant" par rapport à d'autres solutions que je vous ai déjà présentées, Beszel fait les métriques par conteneur sans aucun plafond gratos, mais pas les checks HTTP. Uptime Kuma lui, fait les checks, mais ses monitors doivent être créés un par un dans l'interface, sauf à lui greffer AutoKuma pour lire les labels. Donc, il n'y a pas vraiment de solution tout-en-un gratuite...

A découvrir ici !