Cybersécurité, Entreprise, IA, Securite informatique

Emploi cyber aux États-Unis : recul de 26,4 % des offres

Aux États-Unis, les annonces en cybersécurité reculent fortement, tandis que certaines spécialités liées à l’intelligence artificielle progressent. Le rapport CyberSN révèle un marché aux trajectoires divergentes.

Le marché américain du recrutement en cybersécurité atteint son niveau le plus faible en quatre ans sur la période janvier-septembre 2026. L’agence CyberSN recense 235 786 annonces en 2026, contre 320 210 sur les mêmes mois de 2025. Cette contraction de 26,4 % contraste avec une progression spectaculaire des offres destinées aux ingénieurs en sécurité de l’intelligence artificielle et aux spécialistes des données cyber. Les métiers historiques, du test d’intrusion à l’analyse des risques, enregistrent des baisses importantes.

Une contraction qui touche plusieurs métiers essentiels

Derrière le recul général, les écarts entre spécialités dessinent un paysage contrasté. Les annonces concernant les analystes des menaces internes diminuent de 55,6 %, pour atteindre 1 088 publications. Celles destinées aux analystes des risques cyber reculent de 51,5 %, à 4 031 offres. Le test d’intrusion subit également une contraction marquée : 3 063 annonces, soit une baisse de 45,9 %.

Les fonctions de coordination et de pilotage suivent cette tendance. Les offres de responsables opérationnels en cybersécurité diminuent de 41 %, à 4 688 annonces. La chasse aux menaces abandonne 40 %, avec 1 013 publications. Pour les chefs de projet cyber, le recul atteint 39,4 %, à 783 offres.

La direction de la sécurité présente une situation plus nuancée. Le périmètre regroupant les RSSI et plusieurs fonctions apparentées totalise 2 832 annonces, en diminution de 38,9 % sur un an. Pourtant, ce volume reste proche des 2 808 publications enregistrées en 2024. La comparaison annuelle traduit donc aussi le niveau particulièrement élevé atteint en 2025. Autre élément à retenir : ces offres progressent de 19,5 % entre le deuxième et le troisième trimestre 2026.

La sécurité de l’IA progresse dans un marché réduit

Deux spécialités échappent nettement à la tendance générale. Les annonces d’ingénieurs en sécurité de l’intelligence artificielle augmentent de 268,3 % sur un an. Celles visant les scientifiques des données spécialisés en cybersécurité progressent de 203,5 %. Ces évolutions signalent une demande croissante pour ces profils, mais les pourcentages seuls ne permettent pas de comparer leur poids avec celui des métiers davantage représentés.

L’IA occupe aussi une place transversale dans les recrutements. Sur la période étudiée, un peu moins de 15 % des annonces la mentionnent, contre 15,1 % un an auparavant. La moyenne ne traduit donc pas une généralisation soudaine à l’ensemble du secteur. En revanche, la dynamique s’accélère au fil de 2026, jusqu’à atteindre 20 % en septembre.

La recherche concentre la proportion la plus élevée d’annonces faisant référence à ces connaissances : 32,7 %, soit 11,7 points supplémentaires sur un an. Les activités offensives suivent avec 23,3 %, en progression de 4,8 points. La gouvernance, les risques et la conformité atteignent 19,8 %, soit 2,1 points de plus. La planification affiche 18,9 %, avec une hausse de 0,6 point. Ces résultats distinguent deux phénomènes : le développement de postes spécialisés dans la sécurité de l’IA et l’intégration de connaissances sur cette technologie dans d’autres fonctions cyber. Ils ne démontrent pas que l’automatisation provoque le recul des annonces observé ailleurs. Le rapport décrit les variations, sans en établir les causes.

Le télétravail apporte un autre éclairage sur les possibilités proposées. Les fonctions commerciales affichent une proportion de 32,8 %, devant la gouvernance, les risques et la conformité, à 31,2 %. Les activités offensives atteignent 24,7 %, la sécurité des produits 22,9 % et la formation 22,8 %. La recherche et la défense suivent respectivement à 21,9 % et 21,3 %.

Cybersécurité, Entreprise, Justice

Cyberattaque : préparer sa plainte sans perdre de temps

Après une cyberattaque, déposer plainte permet de demander une réponse judiciaire. Préparer les preuves, identifier le bon interlocuteur et documenter l’incident évite de perdre un temps précieux.

Une intrusion informatique ne se résume pas à la remise en service des équipements. L’organisation touchée doit aussi préserver les éléments nécessaires à une enquête et organiser sa démarche de plainte. Qui peut la représenter ? Quels documents transmettre ? Faut-il attendre un rapport technique complet ? Il faut anticiper ces questions, de réunir les premières preuves disponibles et de compléter ensuite le dossier. Elle souligne également les enjeux de reconnaissance du préjudice et d’assurance. Pour les équipes de sécurité comme pour la direction, cette préparation relie la gestion technique de l’incident à ses suites judiciaires, sans attendre de connaître toute l’étendue de l’attaque.

Déposer plainte pour engager la réponse judiciaire

Lorsqu’une entreprise découvre une intrusion, ses premières décisions portent souvent sur les systèmes compromis. Il faut comprendre ce qui s’est produit, contenir l’incident et rétablir les services. La démarche judiciaire doit également trouver sa place dans cette mobilisation. Dans certaines situations, seule la victime connaît les faits. Sans signalement de sa part, les autorités peuvent ignorer l’existence même de l’attaque.

Le dépôt de plainte permet de porter ces faits à leur connaissance et de solliciter une enquête pénale. Celle-ci vise notamment à identifier les responsables et à réunir les éléments permettant leur éventuelle poursuite. La victime n’a donc pas à attendre de connaître l’identité de l’attaquant pour entreprendre sa démarche. L’identification des auteurs constitue précisément l’un des objectifs de l’investigation. En 2025, ZATAZ avait proposé un outil interactif pour préparer une « cyber » plainte.

