Weekly #26 : Coldcard, Proxmox ARM64, ChainDrop, Home Assistant et FFmpeg

Cette semaine, deux sujets demandent une action rapide : les seeds générées par plusieurs versions de firmware Coldcard doivent être remplacées, et les équipes JavaScript doivent vérifier leur exposition à ChainDrop. Le reste est moins urgent, mais intéressant pour l’exploitation d’un homelab : Proxmox VE arrive officiellement sur ARM64, Home Assistant simplifie sa configuration réseau et FFmpeg publie une nouvelle version majeure.

Le point commun est assez classique. Une version ou une architecture annoncée comme supportée ne suffit pas à garantir une migration simple. Il faut regarder les limites matérielles, les secrets déjà créés, les dépendances réellement installées et les chemins de retour arrière.

Coldcard : mettre à jour ne suffit pas, il faut remplacer la seed

#

Coinkite a publié un avis de sécurité concernant l’entropie utilisée pour générer les seeds de plusieurs générations de Coldcard.

Le problème vient d’une intégration réalisée en 2021. La génération de seed est passée de ckcc.rng_bytes() à ngu.random.bytes(), mais la résolution des symboles a sélectionné un générateur logiciel de secours fourni par MicroPython au lieu du générateur matériel attendu. Le bon code était présent dans le firmware, sans être celui effectivement appelé par ce chemin.

Selon l’analyse actuelle de Coinkite, l’espace de recherche effectif était d’environ :

• 40 bits sur les Mk2 et Mk3 concernés ;
• 72 bits sur les Mk4, Mk5 et Q concernés, grâce à de l’entropie supplémentaire issue des secure elements ;
• 128 bits attendus en fonctionnement normal.

Les versions concernées sont précisément documentées :

• Mk2 et Mk3 : versions 4.0.1 à 4.1.9 incluses ;
• Mk4 et Mk5 standard : seeds générées avant la 5.6.0 ;
• Q standard : seeds générées avant la 1.5.0Q ;
• Mk4 et Mk5 Edge : seeds générées avant la 6.6.0X ;
• Q Edge : seeds générées avant la 6.6.0QX.

TAPSIGNER, OPENDIME et SATSCARD ne sont pas concernés, car ils utilisent d’autres bases de code.

Le point opérationnel le plus important est le suivant : la mise à jour du firmware ne répare pas une seed existante. Elle corrige uniquement la génération des prochaines seeds.

Pour un wallet concerné, l’ordre raisonnable est :

1. installer la version corrigée correspondant exactement au modèle et à la branche standard ou Edge ;
2. générer une nouvelle seed sur le firmware corrigé ;
3. vérifier la sauvegarde, l’empreinte du wallet et une adresse de réception sur l’écran du Coldcard ;
4. envoyer une petite transaction de test ;
5. déplacer le solde restant après confirmation ;
6. conserver l’ancienne sauvegarde jusqu’à la confirmation complète de la migration.

Coinkite indique qu’au moins 50 lancers de dés privés, indépendants et correctement saisis lors de la création apportent à eux seuls 128 bits d’entropie. Une passphrase BIP-39 forte et unique ajoute aussi une barrière indépendante. En cas de doute sur le nombre de lancers ou la qualité de la passphrase, il faut considérer la seed comme concernée. Même avec une bonne passphrase, le constructeur recommande une migration.

Ce n’est pas un scénario où il faut improviser dans l’urgence avec une seed copiée dans un navigateur ou un outil en ligne. Préparez la migration hors ligne, vérifiez chaque empreinte et commencez par une petite transaction.

Avis de sécurité Coldcard
Analyse technique de l’entropie

ChainDrop : 444 paquets npm, 1 381 versions et plusieurs chemins de propagation

#

La veille FreshRSS a beaucoup remonté ChainDrop avec des titres parlant de plus de 1 300 paquets contaminés. La source primaire d’Aikido donne une mesure plus précise au 5 août : au moins 444 paquets, répartis sur 1 381 versions compromises, pour plus de deux milliards d’installations mensuelles cumulées.

La distinction entre paquets et versions compte. Elle ne réduit pas le risque, mais évite de gonfler artificiellement le nombre de projets touchés.

