L’auteur explique pourquoi une nouvelle YubiKey 5C ne pouvait plus déverrouiller sa base KeePassXC, alors qu’il utilisait auparavant une YubiKey configurée avec le même secret HMAC-SHA1. Le problème vient de la méthode de provisionnement : les anciens outils (YubiKey Personalization Tools) utilisaient des options avancées non documentées, tandis que les outils récents (ykman) standardisent le processus, générant des réponses différentes pour un même secret.

Il souligne la dépendance implicite au logiciel initial, désormais obsolète, qui pourrait devenir difficile à utiliser à l’avenir. Yubico a en effet abandonné ses outils graphiques au profit de ykman, rendant la compatibilité rétroactive problématique. L’auteur recommande de reprogrammer les clés avec ykman et de mettre à jour le challenge-response dans KeePassXC, tout en sauvegardant un accès alternatif à la base avant toute manipulation.

Enfin, il détaille brièvement la procédure pour recréer le challenge HMAC-SHA1 dans KeePassXC via les options de sécurité, en utilisant la ligne de commande (ykman) pour configurer le slot 2 de la YubiKey. Une migration proactive évitera des difficultés futures lors du remplacement d’une clé.

Les fuites massives de données permettent aux escrocs de personnaliser leurs spams avec des informations précises (adresse, numéro de sécurité sociale, etc.), rendant les arnaques plus crédibles. Ils ciblent désormais des victimes spécifiques plutôt que d’envoyer des messages génériques, augmentant ainsi l’efficacité de leurs tentatives de fraude.

Pour éviter de tomber dans le piège, il est crucial de vérifier l’expéditeur des e-mails. Une adresse frauduleuse peut imiter une entreprise légitime (ex. : vinci-autoroute.com au lieu de vinci-autoroutes.com), ou utiliser un domaine inattendu (ex. : .fi pour une entreprise française). Même les détails subtils, comme une lettre modifiée (rnicrosoft.com au lieu de microsoft.com), doivent être examinés.

Enfin, la règle d’or reste de ne jamais cliquer sur les liens contenus dans un e-mail suspect. Un simple clic peut confirmer à l’escroc que l’adresse est active, même sans interaction supplémentaire. La prudence et la vérification systématique des sources sont essentielles pour se protéger.

La faille IDOR (Insecure Direct Object Reference) est une vulnérabilité de sécurité classée parmi les plus courantes par l'OWASP, où une application expose des identifiants directs (comme un numéro de commande ou un ID utilisateur) dans des URLs, formulaires ou APIs, sans vérifier les droits d'accès. Un attaquant peut ainsi modifier manuellement ces identifiants pour accéder aux données d'autres utilisateurs, comme illustré par l'exemple d'une URL ?id=1042 où remplacer 1042 par 1041 donne accès à une facture étrangère.

Cette faille est fréquente car elle est simple à implémenter et souvent négligée lors du développement, notamment avec des identifiants numériques prévisibles (auto-incrémentés). Elle ne se limite pas aux URLs mais peut aussi toucher les paramètres POST, les APIs ou les cookies, rendant le risque encore plus diffus. L'article souligne que même des développeurs expérimentés peuvent omettre de vérifier les permissions côté serveur, exposant ainsi des données sensibles.

Cette faille critique dans Kubernetes, révélée en janvier 2026, exploite la permission RBAC nodes/proxy GET pour exécuter du code à distance dans n’importe quel Pod du cluster, sans laisser de trace dans les logs d’audit. Cette vulnérabilité repose sur un contournement des vérifications d’autorisation : le Kubelet, via une connexion WebSocket, autorise l’exécution de commandes (/exec) en validant uniquement un GET initial, sans exiger le verbe CREATE normalement requis. L’absence de logs d’audit côté Kubelet aggrave le risque, permettant des attaques discrètes, notamment sur des composants système comme etcd ou kube-apiserver.