La plainte contribue aussi à formaliser le préjudice subi. Le document associe cette démarche à la reconnaissance de la qualité de victime, aux possibilités de constitution de partie civile et aux démarches destinées à obtenir réparation. Pour une organisation, l’enjeu dépasse ainsi la seule description d’un dysfonctionnement informatique. Il s’agit de documenter les conséquences d’une action susceptible de relever du pénal.

Les questions d’assurance ajoutent une contrainte de calendrier. DataSecuritybreach.fr vous rappelle le délai de 72 heures après la découverte de l’incident pour le dépôt de plainte lié à l’indemnisation assurantielle, en référence à la loi LOPMI. Ce point doit être traité rapidement avec les interlocuteurs compétents de l’organisation. Attendre une expertise exhaustive avant d’aborder la plainte peut faire perdre un temps déterminant.

La démarche participe enfin à la protection de l’organisation. Elle permet de présenter aux autorités les documents dérobés, les données concernées et les risques identifiés. Le dépôt de plainte ne garantit toutefois ni la récupération des fonds ni l’arrêt de l’exploitation des informations volées. Ces objectifs dépendent des circonstances et des suites données au dossier. A noter que si vous êtes victime d’une fuite de données, le blog zataz propose un guide interactif complet intitulé « Vos données ont fuité. La suite vous appartient.« 

Préparer les preuves et organiser la représentation

Comme l’indique le CLUSIF dans un document diffusé fin octobre, la préparation commence avant l’incident. Identifier un service de police ou de gendarmerie à proximité permet de disposer d’un premier point de contact. Un échange préalable peut faciliter l’orientation vers les interlocuteurs appropriés lorsque survient une attaque. En pleine crise, cette anticipation évite de consacrer les premières heures à rechercher où présenter les faits.

Il faut également savoir qui représentera l’entreprise. Le représentant légal ou une personne disposant d’un pouvoir spécial de représentation. Cette question mérite d’être réglée en amont : la personne qui maîtrise les détails techniques n’est pas nécessairement celle qui dispose du mandat requis. Préparer la délégation utile facilite la démarche lorsque plusieurs équipes interviennent simultanément.

Le dossier initial doit réunir les éléments déjà disponibles. Journaux techniques, captures d’écran, rapports d’analyse et coordonnées des prestataires peuvent aider à comprendre l’incident. Leur utilité tient autant à leur contenu qu’à leur capacité à éclairer les faits présentés. Les équipes doivent pouvoir expliquer ce que chaque pièce montre, sans transformer une hypothèse technique en certitude.

Un dossier encore incomplet ne doit pas devenir un motif d’attente systématique. Le document recommande de présenter une première plainte avec les informations essentielles (le brouillons, daté et indiquant les mises à jour), puis de transmettre des compléments. Cette approche permet d’engager la démarche tandis que l’analyse se poursuit. Une audition ultérieure ou un complément de plainte peut apporter les résultats obtenus après les premières constatations. La volatilité des traces numériques renforce cette nécessité d’agir tôt. Certains éléments utiles peuvent disparaître alors que l’entreprise concentre ses efforts sur le rétablissement de son activité. La conservation des preuves doit donc être intégrée à la réponse à incident, avec les personnes chargées de l’analyse et celles qui préparent le dossier judiciaire.

Enfin, une enquête informatique peut demander du temps. Des auteurs situés à l’étranger, des preuves dispersées et des vérifications successives compliquent les investigations. L’absence de nouvelles immédiates ne permet pas, à elle seule, de conclure à un classement sans suite. La rapidité du signalement et la qualité des pièces transmises restent des contributions concrètes de la victime.

Cybersécurité, Entreprise, Mise à jour, Patch, Securite informatique

Panne Google Cloud : les entreprises face au silence

La panne de Google Cloud du 20 octobre a perturbé de nombreux sites, dont la banque Revolut et relancé une question stratégique : comment poursuivre son activité lorsque les communications habituelles deviennent indisponibles ?

Une application inaccessible, des paiements perturbés, des équipes privées de leurs moyens d’échange : une interruption informatique peut rapidement désorganiser une entreprise. L’incident de Google Cloud du 20 octobre 2026 replace la continuité des communications au cœur du débat. Data Security Breach souligne une dépendance souvent sous-estimée : plusieurs outils peuvent reposer sur une infrastructure commune. Le retour d’expérience transmis par Revolut à ses clients illustre également les conséquences prolongées d’une panne, certaines opérations nécessitant un délai de régularisation après le rétablissement. L’enjeu dépasse donc la disponibilité technique : il concerne la capacité à coordonner, informer et décider.

Plusieurs applications, une même dépendance

Le 20 octobre, plusieurs services de Google Cloud ont rencontré des difficultés dans la région de Londres. La page officielle de suivi mentionne un incident électrique ayant provoqué une interruption dans la zone europe-west2-b. Une défaillance d’infrastructure peut ainsi se répercuter sur les organisations qui utilisent les services concernés.

Revolut figure parmi les entreprises touchées. Dans le message adressé à ses clients, la société attribue explicitement son interruption de service à cette panne de Google Cloud. Elle indique que le problème a été résolu le jour même et affirme que les fonds comme les données sont restés en sécurité pendant toute la perturbation. Le rétablissement technique ne signifie toutefois pas que toutes les conséquences disparaissent immédiatement. Revolut prévient que certaines transactions par carte, remboursements compris, peuvent demander quelques jours avant d’apparaître sur le compte et d’être répercutées dans le solde. L’établissement précise travailler au traitement de ces opérations et renvoie les clients rencontrant encore des difficultés vers l’assistance accessible dans son application.

Ce décalage illustre une distinction essentielle : remettre un service en ligne et retrouver un fonctionnement entièrement normal constituent deux étapes différentes. Entre les deux, les utilisateurs doivent comprendre ce qui fonctionne, ce qui reste en attente et comment obtenir une réponse. DataSecuritybreach.fr Derbes attire précisément l’attention sur cette fragilité organisationnelle. Une entreprise peut disposer d’une téléphonie sur IP, d’une messagerie instantanée, d’une plateforme collaborative et d’un outil de visioconférence sans bénéficier de quatre voies de secours indépendantes. Ces applications peuvent partager un hébergeur, un fournisseur cloud ou certaines infrastructures. Leur nombre ne renseigne donc pas, à lui seul, sur leur capacité à résister à une défaillance commune. La diversification apparente des interfaces peut masquer une concentration des dépendances.