L’incident initial passe par le compte GitHub compromis d’un mainteneur de Keyv. Le malware a ensuite utilisé plusieurs mécanismes :

• ajout d’un script preinstall qui exécute setup.mjs ;
• vol de tokens npm, GitHub, AWS et de secrets Kubernetes ;
• republication de nouvelles versions contaminées avec les droits npm récupérés ;
• commits dans des dépôts accessibles avec un token GitHub Actions ;
• ajout de hooks dans .claude/settings.json et .vscode/tasks.json ;
• exécution ultérieure à l’ouverture du dépôt dans VS Code ou au lancement de Claude Code.

Les commits observés utilisent notamment l’auteur claude, l’adresse claude@users.noreply.github.com et le message chore: update config. Ce sont des indicateurs, pas des preuves suffisantes à eux seuls.

Quelques contrôles en lecture seule :

find . -type f \( -name setup.mjs -o -name Math_Symbol.js -o -name math_init.js \) -print

rg -n '"preinstall"[[:space:]]*:[[:space:]]*"node setup\.mjs"' .

git log --all --format='%h %ad %an <%ae> %s' --date=iso -- \
  .claude/settings.json .vscode/tasks.json
git log --all --grep='chore: update config'

Aikido publie aussi les empreintes SHA-256 des fichiers et les indicateurs réseau. Il faut les intégrer au contrôle des postes développeurs et runners CI, pas seulement scanner le dépôt courant.

Si un environnement a exécuté une version compromise, supprimer le paquet et relancer npm install n’est pas une réponse suffisante. Il faut traiter le poste ou le runner comme compromis : l’isoler, préserver les éléments utiles à l’analyse, révoquer les tokens depuis une machine saine, faire tourner les secrets cloud et Kubernetes accessibles, puis reconstruire l’environnement.

L’attaque rappelle aussi une limite de npm audit : un paquet malveillant récemment publié n’est pas nécessairement couvert immédiatement comme une vulnérabilité classique. Il faut croiser le lockfile, les listes de versions touchées et les IOC.

Analyse ChainDrop et indicateurs d’Aikido

Proxmox VE 9.2 : ARM64 devient une architecture officiellement supportée

#

Proxmox VE est désormais disponible officiellement sur ARM64. Ce n’est pas une simple image communautaire ni une préversion technique : Proxmox annonce le même code source, les mêmes dépôts et le même cycle de publication que pour x86-64.

La version ARM64 de Proxmox VE 9.2 repose notamment sur :

• Debian 13.5 Trixie ;
• Linux 7.0 par défaut ;
• QEMU 11.0 ;
• LXC 7.0 ;
• ZFS 2.4.

Le support matériel reste cependant très ciblé.

Les plateformes NVIDIA Grace Hopper et NVIDIA Vera sont pleinement supportées. Les autres serveurs ARM doivent démarrer en UEFI et décrire leur matériel via ACPI. Proxmox annonce un support best effort pour ARMv9-A, et indique qu’ARMv8-A fonctionne généralement dans les mêmes conditions.

Le Raspberry Pi et les autres cartes qui reposent uniquement sur un device tree ne sont pas supportés. L’annonce ne transforme donc pas un Raspberry Pi 5 en petit nœud Proxmox officiel.

Contrôles utiles sur une machine candidate :

dpkg --print-architecture
test -d /sys/firmware/efi && echo "UEFI détecté" || echo "Pas de démarrage UEFI"
test -d /sys/firmware/acpi/tables && echo "Tables ACPI présentes" || echo "ACPI non détecté"

Sur un hôte Proxmox installé :

pveversion -v

Il faut aussi garder en tête les limites de cluster :

• les VM utilisent toujours UEFI sur ARM64 ;
• un invité ne s’exécute que sur un nœud de la même architecture ;
• la migration à chaud ne fonctionne qu’entre nœuds de même architecture ;
• un cluster mixte x86-64 et ARM64 n’est pas officiellement supporté, même si sa création n’est pas bloquée techniquement.

Les données d’un invité x86 peuvent être déplacées hors ligne vers un nœud ARM, mais le système invité doit ensuite être réinstallé ou reconfiguré pour la nouvelle architecture. Pour un cluster x86 existant, il n’y a donc aucune raison de migrer par principe. L’intérêt immédiat concerne surtout les serveurs ARM déjà disponibles et les charges adaptées à cette architecture.

