Connexion
Bon, j'avoue que j'ai un petit peu lâché l'affaire pour mon summer body. Avec cette canicule, je suis à deux doigts de me faire une raclette. Par contre, s'il y a un truc dont je ne supporte pas qu'il grossisse, c'est bien mon système d'exploitation.
Et pourtant, si vous êtes sous Windows 11, eh bien c'est le cas ! Celui-ci se remplit tout seul sans explication, en tout cas jusqu'à maintenant, parce qu'on tient enfin le coupable !! C'est un fichier caché qui grossit dans son coin depuis des mois et des mois et Microsoft vient enfin de reconnaître le bug et de le corriger. Donc je vous explique tout...
Le fautif s'appelle CapabilityAccessManager.db-wal, planqué dans le dossier C:\ProgramData\Microsoft\Windows\CapabilityAccessManager et derrière ce nom barbare se cache en réalité le log d'une petite base de données SQLite, celle qui note chaque fois qu'une application réclame l'accès à votre webcam, votre micro ou votre position. Normalement ce fichier pèse quelques dizaines de kilo-octets et se vide tout seul, sauf que pas de bol, une mise à jour de Windows a cassé ce petit ménage automatique et donc notre journal enfle chaque jour un peu plus sans jamais se compacter. Alors vous pourriez vous dire que c'est pas très grave, mais il grossit quand même de deux giga par jour ce sagouin.
Résultat, des utilisateurs ont vu ce fichier grimper à 70 Go, 110 Go, 200 Go, et le record documenté monte à 513 Go. Le "500 Go" des gros titres, c'est donc le cas extrême, pas la moyenne mais même à 50 ou 100 Go engloutis en douce, ça suffit à saturer un SSD et à ralentir toute la machine. Plusieurs personnes ont aussi remarqué un Wi-Fi qui traîne, un effet de bord du même souci.
La bonne nouvelle maintenant, c'est que Microsoft a fini par corriger le tir avec la mise à jour optionnelle KB5095093 du 23 juin dernier, qui nettoie même le fichier gonflé au redémarrage et vous rend l'espace perdu d'un coup. Et le correctif deviendra obligatoire pour tout le monde lors du Patch Tuesday de juillet. Si vous ne l'avez pas encore, direction Windows Update, options avancées, puis les mises à jour facultatives.
Et si c'est trop tard, et que votre disque est déjà plein à ras bord et que vous voulez récupérer la place immédiatement, vous pouvez supprimer le fichier à la main. Attention quand même, il faut d'abord arrêter le service concerné, sinon le fichier reste verrouillé et la suppression échoue.
Dans un PowerShell en administrateur :
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) net stop camsvc
del "C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.db-wal"
Supprimez uniquement le fichier terminant par .db-wal, surtout pas le .db juste à côté. Un redémarrage plus tard, le service repart proprement et le fichier repart de zéro. Si vous croisez du Dell SmartByte ou d'autres bloatwares du genre sur un portable, virez-les aussi, ils font partie des déclencheurs connus.
Pour le reste, si vous avez la manie du disque bien rangé, c'est le bon moment pour un grand ménage de printemps avec BleachBit , jeter un œil à ces astuces quand Windows rame , ou carrément partir sur un Windows 11 allégé façon tiny11 .
Bref, voilà, si votre espace disque a fondu ces derniers mois sans raison, vous savez maintenant où regarder.
Si vous avez remarqué récemment que les logos de vos correspondants pros sont remplacés par une vilaine croix rouge dans Outlook, ou pire, que certaines pièces visuelles disparaissent purement et simplement de vos mails, ce n'est ni votre antivirus ni votre connexion.
The Register a sorti le sujet la semaine dernière, et Microsoft a fini par confirmer un bug introduit dans la version 2604 (Build 19929.20164) de Classic Outlook, qui fait planter l'affichage de certaines images dans les emails.
Le problème ne touche pas n'importe quelle image. La condition pour le déclencher, c'est d'avoir une option de mise en page particulière activée, "Habiller le texte en haut et en bas" (l'image flotte au-dessus du texte avec le contenu qui s'écoule au-dessus et en dessous).
Avec cette configuration, Outlook se prend les pieds dans le tapis et affiche à la place un message d'erreur du genre "L'image liée ne peut pas être affichée. Le fichier a peut-être été déplacé, renommé ou supprimé.", ou parfois rien du tout, juste un trou blanc.
Le plus pénible, c'est que les premières victimes sont les signatures de mail qui contiennent un logo d'entreprise. Vous savez, ce petit truc obligatoire qui doit faire identité de marque sur chaque message envoyé. Eh bien, chez pas mal de monde, ces logos se retrouvent désormais accompagnés d'une jolie croix rouge ou d'une boîte vide. Pratique pour faire pro auprès des clients.
Microsoft a publié sur son site de support un correctif temporaire qui consiste à demander aux utilisateurs de changer le réglage d'habillage de leurs images, en passant sur un autre mode (intégré dans le texte, derrière le texte, etc.). Pas idéal. Encore moins quand on ne sait même pas où trouver ce réglage et qu'on l'a mis en place il y a deux ans avec l'aide du service info de la boîte.
Pour la suite, c'est encore moins drôle. Microsoft précise que les images des messages d'origine reviendront normalement une fois le correctif déployé, ce qui est plutôt rassurant. Sauf que pour les réponses ou les transferts faits pendant la période bugée, certaines images peuvent disparaître définitivement, parce qu'elles ne se seront tout simplement pas attachées au nouveau message.
Ce qui veut dire que tout un fil de discussion sur un projet visuel risque de perdre des morceaux en chemin sans qu'on s'en rende compte tout de suite.
Aucune date n'est annoncée pour le déploiement du correctif définitif. C'est typiquement le genre de bug qui aurait dû être attrapé en interne avant publication, sur une fonctionnalité aussi basique que l'affichage d'une image.
Et c'est aussi un rappel utile que Classic Outlook (la version installée historiquement sur Windows, par opposition au New Outlook web) reste largement utilisée en entreprise et que ses bugs touchent vraiment beaucoup de monde.
Au passage, si vous hésitez entre attendre le correctif et passer sur le nouveau Outlook ou un client tiers, ça peut être l'occasion de jeter un œil ailleurs.
Source : The Register
L'histoire nous vient de Málaga, racontée par la Policía Nacional et reprise par The Register. Un magasin de paris local est pris en défaut par un bug logiciel qui affiche des gains doublés sur plusieurs tickets de la journée.
Les parieurs concernés voient leur jackpot apparaître deux fois à l'écran, et vont logiquement le réclamer au guichet. Sauf que la direction du groupe, une fois prévenue, refuse net d'honorer les paiements erronés. Les clients repartent avec leur mise normale, et bien bien remontés.
Parmi ces parieurs floués, visiblement, l'idée du recours en justice n'a pas séduit tout le monde. Un agent de sécurité du magasin lui-même, selon la police, s'associe à un complice non identifié pour monter une combine.
Les deux se présentent aux parieurs lésés comme des "intermédiaires" capables de récupérer l'argent dû, à condition que les clients leur fassent confiance pour la suite. Une petite économie parallèle de compensation, en somme.
Le problème, c'est la méthode choisie pour faire pression sur la direction. Les deux comparses traquent le gérant du magasin, obtiennent son adresse personnelle, lui envoient des SMS et des enregistrements audio d'intimidation, puis finissent par l'enlever.
La rançon demandée est de 50 000 euros, avec des exigences qui évoluent en cours de négociation, vers des acomptes plus petits et plus rapides. Clairement des kidnappeurs qui improvisent.
Heureusement pour le gérant, ça n dure pas. Après une info anonyme, la Policía Nacional localise le point de rendez-vous du premier versement, un fast-food dans un centre commercial de Málaga, et y interpelle les deux suspects en même temps qu'elle libère l'otage. Le tout 90 minutes après l'enlèvement, sans paiement effectué et sans blessé. Les deux hommes sont maintenant en détention pour kidnapping.
Moralité : un bug logiciel plus une mauvaise gestion de la communication client égale un agent de sécurité qui se reconvertit en pseudo-Robin des Bois. Le refus de la direction de payer les erreurs système est discutable commercialement, mais ce n'est clairement pas ce qui justifie d'enlever qui que ce soit.
Bref, un bon audit du logiciel de paris, et une réponse client un peu plus habile, auraient évité tout ce bordel.
Source : The Register
Une vulnérabilité Microsoft patchée en 2012, deux fois, refait surface en 2026 dans des attaques actives. Elle fait partie des quatre failles que la CISA a collées lundi dans son catalogue des bugs activement exploités, avec obligation pour les agences fédérales américaines de patcher sous deux semaines. 14 ans plus tard, un vrai bug zombie.
La plus vieille, c'est CVE-2012-1854, un chargement de bibliothèque non sécurisé dans Visual Basic for Applications. Microsoft l'a corrigée une première fois en juillet 2012, puis encore en novembre de la même année.
Ça n'a pas suffi. Des attaquants trouvent toujours des machines non patchées sur lesquelles elle fonctionne, et exécutent du code à distance via VBA. Un classique des macros Office qui refuse de mourir.
Les trois autres ne sont pas plus rassurantes. CVE-2023-21529, une désérialisation de données non fiables dans Exchange Server, permet à un attaquant authentifié de faire de l'exécution de code à distance.
Elle était patchée en février 2023. CVE-2023-36424 touche le driver Common Log File System de Windows et ouvre la porte à une escalade de privilèges (patchée en novembre 2023). Et la dernière, CVE-2025-60710, est une faille de link-following dans Windows qui donne également de l'escalade de privilèges.
Côté exploitation active, les chasseurs de menaces Microsoft pointent Storm-1175, un gang financièrement motivé qui combine la faille Exchange avec 15 autres pour entrer dans des organisations, siphonner leurs données et déployer le ransomware Medusa. Du classique en plusieurs étapes, sauf que le point d'entrée est une faille colmatée depuis trois ans.
Ce qui est frappant dans la liste, c'est que trois failles sur quatre disposent d'un patch depuis des années. La CISA ne découvre pas des zero-days, elle constate que le parc à patcher est toujours aussi béant, y compris dans les administrations fédérales US. Côté SI de PME françaises qui tournent sur un Exchange vieillissant, je vous rassure le tableau n'a aucune raison d'être meilleur.
Patcher Exchange reste un gros chantier pour beaucoup d'équipes IT, entre les dépendances métier, les interfaces custom et la peur de casser la messagerie. Sauf que voilà, tant que ce n'est pas fait, le ransomware a un boulevard.
Bref, si vous avez un Exchange ou un Windows qui traîne avec des patches manquants depuis 2012 ou 2023, c'est vraiment le moment de vous y coller.
Source : The Register
49 jours, les amis, c'est la durée de vie d'un Mac avant que son réseau TCP ne s'effondre dans un silence assourdissant. Il suffit d'un overflow d'entier 32 bits dans le kernel XNU, une horloge interne qui se bloque, et hop, plus moyen d'ouvrir la moindre connexion. Le ping marche toujours, parce qu'ICMP se fout du TCP, mais pour le reste... c'est reboot obligatoire ou rien.
Pour savoir combien de temps il vous reste, tapez uptime dans le Terminal. Si votre Mac sous macOS Sequoia, Sonoma ou même Ventura tourne depuis plus de 7 semaines sans redémarrage, c'est le moment d'y remédier car le bug touche toutes les versions.
C'est l'équipe de Photon qui a révélé le problème. Celui-ci est apparu sur une flotte de Macs dédiée à la télémétrie iMessage. Pile 49,7 jours après le dernier redémarrage, plusieurs machines ont lâché en même temps. Plus de nouvelles connexions réseau, mais le ping répondait toujours.
En fouillant le code du
noyau XNU d'Apple
(qui est open source, faut le rappeler), ils sont tombé sur une variable tcp_now, qui est un compteur 32 bits qui s'incrémente chaque milliseconde. En gros, imaginez un compteur kilométrique qui arrivé au max (environ 4,3 milliards), repasse à zéro.
Sauf que le code contient un garde fou censé empêcher l'horloge de reculer du genre "si la nouvelle valeur est plus petite que l'ancienne, on ne met pas à jour". Ça a l'air malin mais en fait, au moment du rebouclage, patatras : la nouvelle valeur (proche de zéro) est forcément plus petite que l'ancienne (proche du max), du coup le garde fou bloque tout et l'horloge TCP se fige.
Et ensuite, ça part en cascade. Les connexions fermées restent normalement en TIME_WAIT durant 30 secondes sur macOS, avant d'être nettoyées par tcp_gc() mais avec l'horloge gelée, ce nettoyage ne se fait plus. Un netstat -an | grep TIME_WAIT montre alors la catastrophe en temps réel avec des connexions mortes qui s'empilent, et finissent par bouffer les 16 384 ports éphémères (range 49152-65535 sur macOS) restant... Et au bout de quelques heures, plus rien ne passe !
Photon a laissé tourner deux machines après l'overflow pour voir. Neuf heures plus tard, l'une affichait 8 000 connexions zombies et un load average de 49. La machine ne faisait plus que scanner sa propre file d'attente de connexions mortes.
Si ça vous rappelle quelque chose, c'est normal car j'sais pas si vous vous souvenais mais Windows 95 plantait au bout du même délai pour la même raison (le fameux GetTickCount() en 32 bits). Le Boeing 787 avait également un souci similaire au bout de 51 jours sur ses switches réseau, sans oublier le bug de l'an 2038 sous Unix, qui est la version signée du même phénomène. 30 ans séparent certains de ces bugs qui pourtant appartiennent à la même catégorie !
Après flippez pas car des devs avec des Macs à plus de 600 jours d'uptime disent n'avoir jamais eu le souci. À vrai dire, le bug ne se déclencherait que si votre Mac n'a aucun trafic TCP pile au moment de l'overflow. Si votre machine cause au réseau en permanence (et c'est le cas de 99% des Macs), l'horloge passe le cap sans broncher.
Les machines les plus exposées sont en fait les serveurs CI/CD sous macOS, les
Mac mini
en ferme de build Jenkins ou GitHub Actions, les Mac Pro dédiés au rendu 3D avec Blender ou Cinema 4D. Le MacBook qui passe en veille tous les soirs n'est pas vraiment concerné (le compteur tcp_now ne tourne pas pendant la veille, donc le délai de 49 jours ne concerne que le temps d'activité réel).
Maintenant pour vérifier votre compte à rebours personnel, ouvrez un Terminal et collez y ceci :
boot_sec=$(sysctl kern.boottime | grep -o 'sec = [0-9]*' | head -1 | awk '{print $3}')
now_sec=$(date +%s)
remain=$(( 4294967 - (now_sec - boot_sec) ))
echo "Temps restant avant overflow : $((remain/3600))h $((remain%3600/60))m"
Apple n'a pour l'instant rien communiqué sur le sujet, ce qui n'est guère surprenant vu que c'est un peu leur spécialité quand une vulnérabilité est remontée. L'équipe de Photon dit travailler sur un moyen de contourner le problème qui éviterait de rebooter, mais en attendant, le seul fix c'est le redémarrage, qui remet le compteur à zéro... et relance le compte à rebours.
Bref, y'a rien à faire si ce n'est de vérifier votre uptime et faire éventuellement un petit reboot préventif. Tic tac, l'horloge tourne ^^.