L’article souligne que des ServiceAccounts aux noms évocateurs, comme rook-ceph-system, combinés à des permissions étendues (accès en lecture aux Secrets), constituent des cibles privilégiées pour une élévation de privilèges. Une analyse des Roles et ClusterRoles est recommandée, avec des outils comme le script de détection du chercheur Graham Helton. Parmi les composants vulnérables figurent des outils courants comme l’OpenTelemetry Collector, dont les ServiceAccounts associés pourraient être exploités pour compromettre l’ensemble du cluster.

Pour atténuer ce risque, l’auteur propose plusieurs correctifs et mesures préventives, comme l’activation de la feature gate KEP-2862 pour un contrôle granulaire des autorisations Kubelet, l’utilisation de CiliumNetworkPolicy pour bloquer l’accès au port 10250, ou encore l’application de politiques Kyverno pour interdire la création de Roles incluant nodes/proxy. La surveillance des audit logs et la mise à jour des composants (comme Rook-Ceph) sont également essentielles, bien que Kubernetes ait classé cette faille comme un "comportement intentionnel" non corrigé en l’état.

L’article de Teddy Ferdinand souligne que l’intégration tardive de la cybersécurité dans un projet limite ses options à des mesures radicales, comme bloquer la mise en production ou imposer des corrections coûteuses, faute de pouvoir ajuster l’architecture ou les choix techniques en amont. L’auteur explique que cette approche brutale résulte souvent d’un manque de collaboration précoce, où les critères de sécurité ne sont pas définis dès le début, transformant une revue finale en révélateur de problèmes évitables.

Ferdinand illustre que les blocages en fin de projet sont rarement perçus comme des solutions, mais plutôt comme des échecs, car ils surviennent après que les engagements métiers, les budgets et les délais aient été figés. Il insiste sur l’importance d’intégrer la sécurité dès les phases clés, en amont, pour éviter des arbitrages douloureux et des tensions entre équipes projet, métier et management.

Enfin, l’auteur rappelle que la sécurité ne vise pas à freiner les projets, mais à les sécuriser de manière proactive, en clarifiant les règles, les responsabilités et les critères de validation avant que les choix ne deviennent irréversibles.

CrowdSec est un outil de défense réseau communautaire qui dépasse les limites de fail2ban en mutualisant les informations entre serveurs. Contrairement à fail2ban, isolé et réactif, CrowdSec permet à un serveur d’apprendre des attaques détectées ailleurs et d’appliquer des bannissements préventifs avant même qu’une IP malveillante n’atteigne son infrastructure. Le système repose sur trois composants : l’Agent, qui analyse les logs locaux et génère des décisions de blocage ; le Bouncer, qui applique ces décisions à différents niveaux (réseau, proxy ou application) ; et la CAPI, une API centrale qui agrège et redistribue les bannissements validés par consensus parmi la communauté.

Le modèle de CrowdSec répond à trois faiblesses majeures de fail2ban : l’isolement des serveurs, l’inefficacité face aux attaques distribuées (botnets utilisant des milliers d’IP) et le coût silencieux des attaques répétées sur les ressources. En partageant les signaux d’attaque et en appliquant des bannissements globaux, CrowdSec réduit la charge sur les infrastructures tout en améliorant la réactivité contre les menaces émergentes.

L’écosystème de CrowdSec permet une intégration flexible, avec des scénarios personnalisables et des mécanismes de consensus pour limiter les faux positifs. Prochainement, un billet détaillera son déploiement concret, illustrant comment cette approche communautaire transforme la sécurité des serveurs publics.

Claude-Red est une bibliothèque organisée de compétences en sécurité offensive conçue pour le système Claude Skills, permettant de transformer l'IA en un acteur du red teaming. Chaque compétence est un fichier structuré SKILL.md couvrant des surfaces d'attaque variées, comme les injections SQL, le développement d'exploits, l'évasion d'EDR ou encore les attaques sans fil (Wi-Fi, WPA2/3).