L’enjeu consiste alors à identifier les communications indispensables. Joindre les collaborateurs, transmettre une décision urgente, répondre aux clients et coordonner les interventions ne peuvent dépendre d’un dispositif dont personne n’a vérifié les possibilités de remplacement.

Autre détail, de taille, nous savons maintenant que Révolut sauvegarde les données chez Google Cloud !

Le secours doit fonctionner pendant la panne

L’existence d’une solution alternative ne garantit pas sa disponibilité au moment critique. Elle peut utiliser le réseau déjà interrompu, demander une authentification inaccessible ou présenter des limites de traçabilité incompatibles avec les exigences de l’activité. La question opérationnelle devient très concrète : les personnes chargées de gérer la crise peuvent-elles effectivement se joindre lorsque leurs outils habituels ne répondent plus ? Un dispositif documenté reste insuffisant si son activation dépend précisément du service défaillant.

L’identification des dépendances et l’expérimentation régulière des moyens de remplacement est indispensable. Pendant que les techniciens rétablissent les systèmes, l’organisation doit conserver la possibilité de transmettre des consignes et d’expliquer la situation à ses interlocuteurs.

Les données européennes donnent une autre dimension à cette réflexion. Publié en juin 2026, le premier rapport commun des autorités européennes de supervision sur les incidents majeurs déclarés dans le cadre de DORA porte sur 3 383 événements. Environ un tiers ont produit des effets transfrontaliers. Ces chiffres concernent les incidents informatiques du secteur financier, et non exclusivement les communications. Ils illustrent néanmoins l’étendue possible des répercussions d’une défaillance numérique.

Orange : des suspensions préventives liées à PHP
Le 22 octobre, Orange a annoncé la fermeture temporaire de certains services après la publication de vulnérabilités PHP le 21 octobre.
Le groupe indique avoir interrompu ces accès pour installer les correctifs et effectuer les contrôles nécessaires.
Plusieurs filiales et entités sont concernées, avec une remise en service progressive des sites et applications.
Une mesure préventive.

Ces situations replacent la disponibilité des échanges dans les décisions de direction. Les performances, les fonctionnalités et les coûts doivent être examinés avec les conséquences d’une interruption prolongée. Les responsables opérationnels et, lorsque nécessaire, les fonctions de conformité ont donc leur place dans cette préparation. Confier une infrastructure à un prestataire ne dispense pas l’entreprise d’organiser sa propre continuité.

backdoor, Cybersécurité

OVHcloud expose le piratage de son outil de commande

OVHcloud a détaillé une attaque visant son outil de commande. Des téléchargements officiels piégés ont exposé les secrets des utilisateurs, déclenchant une réponse publique et documentée.

Une page officielle peut distribuer un logiciel malveillant lorsque sa publication est détournée. OVHcloud en a fait l’expérience avec son interface en ligne de commande, utilisée pour administrer des ressources cloud depuis un terminal. Un compte GitHub compromis a permis de remplacer les fichiers de cinq versions existantes, sans modifier leur code source. L’entreprise européenne a communiqué publiquement, retiré les exécutables concernés et documenté l’incident. L’exposition dépend du téléchargement effectué pendant la fenêtre d’attaque et de l’exécution du programme. Pour les utilisateurs concernés, réinstaller une version saine ne suffit pas : les secrets accessibles sur leur poste doivent également être révoqués.

Des archives officielles remplacées après publication

Le piège reposait sur une confiance quotidienne : télécharger un outil depuis le dépôt de son éditeur. Les utilisateurs retrouvaient le projet attendu, ses versions habituelles et des fichiers portant des noms familiers. Pourtant, certaines archives avaient été remplacées après leur publication initiale.

Cinq versions étaient concernées, de la 0.11.0 à la 0.15.0. Selon la reconstitution d’OpenSourceMalware, l’attaquant a utilisé les accès d’un contributeur disposant des permissions nécessaires pour modifier les fichiers associés aux versions publiées. Le détournement portait sur les exécutables distribués. Le code source et la chaîne de compilation n’avaient pas été altérés.

L’opération s’accompagnait du remplacement de checksums.txt, le fichier contenant les empreintes utilisées pour contrôler les téléchargements. Les nouvelles valeurs correspondaient aux archives piégées. Un utilisateur comparant son téléchargement avec cette référence modifiée pouvait donc obtenir un résultat rassurant. La vérification perdait son utilité puisque le fichier contrôlé et sa référence avaient été remplacés ensemble.

L’alerte est venue d’un client ayant conservé une empreinte SHA-256 attendue dans sa chaîne d’intégration. Lorsque l’archive Linux ARM a changé, le contrôle a échoué. Cette différence a conduit à un signalement public sur GitHub. Une référence enregistrée avant l’attaque a ainsi révélé une modification que les pages de téléchargement ne rendaient pas immédiatement visible.

La chronologie officielle situe la disponibilité des fichiers malveillants le 19 octobre 2026, entre 14 h 47 et 16 h 21, heure de Paris. OVHcloud a retiré les exécutables concernés puis publié la version 0.16.0, accompagnée d’une étiquette signée et de fichiers rendus immuables. Cette configuration empêche leur remplacement ultérieur au sein de la même publication.

La transparence d’OVHcloud se mesure ici à des éléments concrets : échanges publics avec l’auteur du signalement, horaires d’intervention, identification du défaut de configuration et publication d’un avis technique le 20 octobre. Le rapport annoncé dans les premières communications est désormais disponible. L’entreprise y décrit également les corrections appliquées et les mesures de renforcement envisagées.

Des secrets à révoquer sur les postes exposés

Le numéro de version, pris isolément, ne permet pas de déterminer l’exposition. Une copie légitime téléchargée avant le remplacement des archives reste différente d’un exécutable malveillant distribué ensuite sous la même référence. Il faut donc examiner la provenance du fichier et le moment de son acquisition.

