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 ?
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é.
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.
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.