Le projet, développé par SnailSploit, propose une approche modulaire où les compétences sont chargées dynamiquement selon les besoins, évitant ainsi une surcharge contextuelle. Il s'adresse aux professionnels pour des engagements autorisés, des recherches de vulnérabilités, des CTF ou des formations, avec une méthodologie experte intégrée.

L'installation est flexible : clone du dépôt, script dédié ou sélection de catégories spécifiques (web, Active Directory, etc.). Le dépôt inclut aussi des outils comme convert_skills.py pour adapter les compétences et une documentation complète pour contribuer ou exploiter les fichiers.

Les détecteurs de dioxyde de carbone (CO₂) se sont popularisés pendant la pandémie de Covid-19, car ils permettent d’évaluer indirectement le risque de présence de pathogènes dans l’air en mesurant la concentration de CO₂, liée à l’expiration humaine. Bien que moins dangereux que le monoxyde de carbone, un taux élevé de CO₂ (dès 2 %) peut provoquer fatigue et maux de tête, tandis qu’un seuil critique de 5 % devient dangereux.

La détection repose principalement sur la spectrométrie infrarouge non dispersive (NDIR), exploitant l’absorption spécifique du CO₂ dans l’infrarouge à 4 260 nm. Une source lumineuse infrarouge traverse une cavité exposée à l’air, et un filtre optique isole la bande d’absorption du CO₂ avant qu’un capteur (comme une thermopile) mesure la variation de température induite par les infrarouges.

D’autres méthodes existent, mais le choix dépend du coût, de la sensibilité et de l’usage (industriel, domestique, etc.). Contrairement au monoxyde de carbone, le CO₂ ne se détecte pas par des réactions chimiques, évitant ainsi les interférences et les faux positifs.

Ce guide des agences de cybersécurité australienne, américaine, canadienne, néo-zélandaise et britannique met en garde contre les risques spécifiques des systèmes d'IA agentique, de plus en plus utilisés dans les infrastructures critiques. Bien qu'ils automatisent des tâches répétitives, ces outils peuvent être détournés, causant des perturbations, des pertes de productivité ou des fuites de données, nécessitant une évaluation rigoureuse des scénarios à risque.

Les auteurs recommandent d'intégrer ces systèmes dans les modèles de sécurité existants, en limitant strictement leurs accès, notamment aux données sensibles ou systèmes critiques. L'IA agentique ne devrait être employée que pour des tâches à faible risque, avec une supervision constante pour maintenir la confiance dans ces technologies.

Destiné aux grandes organisations et gouvernements, ce document propose des bonnes pratiques pour sécuriser ces systèmes, depuis leur conception jusqu'à leur déploiement, en passant par une analyse des vulnérabilités potentielles et des comportements à risque.

Dependency Cooldowns propose une solution simple pour réduire les risques liés aux attaques par dépendances malveillantes dans les écosystèmes de gestion de paquets. L’idée centrale est d’imposer un délai minimal (cooldown) avant qu’une nouvelle version d’une dépendance ne soit installée, limitant ainsi l’exposition aux attaques rapides. Par exemple, un cooldown de trois jours aurait bloqué 80 à 90 % des attaques analysées, dont des compromissions comme LiteLLM ou axios, où les fenêtres d’exploitation étaient de quelques heures seulement.

Le site détaille les implémentations par écosystème, comme uv pour Python (avec des commandes comme uv pip install --exclude-newer '3 days' foo) ou npm (via des outils comme cooldowns.sh). Bien que certains gestionnaires comme pip ne supportent pas encore les durées relatives, des contournements existent. La méthode s’applique aussi aux dépendances transitives, renforçant la sécurité globale.

Enfin, l’article souligne l’efficacité des cooldowns, même réduits à un jour, et fournit des exemples de configuration pour divers outils (pnpm, Yarn, Cargo, etc.). Une approche pragmatique pour limiter les risques sans complexité majeure.

