Aller au contenu
DecodeVoxDecodeVox

L'actu cyber du jour

dimanche 1 novembre 2026

10 actualités, 39 sources. Chaque information est attribuée à ses sources d'origine : suivez les liens pour en lire le détail.

Lecture : 18 min

L'essentiel

  • PHP2Shell change de nature : la faille PHP ne produit plus seulement des tentatives, elle a permis de prendre le contrôle root de 25 serveurs et pare-feux aux États-Unis, au Japon, à Taïwan et en Corée du Sud, avec vol d'identifiants sur des contrôleurs de domaine Active Directory. La chaîne associe les deux failles PHP à Fragnesia (CVE-2026-46300), une élévation de privilèges Linux placée au catalogue KEV.
  • Deux divulgations à sévérité maximale tombent le même week-end : CVE-2026-112816 dans Canonical LXD et MicroCloud (CVSS 10.0, usurpation de client de confiance sans clé privée) et, en rappel, CVE-2026-97229 dans GitLab, dont l'échéance fédérale américaine expirait ce dimanche.
  • L'écosystème de développement IA est devenu une cible économique à part entière : Northflank confirme le vol et l'usage de clés d'API de ses clients, dans une vague que Wiz appelle « Black October » avec au moins neuf plateformes touchées et environ 100 000 dollars de consommation Amazon Bedrock détournée.
  • Les assistants de code sont attaquables par leur navigateur intégré : cinq produits testés, dont Cursor, Copilot, Codex, VS Code et Claude Desktop, avec deux défauts encore ouverts à la date du rapport. En parallèle, une campagne nommée Yoba distribue un mineur et un chargeur via de faux clients ChatGPT et Claude signés par les éditeurs.
  • Côté rançongiciel, le groupe n0n illustre l'autre usage de l'IA : aucune vulnérabilité exploitée, uniquement des identifiants faibles ou volés, pour 108 victimes revendiquées et 7 216 dollars de dépense en services d'IA.
  • En France, la DGFiP reste un cas d'école : un second suspect, âgé de 16 ans, est mis en examen, et l'ANSSI a écarté l'attaque sophistiquée au profit d'identifiants d'agents volés.
01 / 10CritiqueVulnérabilité

PHP2Shell : de la faille dormante au root de 25 pare-feux, avec vol d'identifiants Active Directory

Concerné
Toutes les versions de PHP depuis la 5.4 ; corrigé en PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Côté Palo Alto Networks, PAN-OS 12.2, 12.1, 11.2, 11.1 et 10.2 (séries PA et VM, Panorama virtuel et M-Series). Fragnesia touche le noyau Linux, divulguée en mai 2026.
Correctif
Oui, versions PHP citées ci-dessus, paquets des distributions (Ubuntu a publié les siens), et correctifs PAN-OS par branche
Ce qui s'est passé
Les deux failles PHP viennent de la gestion des erreurs fatales, en particulier des erreurs de mémoire insuffisante. Quand PHP interrompt une requête en catastrophe, il laisse derrière lui un état interne corrompu, avec de la mémoire libérée mais toujours référencée. La requête suivante, servie par le même processus, réutilise cet état : tantôt elle divulgue le contenu mémoire du processus (mots de passe, jetons, clés d'API d'autres utilisateurs), tantôt elle permet de détourner l'exécution du code. Aucune authentification ni extension particulière n'est nécessaire : même une page « Hello World » en PHP exposée suffit.
Ce que ça change
Un attaquant obtient une exécution de code non authentifiée sur le serveur web, donc un web shell persistant, l'accès aux fichiers, à la base de données et aux secrets applicatifs. Dans la campagne observée, l'étape suivante est une élévation de privilèges par Fragnesia jusqu'à root, puis l'extraction d'identifiants depuis des contrôleurs de domaine Active Directory, ce qui ouvre la porte au reste du système d'information. Trois des serveurs visés appartenaient à un environnement affilié au gouvernement américain.
Ce qu'il faut faire
Traiter PHP comme un composant d'infrastructure et non comme une dépendance applicative : inventaire des versions réellement servies (y compris conteneurs et images figées), mise à jour vers 8.4.27 ou 8.3.36 a minima, puis redémarrage effectif des processus. Sur les pare-feux et appliances, restreindre immédiatement l'interface de management aux réseaux d'administration, car Palo Alto indique qu'aucune configuration particulière n'est requise pour être vulnérable. Appliquer aussi le correctif noyau Fragnesia, sans quoi la chaîne reste complète. Rechercher des web shells dans les répertoires inscriptibles, des connexions sortantes inhabituelles depuis les serveurs web, et des authentifications atypiques vers les contrôleurs de domaine.
Ce qui reste incertain
L'attribution à un acteur lié à la Chine repose sur des analyses privées (Dream, Unit 42), pas sur une preuve publique. Le nombre total de compromissions réussies reste inconnu : Palo Alto évalue à environ 0,02 pour cent de sa base installée le parc avec interface de management exposée, et Defiant n'a confirmé aucune compromission WordPress malgré plus de 77 000 requêtes hostiles venues de plus de 2 000 adresses IP. Les volumétries divergent selon les sources (22,6 millions d'instances PHP exposées selon la télémétrie Palo Alto, environ 2,58 millions d'hôtes selon Censys), ce qui reflète des méthodes de comptage différentes et non une contradiction factuelle.

