VeilleTech — 2026-09-15

01 SÉCURITÉ Faille

Gitea exposé : Red Heron scanne, entre, reste

The Hacker News14 septembre3 min de lecture

Acronis TRU attribue à l'acteur Red Heron l'exploitation de CVE-2026-60004, une RCE critique de Gitea divulguée en juillet 2026, contre des instances exposées sur internet : 1 386 instances scannées dans sept pays et treize compromissions confirmées au Canada, en Argentine, à Taïwan, aux États-Unis, au Qatar et au Sri Lanka. La progression va du vol de dépôts à l'accès root sur un cluster Proxmox de trois nœuds, via l'implant JITTERLY et un rootkit LD_PRELOAD inédit baptisé SIXZUT.

CVE-2026-60004 : RCE Gitea divulguée en juillet 2026 ; le PoC public (github.com/HORKimhab/CVE-2026-60004) a été transformé en framework automatisé « exp_enhanced.py » dès le 29 juillet 2026
Portée mesurée : 1 386 instances scannées sur 7 pays, jeu de données séparé de 477 systèmes taïwanais, 13 compromissions confirmées (Taïwan 4, États-Unis 4, Canada 2, Argentine 1, Qatar 1, Sri Lanka 1)
Outils déposés : implant Linux C++ JITTERLY (plus de 30 commandes de post-exploitation, proche d’AdaptixC2) et rootkit LD_PRELOAD SIXZUT, qui patche 15 fonctions pour masquer fichiers, processus et connexions

Un dépôt Git privé, c'est votre code plus tous vos secrets au même endroit.

Lire la fiche Source

02 OAUTH Faille

Une extension Twitch fuitait 31 000 jetons

The Hacker News14 septembre3 min de lecture

L'extension « Twitch Enhanced Viewer | JeetBot », publiée sur Chrome et Firefox, transmettait le jeton OAuth Twitch de ses utilisateurs aux proxys de son éditeur sous forme de paramètre d'URL — donc en clair dans les journaux. Socket recense près de 31 000 utilisateurs concernés. La version corrigée 85.8.7 est parue côté Firefox, mais elle ne révoque pas les jetons déjà transmis : seule une déconnexion de toutes les sessions Twitch le fait.

Identifiants : Chrome pnhhdhhcadcjfckjhpmjneldiegbojfb (30 000 utilisateurs, publiée le 26 juin 2025) et Firefox twitchenhancedviewer@example.com (604 utilisateurs, 7 juillet 2025)
Les builds v85.x transmettent le jeton en paramètre &auth= vers le proxy de l’opérateur sur les requêtes vers usher.ttvnw[.]net ; les builds v4.x (ex. 4.8, janvier 2026) le POSTaient vers un endpoint set-token, avec des relais sur deno.dev et deno.net
Correctif 85.8.7 (Firefox publiée, Chrome en attente de revue) — il stoppe l’envoi mais ne révoque rien : passer par Twitch › Sécurité et confidentialité › Déconnecter tous les appareils

Un jeton dans une URL, c'est un mot de passe écrit sur une carte postale.

Lire la fiche Source

03 SÉCURITÉ Faille

Telegram : un export HTML qui vous relit

The Hacker News14 septembre3 min de lecture

Telegram Desktop écrivait sans échappement le libellé des boutons d'un bot dans ses exports HTML, ce qui permettait d'y cacher du JavaScript exécuté à l'ouverture du fichier dans un navigateur. Les chercheurs d'ExPatch, Denis et Aleksander Rostilov, l'ont publié le 12 septembre 2026 et le notent 8,2 sur 10 en CVSS 3.1. Le correctif est parti en juillet, mais aucun export déjà produit n'est réparé, et il n'existe ni CVE ni avis de sécurité.

Versions touchées : Telegram Desktop 4.15.1 (mars 2024) à 6.9.3 — soit deux ans et quatre mois. Corrigé en 6.9.4 bêta (3 juillet 2026) et 7.0.1 stable (14 juillet 2026), par le commit 8457d13a
Le script s’exécute sans clic, lit l’intégralité du fichier (messages, expéditeurs, horodatages, nom et type du salon, nombre de membres, chemin local) ; l’export est découpé par blocs de 1 000 messages, ce qui borne la fuite à un fichier
Aucun identifiant CVE, aucune mention dans le changelog ni dans les notes de version ; bug bounty de 500 $ proposé le 1er juillet et refusé par les chercheurs au profit d’une association

Échapper huit champs sur neuf, c'est ne pas échapper.

Lire la fiche Source

04 WORDPRESS Discussion

WordPress bloque les mises à jour à risque

The Hacker News14 septembre3 min de lecture

Depuis le 9 septembre 2026, WordPress.org analyse automatiquement chaque nouvelle version de plugin pendant sa période de refroidissement et bloque sa distribution si le score de risque dépasse un seuil. Le dispositif complète l'initiative « Protect The Shire » lancée le 5 juin, qui impose déjà six heures de délai avant diffusion. Un cas réel est cité : une porte dérobée détectée le 28 juillet dans un plugin d'environ 20 000 installations actives, jamais distribuée, plugin fermé 26 minutes après l'alerte.