GTFOBins est une liste curated d'exécutables Unix-like permettant de contourner les restrictions de sécurité locales dans des systèmes mal configurés. Le projet recense des fonctions légitimes de ces outils pouvant être détournées pour échapper à des shells restreints, élever des privilèges, transférer des fichiers ou établir des connexions inversées, sans exploiter de vulnérabilités spécifiques.

Développé par Emilio Pinna et Andrea Cardaci avec la contribution de nombreux autres, GTFOBins se concentre sur l'exploitation des outils natifs disponibles ("living off the land"). Il ne s'agit pas d'une liste d'exploits, mais d'un guide pratique pour les professionnels de la sécurité ou les administrateurs système.

Le site propose également une API JSON et des liens vers des ressources complémentaires comme LOLBAS pour les binaires Windows. Les utilisateurs peuvent contribuer en soumettant de nouvelles entrées ou techniques.

L’article de Teddy Ferdinand critique l’idée reçue selon laquelle la cybersécurité serait le principal frein aux projets, soulignant que le vrai problème réside plutôt dans le flou organisationnel. Les règles imprécises, les responsabilités mal définies et les processus opaques créent une dette organisationnelle, où chaque équipe interprète différemment les attentes, menant à des blocages tardifs. Par exemple, des critères vagues comme "les accès doivent être sécurisés" sans détails concrets (MFA, gestion des droits, etc.) génèrent des incompréhensions et des risques non anticipés.

L’auteur explique que la sécurité n’est souvent que le révélateur de ces dysfonctionnements, intervenant trop tard dans un projet déjà mal maîtrisé. Les équipes découvrent alors des lacunes critiques (architecture non documentée, données sensibles exposées) qui auraient dû être identifiées en amont. Le manque de clarté dans les processus de validation et l’absence de SLA (accords de niveau de service) sapent la confiance et ralentissent in fine l’ensemble des parties prenantes.

En conclusion, Ferdinand plaide pour des règles explicites, des responsabilités attribuées et des critères de validation transparents, afin d’éviter que la sécurité ne soit perçue comme un obstacle alors qu’elle devrait être un garde-fou intégré dès la conception des projets.

En mai 2026, le portail moncompte.ants.gouv.fr a subi une faille IDOR (Insecure Direct Object Reference) ayant exposé les données de 11,7 millions de Français. L’exploitation, qualifiée de « vraiment stupide » par son auteur, consistait simplement à modifier un identifiant numérique dans une URL pour accéder aux comptes d’autres utilisateurs, faute de vérification d’autorisation entre l’authentification et la récupération des données.

L’article explique que cette vulnérabilité, courante mais critique, survient lorsque les applications ne contrôlent pas si un utilisateur a le droit d’accéder à une ressource spécifique, même après s’être authentifié. L’exemple donné illustre un endpoint /api/account/{id} où seule la session est validée, sans vérification que l’identifiant {id} correspond bien au compte de l’utilisateur connecté.

Pour éviter ce type de faille, l’auteur propose des solutions techniques avec Symfony et PHP, comme l’utilisation de Voters pour gérer les autorisations, l’absence d’IDs exposés dans les URLs, ou des tests automatisés pour détecter les accès non autorisés. Le problème ne dépend pas du framework utilisé, mais de l’absence d’une couche d’autorisation explicite.

L’article Email is crazy explore la complexité et les paradoxes de l’infrastructure email, malgré son apparente simplicité. Bien que des milliards d’emails soient échangés quotidiennement, son fonctionnement repose sur des protocoles anciens (SMTP, DNS) et une architecture organique, accumulée depuis les années 1970. L’auteur illustre ce processus à travers l’exemple d’Alice envoyant un email à Bob, détaillant les étapes techniques comme la soumission via un Mail Submission Agent, le routage via les enregistrements MX du DNS, et la gestion des files d’attente en cas d’indisponibilité du serveur.

