Homebrew 6.0.0 renforce la sécurité des taps et déploie le sandboxing Linux. Zcash Orchard : une vulnérabilité de 4 ans découverte par IA, impossible à savoir si exploitée. Let’s Encrypt, trop seul au monde ?
Freebox 4.11.1 déploie le DNS local .home après 15 ans d’attente, zeropod v0.12.0 corrige les probes K8s, et les outils auto-hébergés Keeper, Euro-Office passent au crible.
En bref # Instructure (Canvas) rançonnée : ShinyHunters revendique 3.65 To de données, rançon payée. Exchange Server zero-day (CVE-2026-42897) : XSS dans OWA, pas de patch, exploitation active. BitLocker YellowKey (CVE-2026-45585) : contournement du chiffrement disque avec accès physique. Gitea/Forgejo (CVE-2026-27771) : 30 000+ instances exposent leurs images privées depuis 4 ans. Verizon DBIR 2026 : 48 % des brèches impliquent un tiers, +60 % sur un an. Chrome 148 : 2 correctifs critiques sur Linux (WebRTC UAF, UI spoofing).
Le 19 mars 2026, un groupe identifié comme TeamPCP a publié une version malveillante de Trivy, le scanner de vulnérabilités le plus utilisé du monde conteneurisé.
L’attaque est exemplaire dans sa mécanique.
TeamPCP a compromis le compte aqua-bot qui gère les releases de Trivy. Avec ce token, ils ont poussé un commit qui remplaçait actions/checkout par un fork malveillant, téléchargeant du code depuis un domaine typosquatté. Le flag --skip=validate de goreleaser était activé pour contourner la validation.
En quelques minutes, 76 des 77 tags de version de trivy-action étaient force-pushés vers des commits infectés. Les 7 tags de setup-trivy étaient tous remplacés.
Le payload était un credential stealer : dump de la mémoire du runner GitHub via /proc/<pid>/mem, sweep de 50+ chemins pour SSH keys, tokens AWS/GCP/Azure, secrets Kubernetes, Docker configs, fichiers .env, identifiants de base de données, wallets crypto. Les données étaient chiffrées en AES-256-CBC avec RSA-4096 et exfiltrées vers un serveur C2.
Trois jours plus tard, des images Docker Hub v0.69.5 et v0.69.6 arrivaient avec le même payload. Et un ver npm, CanisterWorm, se propageait via le paquet containers-check.
Aqua Security a détecté l’intrusion initiale fin février 2026 et avait rotationné des credentials. Mais la rotation n’était pas atomique. TeamPCP a gardé un accès résiduel via des tokens non révoqués.
Le plus frappant n’est pas la sophistication. C’est la banalité du point d’entrée : un token CI mal rotationné. Et la confiance qu’on accorde à un outil qui est censé améliorer la sécurité.
En bref # Proxmox VE 9.2 avec Load Balancer natif, SDN BGP/WireGuard, et Debian 13. Microsoft Azure Linux 4.0 : leur première distro grand public, immutable, orientée AI/K8s. Plex Lifetime à 750 $ le 1er juillet. Oui, vous avez bien lu. 3 800 repos GitHub compromis par une extension VS Code malveillante installée par un employé. Jellyfin profite de la panique Plex en « quadruplant » son prix (4 × 0 $ = 0 $).
La cryptographie post-quantique n’est pas de la science-fiction. L’attaque Harvest Now, Decrypt Later invite à préparer les usages crypto dès maintenant. Guide pratique pour auditer les usages, prioriser les risques et préparer une migration progressive vers l’hybridation.
La CVE-2026-42945, surnommée Nginx RIFT, touche le module ngx_http_rewrite_module de Nginx, un composant historique introduit en 2008.
Selon les chercheurs à l’origine de la découverte, la vulnérabilité peut mener, dans certaines conditions, à une corruption mémoire exploitable pouvant aller jusqu’à une exécution de code arbitraire (RCE). Un PoC public est déjà disponible, ce qui réduit rapidement le coût d’entrée pour tester l’exploitation.
Debian 14, nom de code Forky, est la future version stable de Debian. Au 14 mai 2026, elle est encore en branche testing. Aucune date de sortie n’est annoncée, et les étapes du freeze ne sont pas encore planifiées publiquement.
Le bulletin de l’équipe Release publié le 10 mai 2026 apporte tout de même plusieurs informations importantes : les builds reproductibles deviennent une contrainte plus forte dans la migration des paquets, les binNMU passent par davantage de tests automatiques, et l’architecture loong64 arrive dans l’archive Debian.
Pour un serveur de production, la conclusion immédiate est simple : Debian 13 Trixie reste la version stable à utiliser. Debian 14 est intéressante à tester dès maintenant, mais pas à déployer comme base principale tant qu’elle n’est pas publiée en stable.
Dans le premier article sur Pangolin, j’avais volontairement laissé CrowdSec de côté.
Pas parce que CrowdSec n’est pas utile. Au contraire. Mais parce qu’une pile Pangolin doit d’abord être comprise avant d’ajouter des briques de sécurité, des bouncers, des dashboards et des automatisations. Une fois Pangolin stable, la question revient naturellement :
Comment visualiser proprement ce que CrowdSec voit et bloque, sans exposer une interface d’administration sensible sur Internet ?
C’est là que CrowdSec Manager devient intéressant.
L’objectif de ce test est simple :
installer CrowdSec Manager à côté de la stack CrowdSec ; ne pas publier son port 8080 sur Internet ; le rendre accessible uniquement via Pangolin ; protéger l’accès avec le SSO Pangolin ; garder les secrets Newt dans Gitea Actions, pas dans Git.
Ubuntu 26.04 LTS est sortie le 23 avril 2026 sous le nom Resolute Raccoon.
Pour un poste desktop, c’est une nouvelle LTS avec GNOME 50, Wayland et quelques changements visibles. Pour un serveur, c’est autre chose : une base qui peut rester en production pendant plusieurs années, avec un nouveau noyau, une pile crypto plus stricte, des paquets serveur mis à jour, des changements de comportement sur des services courants, et une stratégie de support à bien comprendre avant de lancer un do-release-upgrade.
Je regarde donc Ubuntu 26.04 LTS sous l’angle qui m’intéresse le plus ici : serveurs, VPS, homelab, cloud, sécurité et migration propre.
Dirty Frag est une nouvelle faille Linux publiee le 7 mai 2026 par le chercheur Hyunwoo Kim, aussi connu sous le pseudo @v4bel.
Petite correction avant de commencer : le nom est Dirty Frag, pas Dirty Flag. Le “frag” fait reference aux fragments de paquets reseau dans le noyau Linux, plus precisement au champ frag de struct sk_buff.
Sur le papier, Dirty Frag est une elevation locale de privileges. En clair : il faut deja pouvoir executer du code sur la machine. Mais une fois ce premier acces obtenu, la faille peut permettre de devenir root.
C’est exactement le genre de bug qui compte beaucoup sur des serveurs multi-utilisateurs, des environnements CI/CD, des machines de developpement, des VPS, des clusters Kubernetes ou des plateformes qui lancent du code tiers.
L’open source est redevenu bruyant. Très bruyant.
Entre les agents IA, les scanners de vulnérabilités, les outils anti-crawlers, les dashboards de monitoring et les apps self-hosted, on peut remplir un serveur en une soirée et le regretter pendant six mois. Le vrai travail n’est plus de trouver des projets. Le vrai travail, c’est de trier. Je mets beaucoup trop d’étoiles sur GitHub. Pas parce que je compte tout installer. Ce serait le meilleur moyen de transformer un homelab en brocante numérique impossible à maintenir. Mais parce qu’une étoile GitHub, bien utilisée, est un marque-page technique. Elle dit : “ce projet répond peut-être à un problème que j’ai déjà rencontré, ou à un problème que je vais rencontrer bientôt”
Dans un homelab, le plus dur n’est pas d’installer un projet open source. C’est de savoir s’il mérite encore d’être là dans six mois. C’est exactement pour ça que je garde une veille GitHub : pas pour tout déployer, mais pour repérer les signaux faibles.
Cette sélection part donc de mes 30 stars GitHub publiques les plus récentes, récupérées depuis mon profil GitHub foudreclair et plus précisément depuis mes stars publiques. Je ne les présente pas comme un classement, ni comme une recommandation de production. Et surtout, je ne les ai pas tous testés. C’est une photographie de veille : ce qui a attiré mon attention à un moment donné, et ce que ces projets racontent de mes sujets actuels.
On y retrouve des thèmes nets : IA, sécurité, infra légère, self-hosting, dev tools, Fediverse, publication web et données personnelles. Ce qui m’intéresse, ce n’est pas la hype. C’est ce que ces projets disent des problèmes que les admins, devs et self-hosters essaient vraiment de résoudre aujourd’hui.
Cet article s’adresse surtout aux personnes qui maintiennent un homelab, un petit VPS, un site statique, ou une veille technique personnelle. Anubis m’intéresse particulièrement dans ce contexte, parce qu’il répond à un problème récent et très concret : les petits sites qui subissent le trafic de crawlers automatisés. Je ne l’ai pas encore testé ; je veux justement le faire proprement avec Pangolin, puis en tirer un article dédié sur le duo Pangolin + Anubis.
Cette liste est datée : 21 avril 2026. Elle correspond aux 30 dépôts publics les plus récemment étoilés sur mon profil GitHub au moment de la rédaction. Si je change mes stars, l’ordre public sur GitHub peut évoluer, et c’est normal. L’objectif n’est pas de figer un classement, mais de documenter une veille à un instant donné.
Quand la contrainte devient un sport # Dans un monde où le cloud facture le moindre CPU burst, il existe un écosystème parallèle : des VPS à 12 $ par an, parfois moins, avec 1 GB de RAM, aucun SLA… et pourtant des services qui tiennent.
Ce monde n’est pas tenu par des débutants, mais par une communauté de passionnés de l’optimisation extrême, prêts à faire tourner des services utiles avec presque rien.
Pour moins de 12 $ par an, j’exploite un VPS low-end, un nom de domaine dédié et un service de monitoring public. Cet article n’est pas un comparatif marketing. C’est un retour d’expérience sur ce que ces infrastructures permettent et surtout sur ce qu’elles ne permettent pas.
Bienvenue dans l’univers Low-End VPS.
Quand on démarre avec Hugo, tout paraît simple :
un thème, quelques articles, un hugo build, et le site est en ligne.
Mais très vite, une vraie question arrive en production :
Comment mettre à jour un thème Hugo sans risquer de casser son site ?
C’est un sujet étonnamment peu documenté.
Voici donc mon setup réel, utilisé en production, et surtout pourquoi je l’ai conçu comme ça.
Mettre à jour un thème Hugo en production est rarement documenté, surtout lorsqu’on utilise git submodules et une CI/CD auto-hébergée.
Quand on lance un projet, blog, side-project, service auto-hébergé ou simple test technique - il y a toujours un moment où la question tombe :
On met quoi comme nom de domaine ?
Par réflexe, on pense immédiatement à .fr ou .com, avec un prix annuel autour de 10 à 15 €.
Ce n’est pas absurde, mais ce n’est pas toujours nécessaire, surtout quand on est encore en phase de test.
Bonne nouvelle : oui, il est possible d’avoir un nom de domaine pour moins d’un euro.
Et non, ce n’est ni une arnaque, ni un hack douteux réservé à des coupons obscurs.
Dernière découverte Fediverse de cette fin d’année.
Je publie ce billet le 31 décembre, avant de passer à 2026.
PieFed a été un vrai coup de cœur : un forum fédéré moderne, lisible et maîtrisable.
En travaillant sur cryptolab.re, j’ai voulu mesurer concrètement les performances du site côté utilisateur.
J’ai donc lancé une analyse via Google PageSpeed Insights.
Résultat : score de 50 sur mobile.
J’ai monté Cryptolab pour une raison simple :
j’en avais marre de bidouiller dans le vide.
Comme beaucoup de gens qui aiment l’infrastructure, le réseau ou le self-hosting, j’ai accumulé les tests, les VPS inutiles, les configs overkill, les idées lancées un soir et abandonnées deux semaines plus tard.
Tout ça existe quelque part dans des notes, des commits oubliés, des terminaux fermés trop vite.