Les téléchargements directs depuis GitHub, le script d’installation officiel et Homebrew pouvaient récupérer les archives remplacées. Une chaîne d’intégration automatisée pouvait également les télécharger sans intervention manuelle. Selon OpenSourceMalware, les compilations réalisées depuis le code source, notamment avec go install, échappaient à ce détournement. L’analyse distingue aussi l’image Docker construite en interne des exécutables substitués sur GitHub.

Le danger apparaît lorsque le programme piégé est lancé. L’avis officiel demande de considérer comme compromis les secrets présents sur un ordinateur ayant exécuté une copie concernée. Il recommande de vérifier les empreintes des fichiers suspects sans les lancer. Exécuter ovhcloud version pour obtenir un diagnostic ferait précisément démarrer le programme dont on cherche à établir l’innocuité.

Les accès à examiner dépassent le seul compte OVHcloud. Le texte initial cite notamment les clés d’API, la configuration ovh.conf, les clés SSH et les accès Kubernetes. Un poste d’administration peut concentrer des moyens de connexion à plusieurs environnements. La portée de l’incident dépend donc aussi des secrets effectivement accessibles sur chaque machine.

Depuis un ordinateur sain, les utilisateurs concernés doivent révoquer ou renouveler ces accès, puis remplacer l’exécutable compromis par une distribution propre. Supprimer le fichier malveillant ne retire aucune valeur aux identifiants déjà copiés. Tant qu’un secret reste valide, son détenteur peut tenter de l’utiliser.

L’attribution appelle une précision comparable. OpenSourceMalware rapproche la compromission ancienne du compte de l’écosystème GlassWorm, notamment à partir de traces dans des dépôts personnels et d’un portefeuille Solana connu. Son analyse initiale distingue toutefois ces indices de la preuve qu’un même opérateur aurait conduit toutes les étapes. Cette réserve évite de transformer un rapprochement technique en certitude.

Cybersécurité

Panne Orange : la 3G permet de retrouver du réseau

Une panne nationale frappe Orange ce 21 octobre 2026. Alors que les communications mobiles sont fortement perturbées, une manipulation permet de rétablir partiellement les appels et SMS.

Mercredi 21 octobre 2026, les abonnés Orange rencontrent d’importantes difficultés pour téléphoner, envoyer des SMS ou accéder à Internet depuis leur smartphone. Près de 12 000 signalements ont été enregistrés au plus fort de l’incident sur Downdetector. L’opérateur reconnaît une perturbation majeure, sans être encore en mesure d’en expliquer l’origine. Une solution provisoire apparaît néanmoins pour certains utilisateurs : abandonner temporairement la 4G et la 5G au profit de la 3G. Cette manipulation permet parfois de retrouver les communications vocales et les messages. Son efficacité dépend du téléphone, de sa configuration et de la couverture mobile disponible.

Une panne nationale qui perturbe les communications mobiles

Depuis plusieurs heures, les abonnés Orange (ainsi que la version low cost SOSH) affrontent une situation inhabituelle. Leur smartphone affiche parfois une absence de service, les appels échouent et les messages ne parviennent plus à leurs destinataires. Pour certains utilisateurs, la connexion mobile est également devenue inutilisable. L’incident prend rapidement une dimension nationale. Sur Downdetector, plateforme spécialisée dans le recensement des dysfonctionnements numériques, les signalements concernant Orange atteignent près de 12 000 à 11 h 50, mercredi 21 octobre.

L’opérateur confirme officiellement les difficultés. Dans un communiqué relayé par Le Parisien, Orange indique que l’incident compromet fortement les appels téléphoniques, les SMS et les services mobiles d’une partie de ses abonnés.

La portée de cette panne mérite une attention particulière. Fin juin 2026, Orange comptabilisait environ 21,6 millions de clients mobiles en France. Cette donnée illustre l’importance de ses infrastructures, sans signifier que l’ensemble de ses abonnés subit les perturbations.

À ce stade, aucune cause technique précise n’a été communiquée. Les équipes de l’opérateur poursuivent leurs investigations et aucune échéance de rétablissement n’est annoncée dans les informations publiées mercredi après-midi.

Une observation attire toutefois l’attention des utilisateurs : certains retrouvent du signal en abandonnant les réseaux mobiles les plus récents.

Ce constat suggère une différence de fonctionnement entre les générations de réseaux pendant l’incident. Il ne permet cependant pas d’identifier la défaillance initiale, ni de conclure à une panne exclusivement localisée dans les équipements 4G et 5G.

Aucun élément communiqué ne permet davantage d’évoquer une cyberattaque, une opération malveillante ou une compromission informatique. L’origine de l’interruption reste inconnue.

Au-delà du désagrément technique, la situation souligne la dépendance des communications quotidiennes à la disponibilité des réseaux des opérateurs. L’impossibilité de joindre un correspondant peut devenir particulièrement problématique lorsqu’une conversation présente un caractère urgent.

La difficulté ne concerne donc pas uniquement la navigation sur Internet. Elle touche également des services de communication élémentaires, normalement disponibles sur des téléphones mobiles parfois utilisés comme unique moyen de contact.

Comment réactiver la 3G sur iPhone et Android ?

Une solution de contournement circule parmi les abonnés touchés. Son principe consiste à forcer le smartphone à privilégier le réseau 3G plutôt que les connexions 4G ou 5G. Cette manipulation ne répare évidemment pas l’infrastructure d’Orange. Elle permet simplement, lorsque les conditions techniques le permettent, d’utiliser une génération différente du réseau mobile.

Sur certains anciens iPhone, il faut ouvrir les « Réglages », accéder à « Données cellulaires », puis aux « Options ». Dans le menu « Voix et données », l’utilisateur peut sélectionner « 3G », à condition que cette possibilité soit encore proposée. Les iPhone récents ne disposent généralement plus de ce réglage. La manipulation ne constitue donc pas une solution universelle pour les détenteurs de smartphones Apple.

