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 .