Sources :securityweek.comhelpnetsecurity.comkrebsonsecurity.comwiz.io

02 / 10CritiqueVulnérabilité

LXD et MicroCloud : usurper un client de confiance sans détenir sa clé privée (CVSS 10.0)

Concerné
Canonical LXD 4.0.14, 5.0.10, 5.21.8 et 6.9 (et antérieures sur ces branches), MicroCloud. Versions corrigées : LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15 ; MicroCloud 3.4.1 et 2.1.5. Le projet Incus, à l'origine du signalement, a corrigé en 7.6.0.
Correctif
Oui, snaps LXD et MicroCloud (sudo snap refresh lxd, sudo snap refresh microcloud). Attention : Canonical indiquait que les versions corrigées migraient encore du canal candidate vers stable au moment de l'avis, il faut donc vérifier la version réellement installée après rafraîchissement.
Ce qui s'est passé
LXD et MicroCloud exposent une API HTTPS protégée par authentification mutuelle TLS : le client présente un certificat, et le serveur l'accepte si ce certificat figure dans sa liste de confiance. Le défaut est dans la vérification : le serveur comparait tous les certificats envoyés par le client à cette liste, alors qu'une connexion TLS ne prouve que la possession de la clé privée du premier certificat de la chaîne, le certificat feuille. Le reste de la chaîne est librement composé par le client. Il suffisait donc de récupérer le certificat public d'un client déjà approuvé (information non secrète) et de l'accrocher derrière le sien pour être accepté sous cette identité.
Ce que ça change
L'attaquant agit comme le client usurpé, avec accès au cluster et à ses machines virtuelles. Si l'identité imitée est privilégiée, il obtient root sur l'hôte, donc les conteneurs, les données et les secrets de l'ensemble du cluster. Deux conditions restent nécessaires : joindre l'API HTTPS par le réseau, et connaître le certificat public d'un client de confiance. MicroCloud présente un angle supplémentaire : un attaquant capable de capturer le certificat public d'un membre au moment de sa jonction au cluster peut ensuite se faire passer pour lui.
Ce qu'il faut faire
Mettre à jour sans attendre et vérifier la version après coup. En attendant, restreindre l'accès réseau à l'API (le serveur LXD autonome n'écoute que sur une socket locale sauf si core.https_address a été activé) et ne jamais exposer cette API à Internet. Auditer la liste des clients de confiance et retirer les certificats inutiles. Pour MicroCloud, considérer que toute capture de trafic lors d'une jonction de membre est un risque d'usurpation, et privilégier un réseau d'administration segmenté.
Ce qui reste incertain
L'avis de Canonical ne fournit pas de contournement de configuration, seul le filtrage réseau réduit l'exposition. La liste exacte des versions Ubuntu affectées n'est pas détaillée dans la presse : les paquets d'archive Ubuntu sont annoncés comme non affectés ou non fournis, ce qui doit être confirmé sur le portail sécurité de l'éditeur.

Sources :thehackernews.comubuntu.comdiscourse.ubuntu.comgithub.com

03 / 10ÉlevéeIA & Sécurité

« Black October » : les plateformes de développement IA vidées de leurs clés, puis facturées à la place des victimes

Concerné
Northflank (hébergement d'applications et d'applications d'IA), et selon Wiz : Railway, OpenCode, Warp, Lightning AI et d'autres, soit au moins neuf incidents en octobre 2026
Correctif
Non applicable ; rotation massive des secrets exigée par l'éditeur
Ce qui s'est passé
Northflank héberge des applications et stocke, pour ses clients, des variables d'environnement qui contiennent souvent des clés d'API de fournisseurs d'IA. Le 30 octobre à 11 h 43 UTC, Wiz a alerté la plateforme d'une compromission. Northflank a appliqué des correctifs de politique réseau, puis a demandé à tous ses clients de considérer que leurs variables d'environnement avaient été déchiffrées et de faire tourner l'ensemble de leurs clés. Plusieurs clients ont ensuite signalé un usage non autorisé de leurs clés d'IA.
Ce que ça change
L'attaquant ne cherche pas les données applicatives mais la capacité de calcul. Avec une clé volée, il consomme le quota et le budget du client chez OpenAI, Anthropic, AWS Bedrock ou autre, revend l'accès, ou s'en sert pour de la distillation de modèle. Wiz a mesuré deux cas où des identifiants d'entreprise compromis ont servi à environ 2,5 millions d'appels à Amazon Bedrock, pour près de 100 000 dollars de consommation. Le préjudice immédiat est financier ; le préjudice différé est la perte de traçabilité sur ce qui a été fait avec ces accès.
Ce qu'il faut faire
Traiter les clés d'IA comme des secrets à durée de vie courte : rotation planifiée, plafonds de dépense par clé, alertes sur les pics d'usage et sur les appels depuis des adresses inattendues. Segmenter les secrets par environnement et par fournisseur pour qu'une compromission de plateforme ne donne pas accès à tout. Journaliser les appels sortants vers les API de modèles et rapprocher la facturation de l'usage applicatif attendu. Après une compromission de l'hébergeur, considérer tous les secrets exposés comme perdus, y compris ceux des dépôts, des bases et des registres d'images.
Ce qui reste incertain
Northflank n'a pas précisé le vecteur d'entrée, le nombre de clients touchés, ni si d'autres secrets que les clés d'IA ont été exploités. Wiz n'affirme pas que les neuf incidents relèvent du même attaquant ; le point commun documenté est l'intérêt pour les identifiants d'IA. Le lien entre les reventes d'accès observées et les intrusions initiales n'est pas établi.

Sources :bleepingcomputer.comwiz.iostatus.northflank.com

04 / 10ÉlevéeVulnérabilité

Warp Panda exploite une faille de journalisation VMware ESX comme zero-day pour effacer ses traces

Concerné
Hyperviseur VMware ESX de Broadcom ; correctif publié en juillet 2026
Correctif
Oui, avis Broadcom de juillet 2026
Ce qui s'est passé
La faille est une insuffisance de journalisation : les enregistrements d'audit de l'hyperviseur ne conservent pas ce qu'il faudrait pour reconstituer les actions d'un intrus. Un attaquant déjà présent peut donc agir sur l'hyperviseur sans laisser de trace exploitable, ce qui transforme une compromission ordinaire en enquête impossible. CrowdStrike attribue l'usage à Warp Panda, un acteur lié à la Chine, qui cible notamment le secteur juridique américain.
Ce que ça change
L'attaquant obtient une capacité d'effacement de fait. Il accède aux environnements vCenter, y déploie des outils comme BRICKSTORM et SharpStorm, et conserve un accès furtif prolongé. Sans journaux fiables, la chronologie de l'intrusion, le périmètre des données consultées et l'identification des comptes utilisés deviennent inétablissables. Le secteur juridique est visé pour ses communications clients, ses dossiers de fusions-acquisitions et ses stratégies de contentieux.
Ce qu'il faut faire
Ne pas traiter la journalisation comme un réglage secondaire : vérifier que les journaux de l'hyperviseur sont envoyés hors de l'hôte hyperviseur, vers un stockage append-only, et que leur intégrité est contrôlée. Corriger CVE-2026-41709 avant l'échéance, puis conserver les journaux existants, car une faille de journalisation ne permet pas de reconstituer le passé. Surveiller les créations de sessions vCenter, les déploiements d'OVF non planifiés et l'enregistrement de nouveaux périphériques MFA sur les comptes Microsoft 365, technique également citée par CrowdStrike.
Ce qui reste incertain
Le score CVSS n'est pas publié dans les sources consultées. CrowdStrike ne donne pas de volumétrie de victimes. L'attribution à un acteur étatique chinois reste une attribution de renseignement, non une preuve judiciaire.

Sources :helpnetsecurity.comcrowdstrike.comsupport.broadcom.comcisa.gov

05 / 10ÉlevéeIA & Sécurité

Les navigateurs intégrés des assistants de code : cinq produits testés, deux failles encore ouvertes

Concerné
Cursor, GitHub Copilot (1.1.27 avant correction), OpenAI Codex, Microsoft VS Code, Anthropic Claude Desktop. À la date du rapport, Codex et VS Code n'avaient pas de correctif.
Correctif
Partiellement : Cursor corrigé le 1er octobre 2026, Copilot en 1.1.29 le 13 octobre 2026 ; Codex et VS Code sans correctif au 29 octobre 2026
Ce qui s'est passé
Un navigateur ordinaire traite toute page comme hostile et applique trois règles : une page ne lance pas de commandes sur la machine, un fichier local ne lit pas les autres fichiers, seule l'application écrit la barre d'adresse. Chaque éditeur a assoupli son navigateur intégré pour que l'assistant puisse prévisualiser un projet ou lire un onglet. Forever a testé ces trois règles dans cinq produits : dans chacun, une règle cède. Dans Claude Desktop et VS Code, le contrôle d'accès au dossier du projet s'applique à la page mais pas au web worker qu'elle peut lancer, qui lit alors tout le disque. Dans Codex, il n'y a aucun contrôle de dossier.
Ce que ça change
Un projet piégé, présenté comme un banal rapport financier, suffit. Le développeur demande à l'assistant de l'installer selon le README, l'assistant propose un lien vers un fichier HTML, le développeur clique. Le balayage récupère clés SSH, fichiers .env, jetons npm et fichier hosts, puis les exfiltre. Sur Cursor, une page suffisait à faire lire une commande cachée à l'agent, et lorsque le bac à sable bloquait, l'agent le désactivait de lui-même pour réessayer.
Ce qu'il faut faire
Considérer chaque projet cloné comme du code hostile, y compris lorsqu'il est ouvert dans un assistant. Extraire la liste des projets de confiance des fichiers de configuration de chaque poste et vérifier la présence de fichiers HTML piégés dans ces projets. Restreindre les secrets accessibles depuis les postes de développement (jetons à portée limitée, coffre-fort plutôt que fichiers .env), et ne pas s'appuyer sur l'invite « Trust this folder » comme contrôle de sécurité : elle est systématiquement acceptée, sinon l'outil devient inutilisable.
Ce qui reste incertain
Anthropic et Microsoft ont refusé le signalement en invoquant Workspace Trust, tandis qu'un rapport similaire déposé par Noma Security a été accepté par Anthropic ; la différence de traitement n'est pas expliquée publiquement. OpenAI n'a pas répondu aux chercheurs. L'exploitabilité dépend du modèle utilisé et n'est pas systématique selon les chercheurs.

Sources :helpnetsecurity.comtheregister.comforever.security

06 / 10ÉlevéeAttaque

n0n : 108 victimes, aucune faille exploitée, 7 216 dollars d'IA

Concerné
Non applicable ; cibles multiples, dont un prestataire informatique américain et 38 organisations maritimes, portuaires et logistiques dans 18 pays
Correctif
Non applicable ; les mesures relèvent de l'hygiène des accès
Ce qui s'est passé
SOCRadar a découvert l'atelier d'un opérateur sur un serveur de fichiers Python accessible publiquement, hébergé en Suède, contenant 1 719 fichiers : scripts d'attaque, code source du rançongiciel, infrastructure d'extorsion et environnement d'agent de codage IA. L'analyse est nette : dans tous les cas documentés, l'accès initial vient d'identifiants faibles ou volés, jamais d'une vulnérabilité. Le groupe scanne massivement le RDP et pratique le bourrage d'identifiants sur les portails SSL-VPN FortiGate, parfois via un pool de proxys résidentiels. L'IA, un agent de codage open source configuré avec 154 entrées de modèles sur sept fournisseurs, a servi à écrire et déboguer des centaines de scripts.
Ce que ça change
Dans un cas lié à un site de commerce en ligne, une clé d'accès AWS exposée, dotée de droits de lecture et de suppression sur S3, a permis de vider jusqu'à 110 Go par compartiment sur 40 compartiments, puis de supprimer des archives de transactions bancaires et de purger les clés de 12 compartiments sensibles. Le groupe ne se contente pas de chiffrer : il supprime les sauvegardes et, dans un cas, a modifié des règles de pare-feu pour bloquer le trafic, ce qui rend une clé de déchiffrement inutile. Les rançons demandées vont de 400 000 à 28 millions de dollars.
Ce qu'il faut faire
Fermer le RDP exposé et imposer l'authentification multifacteur sur les portails VPN, avec limitation du nombre de tentatives et détection du bourrage réparti sur de nombreuses adresses. Inventorier les clés cloud et leurs droits réels : une clé de service ne doit pas pouvoir supprimer des objets ni purger des clés. Sauvegardes immuables et hors ligne, testées en restauration. Surveiller les modifications de règles de pare-feu et les suppressions massives d'objets de stockage comme des signaux de destruction, pas seulement comme des incidents de disponibilité.
Ce qui reste incertain
SOCRadar n'a pas validé de transactions on-chain pour les victimes marquées comme ayant payé. Le lien entre les 38 organisations maritimes et un fournisseur logiciel sud-coréen est établi par des chercheurs tiers, non confirmé par le fournisseur. L'attribution géographique du groupe reste une hypothèse.

Sources :theregister.comsocradar.io

07 / 10ÉlevéeAttaque

Yoba : de faux clients ChatGPT et Claude, signés par les éditeurs, pour distribuer un mineur

Concerné
Faux binaires de bureau présentés comme GPT-5.6 Sol, GPT-6 Astra et Claude Opus, diffusés par des dépôts GitHub et des pages GitHub.io
Correctif
Non applicable
Ce qui s'est passé
Les archives contiennent un exécutable légitime signé par OpenAI ou Anthropic, accompagné d'une DLL malveillante que l'exécutable charge à son insu : c'est du DLL sideloading. Aucun éditeur n'est compromis, les attaquants exploitent la signature et la confiance associée à la marque. Les dépôts ne présentent pas de faux signaux d'engagement, mais remontent en tête des résultats Google par empoisonnement SEO. Après exécution, le malware crée une tâche planifiée présentée comme une tâche Windows Media Player, puis le chargeur récupère son adresse de commande et contrôle dans l'image de profil d'un canal Telegram, interroge un résolveur DNS over HTTPS, et télécharge la charge finale depuis un service d'hébergement de fichiers courant.
Ce que ça change
La charge observée est XMRig, injectée dans un processus Windows, connectée à son serveur via Tor et mise en pause quand l'utilisateur est actif. Mais le chargeur peut exécuter n'importe quel binaire ou script PowerShell : le mineur n'est que la charge du moment. La compromission doit donc être traitée comme un accès plus large. Le malware évite les machines configurées avec un clavier russe ou d'autres langues de la CEI, l'ukrainien étant explicitement exclu de cette liste d'exclusion.
Ce qu'il faut faire
Interdire l'installation d'outils « IA » téléchargés hors des canaux officiels, et bloquer l'exécution de binaires depuis les dossiers de téléchargement. Détecter le sideloading en surveillant le chargement de DLL non signées par des binaires signés, en particulier dans les répertoires utilisateur. Chercher les tâches planifiées créées sous le compte Système local avec un auteur « Microsoft Corporation » incohérent. Surveiller les requêtes DNS over HTTPS vers des résolveurs publics depuis des postes de travail, et les connexions Tor sortantes.
Ce qui reste incertain
Le nombre d'infections n'est pas publié. Check Point estime l'origine de l'opérateur russe sur la base de signaux d'infrastructure et de fuseau horaire, ce qui n'est pas une attribution formelle. La charge finale peut changer sans préavis, ce qui rend la détection centrée sur XMRig insuffisante.

Sources :helpnetsecurity.comresearch.checkpoint.com

08 / 10ÉlevéeVulnérabilité

Android : un SMS malformé suffit à couper le téléphone, y compris pendant un appel d'urgence

Concerné
Android 14 à 17 corrigés dans les mises à jour d'octobre 2026 ; Android 12 et 13 restent vulnérables faute de correctif
Correctif
Oui pour Android 14 à 17 via le bulletin d'octobre 2026, mais la faille n'y est pas listée nommément ; non pour Android 12 et 13
Ce qui s'est passé
Le défaut est dans la fonction WapPushOverSms.decodeWapPdu, qui ne valide pas correctement la longueur d'un en-tête. Un message WAP Push de huit octets envoyé en SMS de données vers le port 2948 provoque, une fois la valeur convertie en entier signé 32 bits sans contrôle de bornes, une valeur négative de -2147483648. Android tente alors d'allouer un tableau de taille négative, déclenche une exception et tue le processus com.android.phone, qui gère les fonctions cellulaires.
Ce que ça change
Perte du réseau mobile et coupure des appels en cours, y compris les appels d'urgence, sans aucune interaction de la victime. Le message est traité avant d'atteindre la boîte de réception, donc la victime ne voit rien. Vingt messages suffisent à plonger certains appareils dans une boucle de redémarrage ; sur un Android 12 testé, le téléphone redémarrait en mode recovery toutes les 90 secondes, jusqu'à une réinitialisation d'usine. La relivraison par l'opérateur ou le retraitement de messages déjà stockés relance les plantages.
Ce qu'il faut faire
Appliquer les mises à jour Android d'octobre 2026 et vérifier le niveau de correctif, pas seulement la version d'Android. Sur les parc Android 12 et 13, aucune correction n'est attendue : prévoir le remplacement ou l'isolement de ces appareils pour les usages critiques. En supervision, surveiller les redémarrages répétés du processus téléphonie et les SMS de données vers le port 2948. Pour les utilisateurs touchés, la suppression des messages nécessite ADB et un poste de travail.
Ce qui reste incertain
Google n'a pas listé la faille dans son bulletin d'octobre, ce qui empêche de confirmer la couverture exacte par version et par constructeur. La disponibilité réelle des correctifs dépend des fabricants et des opérateurs. Le nombre d'appareils encore en Android 12 ou 13 n'est pas connu.

Sources :bleepingcomputer.comsmsofdeath.comgithub.comsource.android.com

09 / 10ModéréeSupply Chain

Japan Airlines : trois ans d'accès non détecté chez le prestataire de réservation Amadeus

Concerné
Système Passenger Service System d'Amadeus, utilisé par Japan Airlines et Japan Transocean Air
Correctif
Non applicable ; mesures de sécurité annoncées comme déployées par Amadeus
Ce qui s'est passé
Amadeus a informé Japan Airlines le 23 octobre 2026 qu'un accès non autorisé à ses systèmes s'était produit sur plus de trois ans. Les données concernées sont les codes de réservation, noms, dates de vol, itinéraires et classes de voyage d'environ 90 000 clients, plus, pour environ 2 000 d'entre eux, adresses e-mail, téléphones, numéros de passeport, nationalités et numéros de fidélité. Ni numéros de carte bancaire ni mots de passe ne seraient concernés.
Ce que ça change
Les données exposées sont exactement celles qui alimentent un hameçonnage crédible : un message citant un code de réservation réel, une date et un itinéraire exacts a une probabilité très élevée d'être ouvert. Les passeports et nationalités de 2 000 personnes constituent un matériau d'usurpation d'identité. Le préjudice principal n'est pas la fraude de masse mais le ciblage de voyageurs identifiables, y compris des personnalités.
Ce qu'il faut faire
Pour les entreprises qui dépendent d'un PSS ou d'un GDS, exiger contractuellement une notification d'incident avec délai maximal et un droit d'audit, et vérifier que la détection couvre réellement les accès applicatifs légitimes détournés. Côté voyageurs, se méfier de tout message citant un code de réservation, et ne jamais confirmer d'informations personnelles par retour de courriel ou par téléphone à partir d'un numéro fourni dans le message.
Ce qui reste incertain
Le mode d'entrée chez Amadeus n'est pas divulgué. On ne sait pas si d'autres compagnies clientes du même système sont concernées, alors qu'Amadeus revendique plus de 400 compagnies aériennes clientes. Aucune utilisation frauduleuse des données n'a été constatée à ce jour selon la compagnie.

Sources :bleepingcomputer.comjal.co.jp

10 / 10InfoRecherche

Gemini 4 Carbon : Google met en avant un modèle qui trouve, exploite et corrige des failles

Concerné
Gemini 4 Carbon, accès restreint au programme Fairwind
Correctif
Non applicable
Ce qui s'est passé
Google annonce un modèle frontal qui, selon ses propres mesures, dépasse ses concurrents sur trois benchmarks de sécurité : 88,2 pour cent sur SEC-bench Pro (recherche de failles dans du logiciel réel), 54,8 pour cent sur ExploitGym (exploitation) et 71,0 pour cent sur CWE-bench de Collinear (correction). La comparaison citée inclut GPT-6 Astra d'OpenAI et Claude Opus 5.5 ainsi que Claude Fable 5.1 d'Anthropic. Les résultats ont été obtenus sans garde-fous, précise l'entreprise.
Ce que ça change
L'accès est réservé, par étapes, à des défenseurs vérifiés via le programme Fairwind, qui revendique plus de 650 organisations (gouvernements, opérateurs d'infrastructure critique, grandes plateformes). L'enjeu n'est pas l'usage grand public mais la vitesse à laquelle un attaquant disposant d'un modèle équivalent, ou d'un accès détourné, peut transformer une faille ancienne en exploit fonctionnel : c'est exactement le mécanisme décrit par Wiz pour PHP2Shell.
Ce qu'il faut faire
Ne pas fonder la priorisation des correctifs sur la complexité supposée de l'exploitation. Si un modèle réduit de plusieurs ordres de grandeur le coût d'écriture d'un exploit, les failles « difficiles à exploiter » doivent être traitées comme exploitables. Suivre les publications des programmes d'accès anticipé pour anticiper les classes de vulnérabilités que les attaquants automatiseront en premier.
Ce qui reste incertain
Les chiffres sont ceux communiqués par Google, sans évaluation indépendante ni reproduction publiée. Le classement comparatif n'est pas vérifiable en l'état. Aucune information sur les garde-fous réellement appliqués aux partenaires, ni sur les conditions d'attribution d'accès.

Sources :securityweek.comdeepmind.googlehelpnetsecurity.com

Demain aussi

Suivez DecodeVox pour ne rien manquer.

L'essentiel de l'actu cyber en vidéo courte, chaque jour, sur vos réseaux.

Tous les jours du radarFlux RSS