Une photo à la place du visuel bancaire dans Wallet : AirCard le permet sans jailbreak, en exploitant AirTraffic. Ce que cette modification change, ses limites et les possibilités de retour arrière.
Un cache CI est souvent considéré comme un simple réglage de performance. Pourtant, les fichiers restaurés peuvent finir dans un chemin exécuté par le build : dépendances, scripts, objets compilés, outils téléchargés ou couches intermédiaires. Un cache modifié par un job peu fiable peut donc devenir un canal d’exécution dans un workflow plus privilégié.
Depuis le 10 septembre 2026, GitHub Actions permet de fixer explicitement les droits du cache avec cache-mode. La clé accepte quatre valeurs, read, write, write-only et none, au niveau du workflow ou d’un job. La fonction est disponible sur github.com pour tous les plans.
Le réglage le plus utile en pratique consiste à séparer les rôles : les validations de pull requests restaurent un cache en lecture seule, tandis qu’un workflow déclenché depuis une branche de confiance produit les nouvelles entrées. Les jobs de publication qui n’ont pas besoin du cache le désactivent complètement.
cache-mode impose une limite de droits appliquée par le service de cache. Il ne vérifie toutefois pas l’intégrité des fichiers déjà présents et ne corrige pas un workflow qui exécute du code non fiable avec des secrets.
SPF, DKIM, DMARC, BIMI : comment configurer une chaîne anti-spoofing solide pour vos emails, avec les commandes et vérifications qui comptent vraiment.
Le 11 juin 2026, Sonatype a révélé une campagne de détournement de paquets dans l’Arch User Repository (AUR). Baptisée Atomic Arch, elle visait des paquets orphelins repris par de nouveaux comptes, puis modifiés pour installer une dépendance npm malveillante.
Sonatype estime qu’environ 1 500 paquets ont pu être concernés au fil de plusieurs vagues. Ce chiffre était encore présenté comme préliminaire dans son analyse. Arch Linux a confirmé un volume important d’adoptions et de mises à jour malveillantes sans publier de décompte définitif.
L’analyse statique du second étage montre des fonctions de collecte d’identifiants, d’anti-debugging et des références à eBPF pouvant servir à masquer des processus, fichiers ou connexions. Elle ne permet pas d’affirmer que toutes ces fonctions ont été exécutées sur chaque machine touchée.
Mise à jour du 28 août 2026 : le nombre de paquets est présenté comme une estimation, et les capacités eBPF comme des fonctions observées lors de l’analyse statique. La version initiale les décrivait trop directement comme un rootkit pleinement déployé.
Le 19 mars 2026, un acteur disposant d’identifiants compromis a publié une version malveillante de Trivy et détourné les références de ses actions GitHub. Trivy est justement utilisé pour détecter des vulnérabilités dans les dépendances et les images de conteneurs.
L’incident ne rend pas le scanner inutile. Il rappelle qu’un outil de sécurité reste un logiciel distribué par une chaîne de build, des comptes, des registres et des mécanismes de mise à jour qui peuvent eux-mêmes être compromis.
Mise à jour du 28 août 2026 : cet article a été recentré sur les faits confirmés par les projets concernés. Plusieurs exemples historiques de la version initiale mélangeaient des dates ou des mécanismes d’attaque différents. Les commandes ont aussi été adaptées aux versions actuelles des outils cités.
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.
CVE-2026-42945, surnommée Nginx RIFT par ses découvreurs, est un dépassement de tampon dans ngx_http_rewrite_module. Le défaut existe depuis Nginx 0.6.27 et peut être déclenché à distance lorsqu’une configuration utilise une séquence particulière de directives rewrite et set avec des données contrôlées par le client.
L’équipe de recherche depthfirst a démontré une exécution de code avec l’ASLR désactivé. Cette preuve établit que la corruption mémoire est exploitable dans un environnement préparé, mais elle ne démontre pas une exécution de code fiable sur toute installation Nginx moderne.
Nginx classe la vulnérabilité au niveau medium. Les versions 0.6.27 à 1.30.0 sont affectées. Les branches 1.30.1 et 1.31.0 ont introduit le correctif.
Mise à jour du 28 août 2026 : la première version de cet article évaluait trop largement le risque comme élevé pour les reverse proxies, homelabs et ingress Kubernetes. La priorité dépend d’abord de la version et de la présence du chemin rewrite/set vulnérable. La qualification amont est medium.
Dirty Frag désigne deux vulnérabilités du noyau Linux publiées le 7 mai 2026 par Hyunwoo Kim. Elles sont suivies sous CVE-2026-43284 pour le chemin XFRM/ESP et CVE-2026-43500 pour RxRPC.
Dans les deux cas, un attaquant qui peut déjà exécuter du code localement peut modifier une page du cache mémoire associée à un fichier normalement accessible en lecture seule. Le démonstrateur public utilise cette primitive pour obtenir les privilèges root.
Mise à jour du 28 août 2026 : les deux CVE disposent désormais de correctifs dans les noyaux fournis par les principales distributions. La désactivation des modules reste une solution temporaire lorsque la mise à jour est impossible. L’article initial, écrit pendant la divulgation, indiquait encore que le second correctif n’était pas publié.
