Autopsie d'une résistance carbone vintage
CuriousMarc, un youtubeur connu pour ses restaurations d'équipements électroniques d'époque, est tombé sur un cas intéressant lors de la réparation d'un oscilloscope Metrix vintage.
Après avoir changé tous les condensateurs (un "recap" en jargon, opération de routine sur les vieux équipements dont les condos sèchent avec le temps), l'appareil refusait toujours de fonctionner correctement. Coupable identifié : une résistance carbone de 20 kΩ qui mesurait 0,843 MΩ au multimètre. Soit 42 fois sa valeur d'origine.
Visuellement, la résistance n'avait absolument rien de suspect. Pas de fissure, pas de brûlure, pas de décoloration. Du coup, plutôt que la jeter et passer à autre chose, Marc a décidé de l'ouvrir pour comprendre ce qui s'était passé à l'intérieur.
L'opération a demandé pas mal de patience. Avec du papier de verre, il a poncé l'enveloppe extérieure couche par couche jusqu'à atteindre le cœur du composant.
Et là, surprise : ces vieilles résistances "composition carbone" sont en réalité de petits tubes en verre remplis d'une pâte conductrice à base de carbone, avec deux contacts métalliques aux extrémités. Une construction très différente des résistances modernes, qui consistent en une simple couche de carbone ou de métal déposée sur un substrat.
La cause de la défaillance était finalement assez prosaïque : le contact entre les terminaux métalliques et la pâte carbonée s'est dégradé avec le temps. Pas de cause improbable donc, juste un vieillissement classique d'un composant qui a plus de cinquante ans. Les pâtes carbonées de l'époque vieillissaient mal, surtout quand elles avaient passé leur vie dans un appareil exposé à la chaleur et à l'humidité.
Pour les amateurs de restauration vintage, c'est un rappel utile : si vous tombez sur un comportement bizarre après un recap, ne cherchez pas la panne uniquement dans les composants visiblement endommagés. Une résistance qui a l'air parfaitement saine peut avoir dérivé de plusieurs ordres de grandeur, sans aucun signe extérieur. Le seul vrai test, c'est le multimètre.
Cest aussi l'occasion de découvrir que les composants d'époque étaient construits très différemment de leurs équivalents modernes. C'est plus fragile, moins précis, et clairement moins photogénique. Mais ça fait partie du charme de la restauration : à chaque appareil ouvert, on tombe sur un vestige d'ingénierie qu'on ne reverra plus jamais en production.
Source : Hackaday
BadHost - Un caractère et votre agent IA passe à l'ennemi
Les chercheurs de X41 D-Sec viennent de divulguer une faille critique baptisée BadHost (CVE-2026-48710) dans Starlette, le framework Python qui sert de fondation à FastAPI, vLLM , LiteLLM et une grande partie des serveurs MCP basés sur FastAPI.
325 millions de téléchargements par semaine, et il suffit d'injecter un seul caractère dans le header HTTP "Host" pour contourner les contrôles d'accès path-based qui lisent "request.url.path" dont autant dire que beaucoup de déploiements d'agents IA en production tournent en ce moment avec une porte d'entrée très mal verrouillée.
Le proof of concept publié par OSTIF donne ceci :
curl -i -H 'Host: foo' http://target/admin # 403, bloqué
curl -i -H 'Host: foo?' http://target/admin # 200, ça passe !!
Et c'est tout ! Un simple point d'interrogation collé au Host header, et l'endpoint "/admin" qui jusqu'alors filtrait les non-authentifiés s'ouvre alors aussi facilement que le claque-merde de mes haters ^^.
Donc si votre infra utilise FastAPI, vLLM ou LiteLLM exposés directement en ASGI (uvicorn, hypercorn, granian) sans reverse proxy strict devant, vous pouvez tester votre exposition immédiatement grâce au scanner de BadHost développé par Nemesis et X41 D-Sec.
Niveau mécanique, Starlette reconstruit l'objet "request.url" en concaténant la valeur du header "Host" avec le path de la requête, puis re-parse le tout. Sauf que la valeur de "Host" n'est jamais validée donc si vous y injectez un "/", un "?" ou un "#", vous décalez la frontière entre path, query et fragment au moment du re-parse.
Du coup, le routeur Starlette dispatche sur le vrai path de la requête HTTP (donc votre endpoint sensible s'exécute bien), mais les middlewares lisent "request.url.path" voient simplement un path empoisonné qui ne correspond plus à rien d'interdit.
Donc le contrôle d'accès saute et le code derrière tourne quand même. On est sur un score CVSS de 7/10 et la boite de sécu Secwest estime même que cette note est largement sous-estimée... En gros c'est super grave !
Car la portée réelle ce sont surtout les serveurs MCP qui peuvent stocker ou manipuler des tokens et identifiants pour accéder aux ressources externes auxquelles les agents IA se connectent : bases de données, comptes mail, calendriers, S3, webhooks...etc
Bref, le genre de "coffre-fort" que vous ne voulez pas voir ouvert via un header HTTP à la con malformé. Markus Vervier de X41 D-Sec a même publié un petit échantillon de ce que leurs scanners ont déjà trouvé en production : Des bases de données d'essais cliniques chez des biopharmas, des données de vérification d'identité avec PII en temps réel, des accès SSH à des équipements industriels via bastion, des boites mails complètes en lecture/écriture, des listes de souscripteurs CMS, des topologies AWS complètes avec metric queries.
Bref, l'écosystème agents IA vient de passer en mode naturiste !
Pour régler ce problème, vous devez donc mettre à jour vers Starlette 1.0.1 ou supérieur, dans tous vos déploiements LLM qui l'intègrent... Et là c'est le bordel parce qu'il y en partout : Dans les images Docker, les virtualenvs et les artefacts "vendorisés" un peu partout... Donc faut tout rebuilder.
Et si vous avez du code custom, l'OSTIF recommande aussi de remplacer request.url.path par request.scope["path"] partout où une décision de sécurité est prise.
En gros, lire la valeur non reconstruite est le "fix" qui survivra aux prochaines versions du bug, parce que croyez-moi, ça reviendra à coup sûr !
Maintenant, côté infra, X41 D-Sec et OSTIF indiquent que nginx, Apache httpd et Cloudflare rejettent le PoC par défaut, mais ça ne doit pas vous empêcher de vérifier votre config. Donc ne traitez votre reverse proxy comme une mitigation qu'après l'avoir testé explicitement avec le scanner Nemesis.
Au-delà du correctif technique, BadHost rappelle une mécanique qu'on a déjà vue avec la faille RCE de llama-cpp-python à savoir que la chaîne d'approvisionnement de l'IA ne tient que sur quelques mainteneurs bénévoles qui prennent des risques personnels énormes pour patcher proprement.
Kludex, le mainteneur de Starlette, est actuellement sous une avalanche de reports depuis des mois. L'audit qui a permis de trouver le bug a par ailleurs été financé par OSTIF et AWS et sans ça, BadHost serait encore probablement dans la nature pour un an voire plus avant d'être découvert plus naturellement.
Donc si votre boîte fait tourner du LLM en prod via FastAPI, vLLM ou LiteLLM, vous avez aujourd'hui 2 choses urgentes à faire : 1/ passer votre infra dans le scanner Nemesis, et 2/ envoyer un petit don à Kludex pour le soutenir !
Sources : Ars Technica , OSTIF
"Je capitule" - Matt Mullenweg est abattu
Matt Mullenweg vient de publier un billet anniversaire des 23 ans de WordPress, et ce qui devait ressembler à une célébration tient plus de l'appel au secours. Et j'avoue qu'à lecture, ça m'a mis un petit coup au moral... Parce que oui, le créateur de WordPress est épuisé à cause de 19 mois de guerre juridique...
Côté chiffres pourtant, le post commence très bien. WordPress 7 est sorti la semaine dernière, et en sept jours, 46% des installations sont déjà passées en 7.0 sans aucune casse. Du Raspberry Pi au site de la Maison Blanche, en passant par Korben.info, pas un wp-config.php à éditer à la main, pas un cron à relancer, pas un fichier .htaccess à toucher, TOUT A FONCTIONNÉ !!
Et surtout, aucune attaque supply chain ni faille de sécurité, en tout cas pour le moment. Matt insiste là-dessus et il a raison d'en être fier ! Mais c'est pas vraiment ce qu'on retient de son article...
En effet, ce qu'il explique c'est que la sortie de WordPress 7 n'a pas été ce qu'il espérait parce que trop de temps a été perdu à cause des attaques de WP Engine. Il a, je cite, "des collègues EN TRAIN DE MOURIR" (les majuscules sont dans le texte) qu'il ne peut pas aller voir parce qu'il est noyé sous les procédures. Son meilleur ami attend une greffe de cœur sur un lit d'hôpital pendant que les avocats de Quinn Emanuel l'interrogent sur tout un tas de conneries sans intérêt...
Mais avant, petit rappel pour ceux qui n'auraient pas suivi... depuis septembre 2024, Matt est en guerre ouverte avec WP Engine, un gros hébergeur WordPress propriété de Silver Lake. J'en parlais déjà à l'époque dans WP Engine vs WordPress, la guerre est déclarée . Et en 19 mois, ça n'a pas refroidi du tout... ça s'est même carrément "judiciarisé" à mort.
Silver Lake pèse plus de 100 milliards de dollars (et vient au passage de récupérer TikTok aux États-Unis), et ils ont lâché Quinn Emanuel sur l'affaire. Matt emploie le terme de "shoggoth paperclip-maximizer" pour le qualifier... En gros, ça veut dire que c'est un gars sans émotion qui exécute les ordres de manière littérale jusqu'à l'absurde.
Bref, il s'attaque à Automattic, à lui personnellement, et essaie maintenant carrément de dissoudre la Fondation WordPress qui je le rappelle est à but non lucratif sans aucun employé, et qui finance entre autres les WordCamps et l'éducation open source à travers le monde. C'est le truc qui fait tourner la communauté...
Et de ce qu'on comprend dans ce récit de Matt Mullenweg, c'est que WP Engine essaie de faire passer Matt pour quelqu'un qui détruit des preuves, parce que wordpress.org fait de la rotation de logs (chose que fait absolument tout serveur sur Terre depuis l'invention de syslog en 1980) et parce qu'il utilise les messages éphémères sur Signal avec ses partenaires amoureuses.
Bref, je comprends que le gars soit fatigué par tout ce merdier et cette mauvaise foi. Et puis vient le passage qui fait vraiment mal quand Matt s'adresse directement à Silver Lake : "Vous avez déjà tout dépecé. Si vous vouliez me faire souffrir pour mes péchés, j'ai souffert, et probablement plus profondément que vous ne le saurez jamais. WordPress et WordPress.org, et oui, même mon leadership imparfait, sont au cœur de ce qui a fait le succès de WP Engine jusqu'ici. Vous avez tellement d'argent et de pouvoir, vous venez d'avoir TikTok, l'administration Trump vous adore, vous n'avez pas besoin de contrôler WordPress aussi. Si vous gagnez, vous le détruisez, et après ?"
Puis il termine sur ces mots : "I submit. Let's move on".
Le mec capitule sur le blog officiel... Je dois avouer que j'avais jamais vu ça.
C'est un humain qui craque mais c'est également une fondation à but non lucratif qui risque de disparaître...
Bref, c'est triste pour Matt et clairement pour tout l'écosystème open source derrière. Force à lui et à WordPress !
Un radioamateur décode le signal de la sonde chinoise Tianwen-2 en route vers un astéroïde
Daniel Estévez est ce qu'on appelle un radioamateur de haut vol. Spécialisé dans le décodage de signaux satellites et de sondes spatiales, l'Espagnol partage ses analyses techniques sur son blog depuis plusieurs années.
Cette fois, il s'est attaqué à un gros morceau : la télémétrie de Tianwen-2, la sonde chinoise actuellement en route vers l'astéroïde géocroiseur Kamo'oalewa.
Pour capter le signal, Estévez s'est appuyé sur le radiotélescope de Dwingeloo, aux Pays-Bas. Cette antenne historique, construite en 1956 par les radioastronomes néerlandais et longtemps abandonnée, a été remise en service par une association de passionnés qui l'utilise en particulier pour suivre les missions spatiales lointaines. La sonde émet en bande X (une plage de fréquences radio utilisée par la plupart des engins interplanétaires), autour de 8428,19 MHz, soit pratiquement la même fréquence que sa grande sœur Tianwen-1.
Là où ça devient intéressant techniquement, c'est sur l'encodage du signal. Tianwen-1 utilisait un encodage Reed-Solomon (une méthode classique de correction d'erreurs, indispensable quand le signal voyage sur des centaines de millions de kilomètres) avec une astuce un peu bricolée qui obligeait à zapper certains octets pour faire rentrer le tout dans la trame.
Tianwen-2, elle, utilise un encodage concaténé avec une longueur de trame mieux pensée. Du coup, les codewords Reed-Solomon rentrent pile-poil, sans bidouillage. C'est un détail qui peut sembler insignifiant, mais ça simplifie la vie de tout radioamateur qui veut suivre la mission depuis chez lui.
La sonde a été lancée le 28 mai 2025 et doit atteindre Kamo'oalewa en juin 2026. L'objectif est ambitieux : prélever un échantillon et le ramener sur Terre, comme l'avait fait la mission japonaise Hayabusa2 sur Ryugu en 2020.
Mais Tianwen-2 vise encore plus loin. Après Kamo'oalewa, la sonde poursuivra sa route vers la comète 311P/PANSTARRS pour une étude rapprochée, dans une mission double assez inédite. Si l'opération réussit, ce sera une nouvelle étape importante pour le programme spatial chinois, qui enchaîne les missions depuis plusieurs années.
Estévez documente tout publiquement, avec les paramètres exacts du signal, les outils utilisés (essentiellement GNU Radio, un framework open-source de traitement de signal), et les écueils techniques rencontrés. Pour les passionnés, c'est une mine d'or. Pour les autres, c'est surtout une démonstration que l'observation spatiale n'est plus l'apanage des agences gouvernementales.
Source : Hackaday
BumpMesh - Pour ajouter de la texture à vos impressions 3D
Stefan Hermann, le mec derrière la chaîne YouTube CNC Kitchen , vient de nous pondre un super outil web baptisé BumpMesh qui permet d'ajouter des textures de " displacement " à vos modèles STL, OBJ et 3MF... directement depuis votre navigateur. Vous balancez votre fichier, vous choisissez une texture dans la bibliothèque (ou vous uploadez votre propre image), vous réglez l'amplitude et le mapping, et hop, vous exportez un STL avec une texture de bois ou de béton ou que sais-je encore, prêt à être imprimé.
Avant pour mettre un motif sur une pièce imprimée en 3D, fallait passer forcement par Blender ou un soft de CAO, et surtout comprendre ce concept de displacement map, gérer les UV, bidouiller pendant des heures..etc etc. Et là avec cet outil, c'est juste quelques étapes et basta ! En plus, le code source est sur GitHub sous le nom stlTexturizer.
Côté fonctionnalités, y'a tout ce qu'il faut pour pas se planter. L'outil détecte automatiquement les surfaces planes orientées vers le bas et les laisse lisses (sinon votre pièce décolle du plateau pendant l'impression), et vous pouvez aussi peindre au pinceau les zones que vous voulez garder vierges de toute texture.
Il protège également les parties en surplomb (les fameux overhangs, ces angles déjà casse-pieds à imprimer proprement sans qu'on aille leur coller des reliefs en plus), garde le dessous bien plat avec le "smooth bottom", et propose un mode d'application cylindrique pour enrouler la texture autour des pièces rondes type vase ou tasse sans déformation aux jointures.
Y'a aussi une poignée 3D pour pivoter le modèle dans tous les sens, les raccourcis clavier classiques pour annuler/refaire, une sauvegarde de projet au format .bumpmesh, et une fonction "Bake Textures" en bêta qui fige la texture actuelle sur le maillage pour que vous puissiez en empiler une deuxième par-dessus.
L'interface est dispo en français mais aussi en italien, espagnol, portugais, japonais, coréen sans oublier l'anglais évidemment...
Bref, pour ajouter une texture peau de banane sur un vase, des écailles sur une figurine, du motif hexagonal sur une coque, c'est top moumoute ! Et en plus c'est gratuit !
À tester sur bumpmesh.com .
Merci à B0t_Ox pour la découverte !
Taphouse - La GUI Homebrew avec scanner CVE intégré
Multimodal Solutions, une boîte grecque, vient de sortir Taphouse 1.5 qui est une GUI native macOS pour Homebrew. GUI c'est pas que le nom de votre collègue qui fout rien, c'est surtout un acronyme qui veut dire Graphic User Interface (Interface Graphique !). Et pour Homebrew, bah c'était pas du luxe.
Parce que Homebrew, c'est le standard chez les développeurs Mac, mais tout passe par le terminal. Faut taper brew install, gérer les services, fouiller l'arbre de dépendances en CLI (Command Line Interface), et c'est pas le pied quand on veut juste installer Firefox et passer à autre chose dans sa vie !
Des interfaces graphiques pour Homebrew, y'en a déjà quelques-unes (par exemple Cakebrew, Applite, Cork, WailBrew) sauf que Taphouse arrive avec 2 trucs qu'on voit rarement ailleurs : un scanner CVE intégré et un détecteur d'apps Intel qui tournent encore sous Rosetta.
Le scanner CVE, fait qu'à chaque installation, Taphouse compare la version de chaque package avec les feeds de vulnérabilités, avec des codes couleur selon la sévérité, et linke directement vers la base NVD et les rapports fournisseur.
Ainsi, quand une nouvelle CVE tombe, ça rescan en arrière-plan comme ça, sur des dépendances qu'on oublie de mettre à jour pendant des mois, y a de quoi repérer les vulnérabilités connues avant qu'elles posent un vrai problème côté sécurité.
L'autre feature pas mal, c'est donc la détection des apps Intel qui tournent encore sous Rosetta. Si vous êtes passé d'un Intel à un Mac M* , vous avez sûrement traîné des binaires Intel dans /Applications sans même vous en rendre compte. Taphouse scanne le dossier, repère les x86_64 et, quand un cask compatible existe, il vous propose la version Apple Silicon native via Homebrew. J'ai testé sur mon install et, ça m'a remonté tous mes binaires Intel oubliés comme ça j'ai pu faire un peu de ménage.
Dans sa version gratuit, vous avez le droit à +14 000 formules et casks, l'installation en un clic, la gestion des services Homebrew (start, stop, restart), le nettoyage de l'espace disque, l'aperçu des dépendances, et un gestionnaire de quarantaine Gatekeeper. Y'a aussi de quoi repousser une mise à jour pour 1 jour, 1 semaine ou 1 mois quand on n'a pas envie de se taper un brew upgrade en plein rush de boulot.
Pour les power-users, la version pro débloque la migration Apple Silicon assistée, l'aperçu des release notes GitHub en direct dans l'app, et un tableau de bord "santé du système" avec un score global. Je ne sais pas si ça vous sera utile mais ça coute moins de 10 balles pour une licence à vie, ce qui se fait de plus en plus rare maintenant.
Notez que Taphouse n'est pas open source malgré le repo GitHub qui n'héberge que les rapports de bug. Maintenant entre une app gratuite et Taphouse Pro à 9,99 €, ça dépend de ce que vous cherchez. Applite couvre 80% du besoin si vous n'installez que des casks (pas les formules), et de son côté, Cork est open-source et gratuit mais le binaire pré-compilé est payant.
Y'a aussi Cakebrew qui est encore dispo mais le projet ne semble plus maintenu. Ce qui est surtout cool avec Taphouse c'est le CVE scanning et cette migration Apple Silicon assistée dont je vous parlais.
Si vous voulez l'installer, ça peut se faire via Homebrew lui-même avec brew install --cask taphouse. Sinon, téléchargement direct sur le
site officiel
.
Bref, si vous gérez votre Mac avec Homebrew et que vous en avez marre du terminal, Taphouse mérite un petit coup d'œil.
Le Canada coupe sa station radio horaire CHU après plus d'un siècle de service
Le 22 juin prochain, le Canada va éteindre une voix qui parle sans interruption depuis 1923. La station CHU, opérée par le Conseil national de recherches (l'équivalent canadien du CNRS), cessera ses émissions sur ondes courtes après plus de cent ans de bons et loyaux services.
Trois fréquences disparaîtront du spectre radio : 3330, 7850 et 14670 kHz. C'est la fin d'une époque.
Pour ceux qui n'auraient jamais croisé son signal, CHU diffusait en continu l'heure officielle canadienne, calée sur une horloge atomique du CNRC. Le principe est très simple : un émetteur balance des "tops" précis à la milliseconde, et n'importe quel récepteur radio peut s'y synchroniser.
La station alternait code morse, voix synthétique (en français et en anglais, tradition oblige), impulsions courtes appelées DUT1 pour les horloges radio domestiques, et un code numérique FSK pour les équipements plus modernes. C'était un peu l'horloge mère qui réglait tous les chronomètres du pays.
CHU est née en 1923 sous l'indicatif 9CC, puis VE9OB, avant de prendre son nom définitif en 1938. Elle faisait partie d'une petite famille de stations horaires qui existe encore aujourd'hui avec WWV et WWVB côté américain, DCF77 en Allemagne et MSF au Royaume-Uni. Si vous avez un réveil "atomique" acheté en Europe, il se cale en fait sur DCF77, près de Francfort. Les Canadiens, eux, écoutaient CHU.
Alors pourquoi débrancher la prise maintenant ? Le CNRC explique que l'heure officielle est désormais distribuée par d'autres canaux : NTP (Network Time Protocol, le système qui met automatiquement vos ordinateurs à l'heure via internet), GPS pour les équipements embarqués, et même une horloge parlante téléphonique toujours active.
La diffusion sur ondes courtes coûte cher à entretenir, et son public se résume aux derniers radioamateurs, à quelques marins équipés à l'ancienne et aux passionnés.
C'est la deuxième fois en peu de temps que le Canada coupe un signal horaire emblématique. La CBC avait déjà arrêté en 2023 son fameux "long dash", ce bip long de fin de journal qui rythmait la radio canadienne depuis 1939.
À chaque coupure, le même argument : tout est passé sur internet, à quoi bon maintenir la bande HF ? Le souci, c'est que si les serveurs NTP ou le réseau électrique flanchent, plus personne n'a de plan B sérieux pour savoir vraiment quelle heure il est. Les ondes courtes, elles, traversent les continents avec un simple émetteur et un récepteur à pile.
Bref, encore un bout d'infrastructure analogique qui s'efface au profit du tout-IP. Dommage.
Source : SWLing