Annonce officielle Proxmox VE pour ARM64

Home Assistant 2026.8 : le port 80 concerne uniquement les nouvelles installations OS

#

Home Assistant 2026.8 fait disparaître :8123 de l’adresse par défaut, mais seulement pour les nouvelles installations de Home Assistant OS.

Une installation existante conserve son port actuel. Il n’y a rien à migrer automatiquement et aucun reverse proxy à reconfigurer simplement parce que la version 2026.8 est installée.

La configuration du serveur web devient accessible depuis l’interface. Elle permet de modifier :

• le port d’écoute ;
• l’interface réseau utilisée ;
• les proxies de confiance.

Home Assistant applique la nouvelle configuration puis attend une confirmation. Si elle n’arrive pas dans les cinq minutes, les anciens paramètres sont restaurés et le service redémarre. C’est une protection utile contre une mauvaise adresse d’écoute ou un port déjà occupé.

Changer le port reste une modification d’infrastructure. Il faut ensuite vérifier les favoris, l’application mobile, les webhooks, le reverse proxy et les services qui appellent directement Home Assistant. Si l’installation actuelle fonctionne sur 8123 derrière un proxy, la laisser en place reste souvent le choix le plus simple.

La release apporte aussi :

• le renommage plus souple des identifiants d’entités ;
• la séparation automatique des appareils qui avaient été fusionnés entre plusieurs intégrations ;
• de nouveaux déclencheurs et conditions dans l’interface ;
• des templates numériques annoncés jusqu’à 40 % plus rapides ;
• une gestion plus complète des identifiants de serrures dans Z-Wave JS 1.6.0 ;
• une indication quand une mise à jour Home Assistant OS nécessite un redémarrage.

La 2026.8.1 est déjà disponible avec les premiers correctifs. Avant mise à jour, la lecture des changements incompatibles reste utile, notamment si des automatisations dépendent des anciennes valeurs textuelles de certains capteurs.

Home Assistant 2026.8

FFmpeg 9.0 : Vulkan, nouveaux accélérateurs et nettoyage de compatibilité

#

FFmpeg 9.0, nommée « Lei », arrive environ quatre mois après la 8.1.

La liste des changements continue de pousser le traitement matériel :

• nouveau filtre v360_vulkan ;
• accélération Vulkan pour APV ;
• accélération ProRes RAW via VideoToolbox ;
• filtre transpose_cuda ;
• conversion HDR étendue dans vf_vpp_amf ;
• nouveau convertisseur de fréquence d’images vf_frc_amf ;
• backend DNN ONNX Runtime avec prise en charge des fournisseurs d’exécution GPU.

La version ajoute également le décodage WebP animé, le décodage HE-AAC 960 utilisé par DAB+, le muxing de pistes LCEVC dans MP4 et la gestion des métadonnées SMPTE 2094-50.

Deux retraits méritent une vérification avant de remplacer une version packagée :

• le décodage CELT historique et le parsing Ogg/CELT sont supprimés, sans impact sur CELT à l’intérieur d’Opus ;
• les options NVENC dépréciées et les SDK antérieurs à la version 11.1 ne sont plus supportés.

Pour connaître la version réellement utilisée :

ffmpeg -version

Et vérifier les filtres présents dans un build donné :

ffmpeg -filters 2>/dev/null | rg 'v360_vulkan|transpose_cuda|frc_amf|vpp_amf'

Sur Jellyfin, Immich ou un autre service qui embarque son propre build, je n’irais pas remplacer FFmpeg à la main dans le conteneur. Il vaut mieux attendre l’image applicative prévue pour cette version, puis tester les transcodages réellement utilisés : codecs, sous-titres, HDR, accélération GPU et lecture sur les clients habituels.

Notes de publication FFmpeg 9.0
Changelog FFmpeg 9.0

Signaux de veille cette semaine

#