L’article révèle aussi les failles de sécurité et les subtilités cachées, comme l’absence de vérification stricte de l’expéditeur dans SMTP, permettant des usurpations d’identité. Les serveurs s’appuient sur des mécanismes de filtrage (spam, sécurité) et des retries progressifs pour garantir la livraison, malgré des délais variables. Enfin, l’auteur souligne que l’email, bien que perçu comme instantané, fonctionne comme un système eventually consistent, où la rapidité dépend des infrastructures modernes plutôt que du protocole lui-même.

Kloak est un outil innovant conçu pour sécuriser les secrets dans Kubernetes en les injectant directement au niveau du noyau via eBPF, sans que l'application ne les manipule jamais en clair. L'idée centrale est d'intercepter le trafic TLS sortant à l'aide d'uprobes eBPF, remplaçant des placeholders par les vrais secrets juste avant le chiffrement, ce qui empêche leur exposition même en cas de compromission du conteneur. Contrairement aux solutions traditionnelles comme OpenBao ou les sidecars, Kloak évite que les secrets ne résident en mémoire de l'application, réduisant ainsi les risques d'exfiltration.

L'architecture de Kloak repose sur deux plans distincts : un control-plane qui gère les Shadow Secrets et synchronise les eBPF maps, et un data-plane qui intercepte les appels TLS via des hooks sur SSL_write et crypto/tls.(*Conn).Write. Le controller, déployé en tant que DaemonSet, surveille les secrets labellisés et réécrit les montages de pods via un Mutating Admission Webhook, garantissant une intégration transparente sans modification du code applicatif.

L'auteur présente un Proof of Concept (PoC) détaillant les défis rencontrés, notamment avec Flannel et Cilium, ainsi que des méthodes d'analyse via les logs et les compteurs eBPF. Bien que le projet soit récent et open-source, il offre une approche prometteuse pour renforcer la sécurité des secrets dans les environnements Kubernetes, en alignement avec les principes zero-trust.

L’article analyse les UserNamespaces dans Kubernetes, une fonctionnalité présentée comme révolutionnaire mais souvent mal comprise. L’auteur souligne que ces espaces de noms réduisent l’impact d’une évasion de container en mappant l’UID 0 (root dans le container) vers un utilisateur non privilégié sur l’hôte, limitant ainsi les dégâts en cas de compromission. Cependant, il critique les promesses exagérées des infographies, qui présentent cette fonctionnalité comme une solution miracle contre les risques de sécurité, alors qu’elle ne couvre qu’un scénario spécifique (l’escape de container).

L’auteur détaille les cas d’usage concrets des UserNamespaces, comme l’exécution de builds sans privilèges (Buildah, Podman rootless) ou la gestion de legacy systems (Postfix, Dovecot) nécessitant des UID fixes. Il rappelle aussi que cette fonctionnalité ne remplace pas les bonnes pratiques de sécurité, comme le multi-tenancy ou la gestion des vulnérabilités kernel, et que son efficacité dépend d’une configuration rigoureuse. Les UserNamespaces sont utiles, mais leur adoption doit s’inscrire dans une stratégie globale.

Enfin, l’article met en garde contre une confiance excessive dans cette fonctionnalité, soulignant que les risques de sécurité applicative (mauvaise configuration, secrets exposés) ou opérationnelle (mauvaise gestion des ressources) restent critiques. L’auteur conclut que les UserNamespaces sont une avancée, mais qu’ils ne doivent pas occulter les priorités réelles en matière de sécurité Kubernetes.

L’article met en garde contre la pratique dangereuse curl | bash, souvent présentée comme une méthode d’installation simple, notamment dans des documentations officielles. Cette méthode, qui consiste à télécharger et exécuter directement un script depuis Internet, expose à des risques de sécurité majeurs. En effet, le script exécuté peut différer de celui consulté, car le serveur peut adapter sa réponse en fonction du contexte (navigateur, curl, adresse IP, etc.), exploitant ainsi les particularités du pipeline Unix où bash commence à exécuter le script avant même qu’il ne soit entièrement téléchargé.