Sur Android, le principe reste similaire. Il faut ouvrir les « Paramètres », rejoindre la rubrique « Réseau et Internet » ou « Connexions », puis rechercher « Type de réseau préféré » ou « Mode réseau ». Lorsque l’option existe, il suffit de sélectionner la 3G. Les intitulés diffèrent selon le constructeur, la version du système et les paramètres de l’opérateur. Certains téléphones récents ne permettent plus de forcer cette connexion.

Cette limite est essentielle. L’absence du choix 3G ne signifie pas que le smartphone fonctionne mal. Elle peut simplement résulter de sa configuration et des technologies encore prises en charge. Le Parisien rapporte que cette méthode a permis de retrouver des communications vocales et des SMS au cours de l’après-midi du 21 octobre. En revanche, l’accès à Internet demeurait interrompu lors de ses constatations.

Mise à jour : Des changements sur le réseau 5G ont entraîné la désynchronisation de plusieurs millions de numéros de téléphone. Une situation gênante, notamment lorsqu’on attend un code de double authentification (2FA) envoyé par sa banque. Sans parler de certains services d’urgence qui ne peuvent plus recevoir ni émettre d’appels. Dans certains cas, disposer d’une connexion de secours auprès d’un autre opérateur devient indispensable pour assurer la continuité des communications.

Cybersécurité, IA, Mise à jour, Patch, Securite informatique

Pwn2Own 2026 : les Pixel 10 et Galaxy S26 compromis

Les chercheurs de Pwn2Own Ireland 2026 ont multiplié les compromissions de smartphones pourtant actualisés, révélant des failles exploitables à distance.

Pwn2Own Ireland 2026 s’achève sur 98 vulnérabilités zero-day et 1 262 000 dollars de récompenses, soit environ 1 128 200 euros. Pendant trois jours, 29 équipes ont ciblé sept catégories de produits, des smartphones aux infrastructures d’intelligence artificielle. Le Google Pixel 10 a été compromis trois fois à distance, tandis que le Samsung Galaxy S26 a cédé lors des sept tentatives annoncées.

Trois attaques à distance contre le Pixel 10

Un téléphone à jour, aucune prise en main physique et, malgré ces conditions, une compromission réussie. Le Pixel 10 a concentré les regards pendant la dernière journée de Pwn2Own Ireland. Trois équipes ont successivement démontré qu’elles pouvaient attaquer le smartphone de Google à distance.

Tim Becker et Yves Bieri, de Xint, ont ouvert cette série avec l’exploitation d’une seule vulnérabilité. Leur tentative a toutefois rencontré une « collision », terme utilisé lorsque la faille présentée est déjà connue dans le cadre du concours. Cette particularité n’annule pas la réussite technique, mais intervient dans l’attribution de la récompense. Le duo a obtenu 150 000 dollars, environ 134 100 euros, et 15 points au classement Master of Pwn.

Ikotas Labs a ensuite compromis le même modèle en combinant plusieurs problèmes dans une chaîne d’exploitation. Cette démonstration lui a rapporté 300 000 dollars, soit environ 268 200 euros, ainsi que 30 points. Une récompense décisive dans la course au titre.

La troisième réussite revient à Dimitrios Valsamaras, Ken Gannon et Tenia Valsamara. Leur attaque associait deux vulnérabilités, dont une inédite et une collision. Elle leur a valu 112 500 dollars, environ 100 600 euros, et 22,5 points. Le compte rendu officiel mentionne notamment Mobile Hacking Lab, Djini.ai et CENSUS Labs pour présenter les participants et leurs affiliations.

Le Galaxy S26 a, lui aussi, accumulé les compromissions : les sept tentatives annoncées ont abouti. Certaines vulnérabilités étaient déjà connues de Samsung, selon les éléments rapportés, tout en restant exploitables pendant la compétition.

Cette précision compte. Une faille connue du fabricant ne signifie pas nécessairement qu’un correctif est disponible pour les utilisateurs. Inversement, une collision ne permet pas de présenter chaque composant d’une chaîne d’attaque comme une découverte entièrement nouvelle. Le bilan doit donc distinguer les attaques réussies, les vulnérabilités inédites et les problèmes déjà signalés.

L’IA et les objets connectés élargissent les cibles

Les smartphones n’occupaient qu’une partie du programme. Les équipes intervenaient également sur les infrastructures d’IA, les outils de programmation assistée, les messageries, les équipements domotiques, les imprimantes et les appareils de suivi de santé.

Parmi les produits visés figuraient OpenAI Codex et Oracle Autonomous AI Database. Les démonstrations concernaient aussi des imprimantes Lexmark, Canon et Brother, ainsi que Sonos Era 300, Philips Hue Bridge Pro, Home Assistant Green et Garmin Index BPM. Sur une imprimante, les chercheurs ont même fait fonctionner Doom, illustration visuelle d’une prise de contrôle technique.

Le cadre du concours impose des versions logicielles et des micrologiciels actualisés. Les réussites montrent ainsi que l’installation des correctifs disponibles ne supprime pas les vulnérabilités encore inconnues ou non corrigées. Elles ne permettent toutefois pas, à elles seules, d’affirmer que ces méthodes sont déjà utilisées contre des utilisateurs.

Ikotas Labs termine en tête avec 42,5 points Master of Pwn et 361 000 dollars, environ 322 700 euros. Xint suit avec 240 000 dollars, environ 214 600 euros. Team ZyGoat complète le podium avec 125 000 dollars, soit environ 111 700 euros.

Le bilan : 51 tentatives réussies sur 63 programmées. L’iPhone 17 figurait également parmi les cibles possibles, avec une prime maximale de 300 000 dollars, environ 268 200 euros. Aucun concurrent n’a enregistré de tentative contre lui. Cette absence ne constitue donc pas une démonstration de résistance du téléphone.

Les fabricants disposent désormais d’une fenêtre de 90 jours avant la divulgation publique des détails par la Zero Day Initiative. L’enjeu se déplace vers les correctifs : les démonstrations ont établi des possibilités d’exploitation, mais leur traitement déterminera la réduction effective de l’exposition.

backdoor, Cybersécurité, Mise à jour, Patch, Securite informatique

