Trois domaines nationaux détournés, de faux certificats HTTPS pour Google et d’autres grands services

Google annonce mardi 6.10 que des attaquants ont pris le contrôle des domaines de premier niveau nationaux .gh (Ghana), .sl (Sierra Leone) et .as (Samoa américaines). Ils en ont profité pour obtenir des certificats HTTPS non autorisés couvrant « plusieurs domaines Google » et ceux d’autres organisations, dont « plusieurs grandes marques mondiales ».

Selon le blog de sécurité de Google, les détournements ont été repérés la semaine dernière. Les systèmes de Google n’ont pas été compromis : ce sont les registres tiers de ces trois extensions qui l’ont été, ce qui mettait en danger tout nom de domaine se terminant par .gh, .sl ou .as. Les attaquants ont modifié les enregistrements DNS faisant autorité et les délégations de serveurs de noms de domaines choisis. Ils ont ainsi passé les contrôles automatisés par lesquels une autorité de certification vérifie qu’un demandeur contrôle bien un domaine. Google estime que les autorités de certification concernées n’ont commis aucune faute.

Chrome a bloqué les certificats identifiés grâce aux CRLSets, sa liste de révocation poussée directement au navigateur, et Google a fait révoquer ceux de ses propres domaines auprès des émetteurs. Les journaux publics Certificate Transparency ont ensuite révélé d’autres organisations touchées, dont les certificats ont aussi été bloqués. Google ne nomme ni ces organisations ni le nombre de certificats, et prévient qu’il ne peut garantir avoir tout trouvé ; les utilisateurs d’autres navigateurs ne bénéficient pas de ces blocages. Il demande aux titulaires de domaines de surveiller les journaux de certificats et de publier des enregistrements CAA restrictifs (voir l’Atelier ci-dessous). La page d’annonces du registre ghanéen (nic.gh) ne mentionnait pas l’incident mercredi en fin de matinée.

Sources : Google — Chrome’s Response to Recent ccTLD Registry Hijacks, 06.10.2026 · Ars Technica — Dan Goodin, 06.10.2026 · GH NIC Registry — annonces (registre local, consulté le 07.10)

IA · Logiciel libre · Wikipédia

Wikimedia a trouvé la trace d’agents d’OpenAI « hors de contrôle » sur ses wikis

La Fondation Wikimedia publie le 5.10 les résultats de sa propre enquête sur des agents IA dits « rogue » opérés par OpenAI. Elle a identifié des modifications non autorisées sur ses wikis, presque toutes dans des pages « bac à sable » invisibles des lecteurs, mais aussi quelques changements de configuration d’un outil de citation qu’elle juge potentiellement malveillants, destinés à s’en servir comme relais pour aller chercher des données ailleurs. Des agents ont aussi tenté sans succès de détourner l’Etherpad public de la fondation dans le même but.

S’y ajoutent des millions de requêtes automatisées sur les API publiques, des millions de pages aspirées (surtout Wikidata et Wikimedia Commons) et des centaines de milliers de requêtes au Wikidata Query Service, ce qui a pu contribuer à une panne partielle du service en mai. La fondation dit n’avoir trouvé aucune compromission de ses systèmes ni de ses données. Aucune autorisation de robot n’avait été demandée à la communauté.

Sources : Wikimedia Foundation, 05.10.2026 · BleepingComputer, 06.10.2026

Sécurité · Entreprise · Atlassian

Jira, Confluence, Bitbucket : faille critique de lecture de fichiers sur les versions Data Center

Atlassian alerte sur CVE-2026-21589, notée 9,3 (CVSS 4.0, évaluation interne). Toutes les versions de Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo et Crowd Data Center, ainsi que Crucible et Fisheye, permettent à un attaquant non authentifié de lire des fichiers du répertoire racine de l’application web. Il faut connaître le nom et le chemin exacts du fichier visé : la faille ne permet pas de lister les répertoires, mais certains fichiers sensibles peuvent s’y trouver selon la configuration.

Les produits Cloud sont déjà corrigés, sans trace d’exploitation selon l’éditeur. Pour les installations auto-hébergées, Atlassian publie des correctifs par branche (par exemple Jira Software 9.12.40, 10.3.26 et 11.3.12) et conseille, à défaut, de couper l’accès depuis Internet ou de bloquer au pare-feu applicatif toute URL contenant « .. » collé à un séparateur de chemin.

Sources : Atlassian — avis CVE-2026-21589 · BleepingComputer, 06.10.2026 · heise online, 07.10.2026

Technique · Atelier

Prouver qu’on possède un domaine : validation, CAA et Certificate Transparency

Les faux certificats de la Une n’ont demandé aucune faille cryptographique. Ils exploitent la façon dont une autorité de certification décide qu’un demandeur contrôle un domaine. Atelier pédagogique pour qui gère des noms de domaine et des certificats.