L’auteur souligne que même l’utilisation de HTTPS ne protège pas contre cette menace, car il garantit uniquement l’intégrité du transport et l’authenticité du serveur, mais pas l’honnêteté du contenu servi. Un serveur malveillant peut ainsi fournir un script inoffensif lors d’une visualisation directe, tout en injectant un code malicieux lors d’une exécution via curl | bash. Des techniques comme la détection du comportement typique d’un pipeline (par exemple, en insérant une commande lente comme sleep) permettent à un serveur de distinguer une exécution directe d’une exécution via curl | bash, renforçant ainsi le risque d’exécution de code non désiré.

Proxelar est un proxy MITM (Man-in-the-Middle) programmable écrit en Rust, conçu pour intercepter, inspecter et modifier le trafic HTTP/HTTPS. Il permet de transformer les requêtes et réponses en temps réel via des scripts Lua, offrant ainsi un outil puissant pour le débogage d'API, l'analyse de services tiers ou le test d'applications mobiles. Le projet propose plusieurs modes de fonctionnement (proxy avant/arrière) et des interfaces variées (terminal, TUI interactive, interface web).

Parmi ses fonctionnalités clés, Proxelar inclut l'interception automatique des connexions HTTPS grâce à une autorité de certification intégrée, ainsi qu'un système de filtrage avancé pour analyser les requêtes. Il prend en charge l'inspection des flux WebSocket et permet une installation simplifiée du certificat racine via une page dédiée. Le projet est distribué sous licence MIT et peut être installé via Cargo, Homebrew ou Docker.

Le dépôt GitHub du projet met en avant des contributions actives, avec des mises à jour régulières et une documentation en constante amélioration, incluant des exemples de scripts Lua pour personnaliser le comportement du proxy.

Shannon est un pentester IA autonome en white-box conçu par Keygraph pour tester la sécurité des applications web et de leurs APIs. Il analyse le code source pour détecter des vecteurs d’attaque, puis exécute des exploits réels (injections, contournements d’authentification, SSRF, XSS) afin de valider les vulnérabilités avant leur mise en production. Seules les failles avec un proof-of-concept fonctionnel sont rapportées.

L’outil comble un vide en automatisant les tests de pénétration, souvent limités à une fois par an, pour les aligner sur le rythme des déploiements modernes. Disponible via npx @keygraph/shannon, il s’intègre facilement aux pipelines CI/CD et utilise une architecture éphémère pour limiter les risques.

Le projet, sous licence AGPL-3.0, est open source et propose des fonctionnalités avancées comme un CLI via monorepo, une intégration Docker, et une gestion structurée des vulnérabilités. Il cible les équipes cherchant à réduire leur exposition aux risques de sécurité entre deux audits manuels.

Ce dépôt GitHub propose une collection de bonnes pratiques pour sécuriser l'utilisation du gestionnaire de paquets npm, face aux risques croissants d'attaques par la chaîne d'approvisionnement. Il met l'accent sur des mesures comme la désactivation des scripts post-installation, l'installation avec délai pour éviter les dépendances vulnérables, et l'utilisation d'outils comme npq ou Socket Firewall pour renforcer la sécurité lors des installations. Une section est dédiée à la prévention des attaques par confusion de dépendances, un vecteur d'attaque récurrent exploitant les lacunes des gestionnaires de paquets.

Le guide couvre également des pratiques pour le développement local sécurisé, comme éviter les secrets en clair dans les fichiers .env, et des recommandations pour les mainteneurs de paquets npm, incluant l'activation de la double authentification (2FA) et l'utilisation de l'authentification OIDC pour les publications. Il aborde aussi la vérification de la santé des paquets via des bases de données comme celle de Snyk et la méfiance envers le registre officiel npmjs.org.

Enfin, il propose des solutions pour différents gestionnaires de paquets (npm, pnpm, Bun, Yarn) et inclut des outils automatisés comme Snyk, Dependabot ou Renovate pour gérer les mises à jour de dépendances de manière sécurisée.