Chaîne de contrôle : cooldown de 6 heures (réduit depuis les 24 h initiales du 5 juin 2026) → analyse par modèles IA + Jetpack Scan → score de risque → blocage automatique et courriel à l’auteur, envoyé uniquement en cas de blocage
Motifs qui font monter le score : endpoints REST, AJAX ou admin-post sans contrôle de capacité (un nonce n’est pas une autorisation), requêtes sans $wpdb->prepare(), chemins ou includes construits depuis la requête, unserialize() sur données distantes, options écrites depuis un endpoint accessible aux abonnés, code récupéré ou évalué à l’exécution, code obfusqué
Seul recours pour débloquer : corriger et publier une nouvelle version — une contestation manuelle est presque toujours plus lente ; outils recommandés : WordPress Coding Standards, PHP_CodeSniffer, et QIT pour les extensions WooCommerce

La revue à l'entrée ne protège de rien si la porte reste ouverte après.

Lire la fiche Source

05 SYMFONY Article

Symfony Mate ouvre le runtime aux agents

Symfony14 septembre3 min de lecture

Mate, composant de Symfony AI, donne à un agent de code un accès direct au runtime d'une application Symfony : profiler, logs Monolog et conteneur de services. Depuis Symfony AI 0.13, ce n'est plus un serveur MCP mais un simple CLI doublé d'une couche de découverte qui écrit les instructions dans AGENTS.md et installe cinq skills. Mate lit les artefacts déjà présents sur disque, donc il répond même quand un conteneur cassé empêche l'application de démarrer.

Installation : composer require --dev symfony/ai-mate puis vendor/bin/mate init — la commande enregistre le mode d’invocation (direct, docker exec <conteneur>, ddev exec) et la version PHP, et refuse de tourner sous un autre PHP majeur ou mineur
Commandes livrées : symfony-profiler-list / symfony-profiler-get (liste puis détail par jeton), monolog-tail et monolog-search (filtres niveau, canal, environnement), symfony-service-detail (classe, tags DI, appels de méthode, factory)
Extension par attribut : #[MateTool] sur une méthode suffit (schéma d’entrée généré par réflexion et PHPDoc), classe déposée dans mate/src/ sous le namespace Mate\ ; #[MateResource] et #[MateResourceTemplate] pour les données lisibles ; extensions PHPUnit, PHPStan, Rector et Composer sur l’organisation MatesOfMate

Le code dit ce que l'application sait faire, le profiler dit ce qu'elle a fait.

Lire la fiche Source

06 POSTGRES Article

Vacuum surveille Postgres depuis Laravel

Laravel News14 septembre2 min de lecture

Vacuum est un paquet Laravel de Rati Rukhadze qui lit les vues de statistiques que PostgreSQL tient déjà (pg_stat_user_tables, pg_stat_activity, pg_stat_statements) et affiche les problèmes détectés avec la requête SQL qui les corrige. Treize règles couvrent le wraparound, le bloat, les tuples morts, les index inutilisés et les requêtes lentes, avec une note sur 100. Deux commandes s'intègrent en CI : vacuum:check fait échouer un build sur constat critique, vacuum:lint signale les clés étrangères non indexées dans les migrations.

Prérequis version : Vacuum 1.2.0 demande PostgreSQL 14 et Laravel 11+ ; l’extension pg_stat_statements est optionnelle (le tableau de bord signale son absence)
En CI : php artisan vacuum:check --fail-on=warning (critical, warning, info ou never) et --format=json pour score, note, déductions et constats ; php artisan vacuum:lint pour les problèmes de schéma
Seuils dans config/vacuum.php : dead_tuple_ratio à 0.20, slow_query_milliseconds à 500 ; le tableau de bord /vacuum n’est ouvert qu’en environnement local, ailleurs il faut un callback Vacuum::auth()

Un index manquant ne coûte rien le jour où on l'oublie.

Lire la fiche Source

07 LLM Discussion

35 ko de prompt chez soi : ce qui casse

patrickmccanna.net14 septembre3 min de lecture

Un praticien raconte l'échec puis le rattrapage d'une migration : des prompts d'agent de 35 ko, efficaces sur une API frontière, s'effondrent sur une installation Ollama locale. La cause n'est pas la taille du modèle mais la fenêtre de contexte — 65 000 tokens sur sa machine, dont 14 % consommés par le seul preprompt. Le billet donne une liste de signaux d'épuisement de contexte à surveiller dans les journaux, et une méthode de découpage en prompts à objectif unique.

Le banc d’essai : AMD Ryzen AI MAX+ 395, 128 Go dont 32 Go réservés à l’OS hôte ; fenêtre de contexte de 65 000 tokens ; un preprompt de 35 ko en occupe 14 % avant le premier échange, et l’agent sature en 3 minutes
Signaux d’épuisement à journaliser : appels d’outils identiques consécutifs, lectures répétées du même fichier, agent qui reformule son objectif, échecs de parsing d’appels d’outils, ratio tours / fichiers modifiés élevé
Remèdes : découper en unités objectif unique, définir explicitement la longueur de contexte dans Ollama (les défauts sont très bas), agents déclaratifs dans ~/.config/opencode/agents, état de session écrit sur disque, moins d’appels d’outils par étape, « fais seulement Y » plutôt que « ne fais pas X »