Ghostpat, la faille qui exposait les images Docker

Une faille critique de Docker Hub permettait d’utiliser les droits d’un autre utilisateur pour manipuler ses images de conteneurs, avec un risque pour la chaîne d’approvisionnement logicielle.

Identifiée sous la référence CVE-2026-105445, la vulnérabilité GhostPat touchait la conversion des comptes personnels Docker Hub en organisations. Un jeton d’accès conservé par un attaquant pouvait être réattribué à un autre utilisateur, donnant accès aux dépôts autorisés pour cette victime. Découverte par Peter Molnar et Krisztian Hozak, cette erreur de gestion des identités a reçu un score de gravité de 9,4 sur 10. Présente pendant plus de deux ans, elle pouvait permettre la publication d’images malveillantes sous une identité légitime.

Un jeton personnel pouvait changer d’identité

Le problème se trouvait dans une opération administrative de Docker Hub. Un utilisateur pouvait transformer son compte personnel en organisation et désigner un autre utilisateur comme propriétaire. Cette transition entraînait également le transfert des jetons d’accès personnels, les PAT, vers le propriétaire choisi.

Or, ce transfert ne s’accompagnait pas d’un renouvellement du secret permettant d’utiliser ces jetons. Leur ancien détenteur conservait donc une information toujours valide. Le nouveau propriétaire, lui, n’avait pas à donner son accord pour cette réattribution. Une opération de gestion de compte devenait ainsi une rupture dans le contrôle des accès.

Un attaquant pouvait exploiter cette combinaison en faisant rattacher à sa victime un jeton dont il connaissait déjà le secret. Docker Hub reconnaissait ensuite ce jeton comme appartenant à l’utilisateur ciblé. L’identité associée à l’accès avait changé, sans que la personne capable de l’utiliser ait perdu cette capacité.

Les conséquences dépendaient de deux éléments, les permissions du jeton et les droits de la victime. Selon leur combinaison, l’attaquant pouvait récupérer des images, en publier ou en supprimer. Le périmètre concernait les dépôts personnels accessibles à l’utilisateur ciblé, ainsi que ceux des organisations auxquelles celui-ci avait accès. La fiche CVE confirme cette possibilité d’agir sur les images au niveau du registre.

La menace dépassait donc la simple consultation non autorisée. Publier une image sous le nom d’un développeur légitime pouvait introduire du contenu malveillant dans une chaîne d’approvisionnement logicielle. L’image aurait été distribuée depuis un emplacement associé à un acteur réel, alors que son contenu pouvait avoir été modifié par un tiers.

Cette possibilité explique la qualification critique de GhostPat. Elle ne signifiait toutefois pas que toutes les fonctions du compte devenaient accessibles. La faille ne permettait pas de se connecter à l’interface web de Docker Hub, de changer le mot de passe, de modifier l’adresse électronique ou de toucher aux paramètres de double authentification. Le risque portait sur les opérations du registre autorisées par le jeton, avec des conséquences potentiellement importantes pour les images concernées.

Une enquête sur deux ans de transferts

Peter Molnar et Krisztian Hozak ont découvert cette vulnérabilité, baptisée GhostPat. Le défaut était resté présent dans le code pendant plus de deux ans. Cette durée imposait de vérifier rétrospectivement les conversions de comptes et les usages des jetons transférés.

Docker affirme avoir examiné l’ensemble de ces conversions sur la période concernée. L’entreprise a également étudié environ 304 000 publications d’images réalisées avec les jetons issus de ce mécanisme. Ce chiffre correspond à des opérations de dépôt dans le registre, et ne constitue pas un décompte d’images compromises ou d’attaques.

Les vérifications ont aussi porté sur les images publiques considérées comme les plus exposées à une éventuelle compromission. Selon Docker, ces investigations n’ont révélé aucun indice d’exploitation de GhostPat. Ce constat doit conserver son attribution, il s’agit du résultat communiqué par l’entreprise à l’issue de ses recherches, et non de la preuve qu’une attaque a eu lieu.

Au début d’octobre 2026, Docker a averti les utilisateurs dont les comptes avaient reçu des jetons provenant d’autres comptes. Les propriétaires des organisations correspondantes ont également été informés. L’enjeu était de permettre aux personnes concernées d’identifier ces accès et d’en vérifier la légitimité.

Le 8 octobre, les jetons potentiellement dangereux ont été désactivés. Une exception a été appliquée à ceux pour lesquels les titulaires avaient expressément demandé le maintien en activité. Docker recommande aux utilisateurs avertis d’examiner leurs jetons personnels et de révoquer ceux qu’ils ne reconnaissent pas ou dont ils n’ont plus besoin.

backdoor, Cybersécurité, Mise à jour, Patch

Ghostscript : un PDF piégé peut compromettre un serveur

Une faille critique de Ghostscript expose les serveurs traitant des PDF à une exécution de code, mais les essais montrent une exploitation dépendante de l’environnement ciblé.

Un document téléversé peut déclencher davantage qu’un simple enregistrement sur disque. Lorsqu’un serveur transforme un PDF en miniature, il peut solliciter Ghostscript, un composant de traitement documentaire touché par la vulnérabilité CVE-2026-39919. Cette corruption de mémoire concerne le traitement de certaines images JPEG 2000 intégrées aux documents. Les chercheurs ont obtenu une exécution de code sur un serveur WordPress préparé pour leurs essais. Cependant, leurs deux fichiers de démonstration n’ont produit aucune exécution de code lors de 10 240 tentatives sur dix autres environnements Linux. Un correctif existe depuis septembre 2026.

Une miniature de PDF comme point d’entrée

Ghostscript travaille souvent en coulisses. Cet interpréteur de documents PDF et du langage PostScript intervient dans le rendu des pages, la production d’aperçus ou l’optimisation des fichiers. Des applications comme ImageMagick, GIMP, Inkscape et Scribus l’utilisent, tout comme certaines configurations du système d’impression CUPS. Sa présence dépasse donc largement le périmètre des sites Internet.