Tailscale revient sur l’intrusion de Hugging Face. Aucune vulnérabilité Tailscale n’a été exploitée. L’agent avait déjà obtenu un accès root à un nœud Kubernetes et lu un coffre contenant 136 secrets. Une clé d’authentification Tailscale réutilisable lui a ensuite permis d’enrôler 181 nœuds externes dans le tailnet avec les droits du tag CI. La réponse opérationnelle est claire : préférer la workload identity federation aux clés réutilisables, lier les clés de nœud au TPM quand le contexte le permet, et activer les flow logs avec des alertes exploitables.

Uptime Kuma 2.5.0 ajoute un moniteur NTP et une image rootless. La release apporte aussi plusieurs fournisseurs de notification et des correctifs autour de DNS, MQTT, Kafka, des captures navigateur et des pages de statut. Le nouveau tag Docker next-rootless mérite d’être testé avant de modifier un déploiement existant : son nom indique encore une voie d’adoption progressive, pas nécessairement le nouveau défaut stable.

Fedora 45 prépare l’activation de Shadow Stack sur x86-64. Il s’agit encore d’une proposition de changement, pas d’un comportement définitivement adopté. Le mécanisme protège les adresses de retour contre des chaînes ROP sur le matériel compatible. La protection ne s’active que si le binaire et toutes ses bibliothèques portent les métadonnées attendues. Un objet partagé non compatible chargé au démarrage désactive silencieusement la protection, tandis qu’un dlopen tardif peut échouer.

openmediavault 8.5.6 complète la maintenance des ensembles MD. Avec le plugin openmediavault-md 8.1.5, l’interface ajoute des actions de vérification et de réparation pour les niveaux RAID redondants. Ce sont des opérations qui sollicitent fortement les disques : vérifier l’état SMART, les sauvegardes et la charge avant de lancer une opération de maintenance reste nécessaire.

Tailscale - retour sur l’intrusion Hugging Face
Uptime Kuma 2.5.0
Fedora 45 - proposition Shadow Stack
openmediavault - mises à jour MD

Les pépites de la semaine

#

Hermex est un client iPhone natif pour piloter un serveur hermes-webui auto-hébergé. Il donne accès au chat, aux sessions, aux tâches planifiées, aux skills, aux modèles et à l’espace de travail sans relais tiers annoncé. Le serveur reste à déployer et sécuriser soi-même. Le projet prévient aussi que l’API amont n’est pas encore stable, donc un décalage de version peut casser certaines fonctions.

ReadMeABook automatise les demandes, le téléchargement et la préparation d’audiobooks pour Plex ou Audiobookshelf, avec intégration Prowlarr, fusion en M4B et sidecars ebook optionnels. Le déploiement unifié tient dans un conteneur, mais l’accès aux contenus reste évidemment soumis aux sources configurées et au droit applicable.

celld propose une implémentation auto-hébergeable et distribuée des Durable Objects. Chaque objet possède sa base SQLite, répliquée dans un stockage compatible S3, sans control plane ni service de consensus séparé. Le projet est encore très jeune. Le port entre pairs ne termine pas TLS et doit rester sur un réseau privé ou un overlay chiffré comme WireGuard ou Tailscale.

Hermex
ReadMeABook
celld

Commande du jour

#

cd -

Dans un shell compatible POSIX, cd - revient au répertoire précédent et affiche son chemin.

Exemple :

cd /etc/nginx
cd /var/log/nginx
cd -

La dernière commande ramène dans /etc/nginx. Une nouvelle exécution permet de revenir dans /var/log/nginx.

C’est utile pendant un diagnostic quand on alterne entre une configuration et ses logs, sans recopier deux chemins longs ni dépendre de l’historique du terminal.

Sources

#

• Coldcard - avis de sécurité
• Coldcard - analyse technique de l’entropie
• Coldcard firmware - Security Advisory
• Aikido - Keyv and friends compromised in npm supply chain attack
• Proxmox VE - support officiel ARM64
• Home Assistant 2026.8
• FFmpeg 9.0 - Release Notes
• FFmpeg 9.0 - Changelog
• Tailscale - Tailscale didn’t stop the Hugging Face intrusion
• Uptime Kuma 2.5.0
• Fedora 45 - Enable Shadow Stack by Default on x86_64
• openmediavault - New updates available
• Hermex
• ReadMeABook
• celld