La grande fenêtre de contexte pardonne les prompts médiocres. La vôtre, non.

Lire la fiche Source

08 IA Article

AI SDK : vos agents via abonnement, sans clé

Vercel14 septembre1 min de lecture

La couche harness du AI SDK de Vercel, qui expose plusieurs agents de code derrière la même interface HarnessAgent, sait désormais s'authentifier via l'abonnement natif de l'agent plutôt que par une clé d'API. Aucun changement de code n'est requis : le mode direct et le mode auto utilisent les identifiants d'environnement s'ils existent, sinon l'abonnement présent sur l'hôte. Les identifiants ne quittent pas l'hôte, et l'agent peut ne recevoir que des valeurs factices.

Trois modes : direct et auto lisent l’abonnement natif à défaut d’identifiants explicites (auto seulement si aucune information AI Gateway n’est configurée) ; ai-gateway ne lit jamais d’abonnement
Les identifiants sont résolus à la frontière de l’hôte, les jetons OAuth y sont rafraîchis ; là où le bac à sable le permet, le harness reçoit des identifiants factices et le vrai jeton est injecté dans les requêtes sortantes
Agents compatibles annoncés : Claude Code, Cline, Codex, Cursor, fx, GitHub Copilot, Grok Build, OpenCode et Pi — à condition que l’agent gère lui-même la connexion par abonnement

Changer de mode d'authentification sans changer une ligne, ça se vérifie avant de déployer.

Lire la fiche Source

09 DEVOPS Article

Kubernetes 1.37 coupe le throttling mémoire

Kubernetes14 septembre2 min de lecture

Memory QoS passe en bêta dans Kubernetes v1.37 et la feature gate est active sur tous les kubelets, mais le défaut de memoryThrottlingFactor passe de 0.9 à null : sans configuration explicite, le kubelet n'écrit plus memory.high, memory.min ni memory.low. Pour un cluster qui n'utilisait pas la fonctionnalité, la montée de version ne change rien. Pour un cluster qui l'avait activée en alpha sans inscrire le facteur dans sa configuration, le throttling s'arrête sans avertissement.

La feature gate MemoryQoS est bêta et activée par défaut en v1.37, mais memoryThrottlingFactor vaut désormais null (contre 0.9 en alpha) et memoryReservationPolicy vaut None
Pour retrouver le comportement alpha, déclarer dans KubeletConfiguration (apiVersion kubelet.config.k8s.io/v1beta1) : memoryThrottlingFactor: 0.9, et memoryReservationPolicy: TieredReservation pour la réservation par paliers via memory.min et memory.low
Pour désactiver la fonctionnalité, retirer d’abord ces champs : le kubelet rejette la configuration si memoryThrottlingFactor vaut autre chose que l’ancien 0.9 ou si memoryReservationPolicy vaut TieredReservation

Une fonctionnalité activée par défaut qui n'écrit rien par défaut, ça se relit deux fois.

Lire la fiche Source

10 SÉCURITÉ Faille

DDRop : la mémoire chiffrée rejoue le passé

The Hacker News14 septembre4 min de lecture

DDRop est une attaque matérielle qui casse l'intégrité mémoire d'Intel TDX, Intel Scalable SGX et AMD SEV-SNP en supprimant silencieusement des écritures : le processeur relit alors une ancienne valeur chiffrée, parfaitement valide à ses yeux. Elle exploite l'absence de garantie de fraîcheur dans le chiffrement mémoire à grande échelle. L'interposeur coûte moins de 200 dollars, fonctionne sur DDR5, et les designs de carte comme le code sont publiés. Il n'existe pas de correctif logiciel complet.

Travaux de KU Leuven, ETH Zurich, Durham University et Google, à présenter à ACM CCS 2026 en novembre ; designs de carte, firmware du contrôleur et code d’attaque publiés sur github.com/ddropattack/ddrop, papier sur ddropattack.eu
Sur Intel TDX : suppression des écritures qui initialisent une table de pages → mappage arbitraire de mémoire physique, lecture d’une VM victime, bascule en mode debug, et falsification de la mesure de démarrage servant à l’attestation distante. Sur AMD SEV-SNP, portée plus réduite (copie d’une page victime dans une autre via la page-relocation)
Non affectés : l’ancien Intel Client SGX (arbre d’intégrité matériel, mais retiré depuis) et les GPU confidentiels NVIDIA (mémoire dans le package). Arm CCA non testé. Avis Intel du 11 août 2026 et bulletin AMD SB-3048 ; les deux fondeurs classent l’accès physique hors modèle de menace

Chiffrer la mémoire dit qu'elle est illisible, pas qu'elle est à jour.

Lire la fiche Source

VeilleTech — feed du mardi 15 septembre