Dans WordPress, la chaîne de traitement peut associer l’extension PHP Imagick, ImageMagick et Ghostscript pour fabriquer une miniature du PDF déposé dans la médiathèque. Le fichier fourni par un utilisateur atteint alors un programme installé sur le serveur. C’est cette opération de conversion qui rend la vulnérabilité accessible, lorsque les conditions techniques nécessaires sont réunies.

Des spécialistes ont découvert le problème le 23 août 2026. Le défaut est un débordement de tampon dans le tas, une zone de mémoire utilisée pendant l’exécution du logiciel. Il apparaît lors du traitement de PDF spécialement conçus contenant une image JPEG 2000.

L’erreur concerne des images dont les composantes présentent des résolutions différentes et utilisent moins de huit bits par valeur. Ghostscript calcule incorrectement l’espace mémoire nécessaire. Dans la démonstration décrite, le programme peut écrire 1 024 octets dans un tampon prévu pour seulement 256 octets. Cette écriture hors limites corrompt la mémoire et ouvre potentiellement la voie à l’exécution de code arbitraire.

Les versions concernées vont de Ghostscript 9.21 à 10.07.1, sous réserve de la présence du chemin de décodage vulnérable et des correctifs éventuellement intégrés par les distributions. Les environnements examinés comprenaient Debian, Ubuntu, Fedora, Alpine, AlmaLinux ainsi qu’un instantané de l’image Docker officielle de WordPress. Tous contenaient le code défectueux au moment des tests.

Cette présence ne signifie cependant pas que chaque installation peut être compromise avec le même document. Les chercheurs ont préparé deux preuves de concept, puis effectué 10 240 tentatives sur dix environnements Linux distincts. Aucune n’a abouti à une exécution de code en dehors de la construction logicielle correspondante.

A noter que les changements de polices, de paramètres linguistiques, de configuration des fontes et d’une bibliothèque système n’étaient pas des prérequis à réunir pour réussir. Les chercheurs ont modifié séparément ces éléments en conservant le même exécutable Ghostscript. L’exploitation restait possible dans les quatre configurations, avec une réussite intermittente. Leurs résultats soulignent surtout l’importance de la construction exacte du programme ciblé.

Des conditions précises et un correctif disponible

Pour WordPress, quatre conditions doivent se cumuler. Un attaquant doit pouvoir transmettre un PDF, anonymement ou depuis un compte disposant de faibles privilèges. Le site doit ensuite produire un aperçu du document. Cette conversion doit effectivement passer par Ghostscript, selon les logiciels installés et leurs politiques de sécurité. Enfin, le programme doit encore contenir le code vulnérable.

WordPress n’autorise pas, par défaut, les visiteurs anonymes à déposer des documents dans sa médiathèque. La présence du logiciel ou d’une image Docker concernée ne suffit donc pas à démontrer une exposition anonyme. Il faut examiner le parcours réel du fichier, depuis son téléversement jusqu’à son éventuel traitement.

Le périmètre dépasse néanmoins cette seule plateforme. Toute application qui transmet des PDF non fiables à une version vulnérable de Ghostscript peut présenter une surface d’exposition. La question opérationnelle porte ainsi sur les conversions réellement effectuées, y compris lorsque l’utilisateur ne voit qu’un formulaire de dépôt ou une miniature.

Artifex a corrigé CVE-2026-39919 avec la version finale 10.08.0, publiée le 8 septembre 2026. Des corrections ont également été reportées dans certaines branches antérieures. Un numéro de version ancien ne permet donc pas, à lui seul, de conclure que le paquet installé reste vulnérable. La révision complète et les informations du fournisseur sont déterminantes.

backdoor, cyberattaque, Cybersécurité, Espionnage Spy

Des opérateurs télécoms ciblés par un faux portail

Des courriels imitant un organisme de traçage des appels cherchent à pousser les opérateurs télécoms vers un logiciel permettant un accès à distance.

L’identité d’un acteur de la lutte contre les appels frauduleux devient un prétexte d’hameçonnage. Des entreprises inscrites dans la Robocall Mitigation Database reçoivent de fausses demandes attribuées à l’Industry Traceback Group (ITG). Le message présente un portail prétendument sécurisé et invoque un délai de vingt-quatre heures pour provoquer une réaction rapide. L’Industry Traceback Group (ITG) est un organisme américain piloté par US Telecom, une association professionnelle du secteur des télécommunications. Il coordonne le traçage des appels suspects, notamment ceux liés aux escroqueries et aux appels automatisés illégaux. Ce n’est pas un service de police.

Concrètement, un appel peut traverser plusieurs opérateurs avant d’atteindre son destinataire. L’ITG demande à chacun d’identifier l’opérateur qui lui a transmis cet appel, puis remonte la chaîne jusqu’à son origine. Cette procédure s’appelle le traceback. Les informations recueillies peuvent soutenir les enquêtes des autorités.

Le lien conduit en réalité vers un dépôt GitHub proposant un logiciel dont l’installation permettrait un accès distant. Cette description documente une tentative de compromission ; elle ne fournit aucun bilan vérifié des entreprises effectivement touchées, des installations réalisées ou des données éventuellement dérobées aux destinataires.

Dans l’affaire évoquée, les attaquants usurpent l’identité de l’ITG pour rendre crédible une fausse demande de traçage et inciter les destinataires à ouvrir un lien piégé. Les attaquants auraient utilisé les coordonnées publiques du registre RMD pour adresser aux professionnels de fausses demandes de traçage. La base sert alors à identifier les personnes à cibler ; cela ne signifie pas qu’elle a été piratée.

La Robocall Mitigation Database (RMD) est un registre public de la FCC, le régulateur américain des télécommunications. Elle recense les opérateurs concernés et les mesures qu’ils déclarent appliquer contre les appels automatisés illégaux, appelés robocalls. Les opérateurs y déposent notamment leur identité et les coordonnées d’un responsable ; leur programme de lutte contre les appels illégaux ou encore leur niveau de déploiement de STIR/SHAKEN, un dispositif d’authentification du numéro présenté lors d’un appel.