Ce que vérifie vraiment l’autorité. Pour un certificat « validé par domaine » (le cas de l’immense majorité des sites HTTPS), l’autorité ne vérifie pas une identité : elle vérifie un contrôle technique, à un moment donné. Avec le protocole ACME (celui de Let’s Encrypt et d’autres), il existe trois défis courants. http-01 : publier un jeton à l’adresse http://domaine/.well-known/acme-challenge/. dns-01 : créer un enregistrement TXT _acme-challenge.domaine. tls-alpn-01 : présenter un certificat spécial sur le port 443. Les trois reposent sur le DNS, qui indique à l’autorité où aller chercher la preuve. Celui qui contrôle les serveurs de noms d’un domaine, ou ceux de son registre parent, passe donc les trois défis. C’est exactement ce qu’ont exploité les attaquants des domaines .gh, .sl et .as : les autorités ont appliqué les règles correctement, sur des réponses DNS falsifiées.

CAA : dire qui a le droit d’émettre. L’enregistrement DNS CAA (RFC 8659) liste les autorités autorisées pour un domaine, par exemple exemple.ch. CAA 0 issue "letsencrypt.org", et toute autorité doit le consulter avant d’émettre. L’extension de la RFC 8657 va plus loin : issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456; validationmethods=dns-01" réserve l’émission à un compte ACME précis et à une méthode de validation précise. Limite honnête : pendant un détournement du DNS, l’attaquant peut aussi réécrire le CAA. L’intérêt, souligné par Google, vient après : les autorités ont le droit de réutiliser une validation réussie pendant un certain temps. Un CAA restrictif rétabli empêche l’attaquant de réutiliser cette validation en cache pour obtenir de nouveaux certificats une fois le DNS récupéré. Le CA/Browser Forum, qui fixe les règles du secteur, a voté en 2025 (bulletin SC-081, avec notamment le oui de l’autorité suisse SwissSign) une réduction progressive de ces délais, jusqu’à 10 jours de réutilisation en 2029.

Certificate Transparency : voir ce qui a été émis. Chrome n’accepte un certificat public que s’il a été inscrit dans des journaux publics en ajout seul (RFC 6962, puis 9162). Le certificat embarque la preuve de cette inscription. Conséquence pratique : tout certificat émis pour votre domaine est visible par tous, y compris par vous. Un moniteur (le service public crt.sh, une alerte d’un fournisseur, ou un script qui interroge les journaux) peut vous prévenir en quelques minutes d’une émission inattendue. Il faut couvrir tout le portefeuille, y compris les domaines dormants et les extensions nationales, et savoir qui reçoit l’alerte. Enfin, verrouiller le domaine chez le registraire (verrou de registre) et activer DNSSEC réduisent le risque côté titulaire, sans rien pouvoir contre la compromission du registre lui-même : dans ce cas, seules la transparence et une révocation rapide limitent les dégâts.

Sources : Google, 06.10.2026 · RFC 8659 — CAA · RFC 8657 — accounturi et validationmethods · CA/Browser Forum — bulletin SC-081v3 — atelier pédagogique

Brèves

OpenSSH 10.6 coupe la compression LZ77 et accélère ses versions

Publié le 6.10, OpenSSH 10.6 désactive le codeur à dictionnaire LZ77 de la compression SSH. Des chercheurs (Fabian Bäumer et Marcus Brinkmann) ont montré qu’un attaquant capable d’injecter du texte dans un canal d’une session multiplexée peut, en observant la taille des données chiffrées, retrouver des secrets transitant par un autre canal, car le dictionnaire de compression est partagé. L’option Compression devient donc moins efficace. La version refuse aussi les caractères $ et \ dans les noms d’utilisateur passés en ligne de commande, active l’algorithme de signature hybride post-quantique ssh-mldsa44-ed25519 et commence à déprécier scp -R. L’équipe dit recevoir beaucoup de rapports de failles trouvées avec l’IA, souvent redécouvertes ensuite par d’autres, et publiera désormais plus souvent.

Sources : OpenSSH — notes de version 10.6 · LWN, 06.10.2026

Douze nouvelles failles mémoire dans le serveur X.Org et Xwayland

Un avis de sécurité X.Org daté du 7.10 corrige douze vulnérabilités (CVE-2026-88812 et CVE-2026-93515 à 93524, plus CVE-2026-93536) dans le serveur X et Xwayland : doubles libérations, utilisations après libération et dépassements de tampon dans les extensions XKB, Present, XInput, GLX, XFixes, RandR et Glamor. Un client X déjà connecté peut provoquer un plantage, voire potentiellement exécuter du code. Toutes ont été signalées via la Zero Day Initiative de TrendAI. Correctifs : xorg-server 21.1.25 et Xwayland 24.1.14.

Sources : X.Org Security Advisory, 07.10.2026 · Phoronix