L’inscription a une conséquence concrète : les opérateurs soumis aux règles américaines ne doivent pas accepter directement le trafic des fournisseurs absents de cette base. Une radiation peut donc empêcher un fournisseur d’acheminer ses appels vers le réseau américain. L’inscription reste une déclaration réglementaire, pas une garantie que tous ses appels sont légitimes.

Android, backdoor, Cybersécurité, Entreprise, Espionnage Spy, Securite informatique, Smartphone

Midnight Mimosa infecte Android avant le premier démarrage

Des smartphones Android arrivent chez leurs propriétaires avec un logiciel malveillant déjà intégré, capable d’installer des applications discrètement et de détourner leur connexion Internet à des fins frauduleuses.

Midnight Mimosa transforme des téléphones Android à bas prix en supports de fraude publicitaire et, potentiellement, en relais réseau contrôlés à distance. Cette campagne touche des milliers d’appareils dans plus de 150 pays, dont la France. Sa particularité tient à son implantation dans le micrologiciel, le logiciel qui accompagne le matériel et participe au fonctionnement du téléphone. Le propriétaire peut donc recevoir un appareil déjà compromis, sans avoir téléchargé la moindre application suspecte. Les chercheurs décrivent une infection persistante, dotée de privilèges système, dont l’origine exacte dans la chaîne d’approvisionnement reste à établir.

Une infection installée au cœur du téléphone

Le premier téléchargement dangereux n’existe parfois pas. Dans cette affaire, le composant malveillant précède l’utilisateur et bénéficie de droits habituellement réservés au fonctionnement d’Android. Une apparence de service technique suffit ensuite à brouiller les pistes.

Selon les éléments rapportés, le logiciel d’espionnage de téléphone Midnight Mimosa serait actif depuis au moins deux ans. Le Mexique, la France, l’Italie, les États-Unis, l’Allemagne, le Brésil et l’Espagne figurent parmi les pays les plus représentés dans les observations des chercheurs. Ces données décrivent les appareils détectés, sans constituer un recensement exhaustif des victimes.

L’infection concerne notamment des smartphones économiques équipés de plateformes MediaTek, parmi lesquels les Doogee S200 X et Cubot KINGKONG X. Des contrefaçons reproduisant l’apparence de modèles Samsung ou Apple apparaissent également dans les éléments présentés. Cette présence ne permet pas d’attribuer une responsabilité au fournisseur des puces ni aux marques imitées.

Le point d’entrée précis demeure inconnu

L’hypothèse privilégiée est celle d’une introduction au cours de la chaîne d’approvisionnement. Les informations disponibles ne permettent toutefois d’identifier ni l’étape concernée ni les responsables. La découverte d’un composant dans un micrologiciel ne démontre pas, à elle seule, la participation consciente du fabricant.

Le logiciel se présente notamment sous les noms com.android.system.lite et com.android.sys.prot. Ces intitulés évoquent des fonctions internes ordinaires. Derrière cette façade, les composants disposent de signatures et de permissions leur permettant d’agir avec des privilèges élevés. Le gestionnaire d’applications classique ne suffit donc pas à les supprimer. Sur les forums XDA, des propriétaires de téléphones Cubot et Doogee ont signalé le retour d’applications suspectes après leur suppression. Un utilisateur de Doogee Fire 3 Max rapporte une apparition après une mise à jour officielle, suivie d’une disparition après restauration d’un micrologiciel antérieur. Ce témoignage apporte un indice sur son appareil, sans établir un scénario identique pour toute la campagne.

Les capacités décrites dépassent largement l’affichage publicitaire. Midnight Mimosa peut ajouter ou retirer des applications sans solliciter le propriétaire, accorder des autorisations et exécuter du code transmis par ses opérateurs. Le téléphone conserve ainsi un composant capable de renouveler les charges malveillantes.

Publicités invisibles et connexions détournables

Les chercheurs ont recensé environ 32 applications distribuées par ce dispositif. Météo, gestion de fichiers, reconnaissance de texte ou édition audio leur servent de couverture. Ces fonctions familières rendent leur présence moins immédiatement suspecte.

La rémunération repose principalement sur une fraude publicitaire. Les applications utilisent un kit publicitaire légitime pour récupérer de véritables annonces. Leur affichage s’effectue cependant dans des fenêtres invisibles superposées à d’autres applications. Le système publicitaire peut alors comptabiliser une impression sans qu’aucun utilisateur ait réellement vu le contenu.

Certaines variantes automatisent aussi les interactions. Des clics sont produits sans geste du propriétaire, donnant artificiellement de la valeur à une audience inexistante. L’utilisation d’une technologie publicitaire légitime ne rend donc pas légitime l’activité qui l’exploite.

Pour faciliter les installations, le logiciel désactive temporairement l’application Google Play Store, identifiée par com.android.vending, puis la réactive. Bitdefender présente cette séquence comme une tentative de contourner la détection par Play Protect. Certaines variantes falsifient également l’origine déclarée d’une installation pour lui donner l’apparence d’un téléchargement depuis la boutique officielle.

Une autre capacité concerne un proxy TCP, susceptible de faire transiter du trafic extérieur par la connexion du téléphone. L’adresse IP du propriétaire devient alors un point de sortie potentiel pour des activités qu’il ne contrôle pas. L’accès à de tels relais résidentiels peut être commercialisé.

La capacité technique et son exploitation effective doivent être distinguées. Les chercheurs ont confirmé le fonctionnement de l’infrastructure de contrôle associée, sans pouvoir déterminer si les téléphones infectés avaient effectivement relayé du trafic comme proxys.

Treize applications liées à la campagne ont également été repérées sur Google Play avec un code frauduleux similaire. Elles ne disposent cependant pas des privilèges des composants préinstallés. Les assimiler entièrement effacerait une différence essentielle pour comprendre la persistance de l’infection. La suppression nécessite un micrologiciel sain ou une désactivation des composants concernés au moyen d’Android Debug Bridge (ADB). Désactiver ne signifie toutefois pas retirer le code du micrologiciel.

Petites entreprises, grandes menaces : restez informés, restez protégés

Quitter la version mobile