VeilleTech — 2026-09-13

01 SÉCURITÉ Faille

ScreenConnect et RouterOS : patch avant demain

The Hacker News12 septembre2 min de lecture

La CISA a inscrit cinq failles activement exploitées à son catalogue KEV : CVE-2026-84869 dans ConnectWise ScreenConnect (CVSS 9.9), CVE-2026-67277 et CVE-2026-86060 dans MikroTik RouterOS, et les deux failles JFrog Artifactory déjà vues en début de semaine. Huntress a documenté trois incidents où ScreenConnect a servi à distribuer un VBScript, et le CERT polonais une chaîne baptisée MikroTrick qui prend le contrôle de routeurs sans authentification.

ScreenConnect : CVE-2026-84869, CVSS 9.9 — corrigé en version 26.6.5 ; seuls les clients sont touchés, pas les serveurs
RouterOS : CVE-2026-67277 (CVSS 8.8, service btest, fuite de mémoire noyau) et CVE-2026-86060 (CVSS 9.2, masque de politique de confiance)
Échéances CISA : RouterOS le 13 septembre, ScreenConnect le 14 septembre, Artifactory (CVE-2026-42016 et CVE-2026-42018) le 25 septembre

Une date butoir fédérale, c'est le chronomètre de tout le monde.

Lire la fiche Source

02 SÉCURITÉ Faille

Vos agents de code noient la détection

The Hacker News12 septembre3 min de lecture

Intezer a classé les alertes liées à l'IA sur le parc de ses clients : 0,43 % du flux total, mais multiplié par 18 entre février et juin 2026. La répartition est de 94,1 % de bruit, 5,8 % de risque réel et 0,02 % de vraies attaques. Le bruit vient de détections écrites avant l'existence des agents de code, qui voient un tunnel réseau ou une lecture de trousseau là où il n'y a qu'un développeur au travail.

Répartition des alertes IA : 94,1 % bruit, 5,8 % risque réel, 0,02 % attaques confirmées — 81,7 % supprimées automatiquement, 5,4 % escaladées à un humain
Cas réels : un agent lançant « security dump-keychain > /tmp/ » pour un seul jeton, un éditeur IA ouvrant un tunnel ngrok, Cursor.exe → powershell.exe → rundll32.exe (MiniDump via comsvcs.dll)
L'installeur signé de Claude Desktop déclenche la règle EDR « Ransomware Operations detected » ; chez un client, une seule détection sur Expand.exe faisait 55 % des alertes critiques

Le jour où l'alerte compte, personne ne la lira plus.

Lire la fiche Source

03 SYMFONY Article

Symfony démonte FrameworkBundle en vingt bundles

Symfony13 septembre3 min de lecture

Sur la branche 8.2 en développement, chaque section de configuration de FrameworkBundle part dans un bundle livré par son propre composant : MessengerBundle, HttpClientBundle, CacheBundle, RouterBundle, SerializerBundle, ValidationBundle et une quinzaine d'autres. Deux mécanismes le rendent possible sans casser les configurations existantes : un nœud de configuration peut aliaser celle d'une autre extension, et le tag container.remove_if_missing retire un service quand son paquet n'est pas installé.

Bundles ajoutés en 8.2 : MessengerBundle, HttpClientBundle, PropertyInfoBundle, CacheBundle, RouterBundle, SerializerBundle, ValidationBundle, MailerBundle, NotifierBundle, LockBundle, WorkflowBundle, SchedulerBundle, JsonStreamerBundle, AssetBundle, AssetMapperBundle, RateLimiterBundle, WebhookBundle, HtmlSanitizerBundle
Mécanismes associés : tag container.remove_if_missing, aliasing de configuration entre extensions, instanciation à la demande des bundles inactifs au démarrage, et le nom du paquet à installer affiché quand une extension manque
Déjà disponible : durcissement OIDC backporté en 6.4 et 7.4 — plus aucune redirection suivie sur les endpoints token, UserInfo et JWKS, revendications vérifiées lues comme des booléens, 401 au lieu de 500 sur échec d’introspection

Un framework qui se démonte est un framework qui a compris son poids.

Lire la fiche Source

04 POSTGRES Article

NocoBase met à jour par clé, pas par filtre

DEV Community13 septembre3 min de lecture

Sur NocoBase 2.2.7, une mise à jour conditionnelle exécute un SELECT avec le filtre, collecte les clés primaires, puis émet les UPDATE sur ces clés — la condition n'atteint jamais l'instruction de mise à jour. Une ligne qui cesse de remplir la condition pendant l'opération est modifiée quand même : cinq fois sur cinq sur un test de 10 001 lignes. Le signalement dort sur le forum officiel depuis le 4 septembre.

Code concerné : méthode update de packages/core/database/src/repository.ts au tag v2.2.7 — find(filter) puis Model.update avec where sur le primaryKeyField seul
Mesure : 10 001 lignes en status=pending, mise à jour en 6,2 à 6,4 s, une ligne basculée en cancelled à la 1ʳᵉ seconde — écrasée 5 fois sur 5
Contournement : un nœud SQL dans un workflow, ou un seul UPDATE ... WHERE ; signalement forum t/14097 du 4 septembre, réponse « we are investigating », testé sur NocoBase 2.2.7 + PostgreSQL 16

Une condition qui sert au SELECT et meurt avant l'UPDATE ne protège rien.

Lire la fiche Source

05 DUCKDB Discussion

La falaise de Pandas vous vend un cluster

Eddie's Blog12 septembre3 min de lecture

La thèse n'est pas que Pandas est lent, mais que sa falaise mémoire pousse vers un système distribué bien avant que le volume le justifie. L'auteur s'appuie sur le papier « Why TPC is not enough » publié par Amazon en 2024 sur son parc Redshift : environ 95 % des tables y contiennent moins de 100 Go. Entre la falaise et l'endroit où un cluster devient nécessaire, Polars et DuckDB tiennent sur une seule machine.

Papier Amazon 2024 « Why TPC is not enough: An analysis of the Amazon Redshift fleet » : 94,68 % des tables sous 100 Go, 86,9 % des requêtes sur 80 Go ou moins (hypothèses assumées de 1 Ko par ligne et 10 machines à 8 Go/s)
Polars : scan_csv est paresseux, .collect(new_streaming=True) exécute le plan ; .explain(streaming=True) affiche le plan optimisé, avec predicate pushdown avant agrégation
DuckDB : SQL sur les objets Python en mémoire, .explain() donne le plan ; Pandas, lui, charge tout en mémoire puis filtre

Le cluster que vous évitez coûte moins cher que celui que vous provisionnez.

Lire la fiche Source

06 MESURE Discussion

Seize des vingt-quatre minutes étaient le lieur

Lalit Maganti12 septembre3 min de lecture

Bun annonçait une compilation plus de 5× plus rapide après son passage de Zig à Rust. Un ingénieur de Perfetto a écrit buildprof, un traceur qui enregistre tous les processus et accès fichiers d'un build, pour voir ce que ce chiffre contenait. Réponse : ld.lld tournait seul plus de 16 minutes à la fin, en LTO complet. Passé en ThinLTO, l'ancien build tombe de 24 à 15 minutes ; le reste de l'écart est structurel.

Mesures : CI Bun médiane 30 min 06 s (ère Zig) contre 5 min 37 s (ère Rust) ; rejeu sur une VM 6 cœurs / 12 threads : 24 min 24 s contre 5 min 40 s
Cause principale : ld.lld seul plus de 16 minutes en Full LTO, soit les deux tiers du build — en ThinLTO (Bun et WebKit), le build Zig passe à 15 minutes, dont 7 de lien
buildprof : ptrace plus un filtre seccomp, Apache-2.0, Linux uniquement, UI dérivée de Perfetto — surcoût mesuré de 12,27 s à 12,43 s sur ripgrep et de 26,78 s à 31,89 s sur Redis

Avant de changer de langage, regardez qui tient la fin du build.

Lire la fiche Source

07 LLM Article

DeepSeek sépare le prefill du décodage

Latent Space12 septembre3 min de lecture

DeepSeek a publié V4.1-Flash sous licence MIT sur Hugging Face, avec la vision intégrée au modèle. L'architecture est un encodeur-décodeur causal qui sépare le prefill du décodage : environ 8 milliards de paramètres actifs sur l'entrée, 16 sur la sortie. Le laboratoire annonce un cache clés-valeurs 4× plus léger en HBM et 8× sur SSD que la génération précédente — mais le décompte total, entre les 552 milliards annoncés et les ~763 trouvés dans les fichiers publiés, reste disputé.

deepseek-ai/DeepSeek-V4.1-Flash sur Hugging Face, licence MIT, publié le 10 septembre 2026 — poids en fp8, experts en fp4, vision native (image_token_id 129264), 384 experts routés plus 1 partagé, 6 par token
Cache KV annoncé : 4× moins de HBM et 8× moins de SSD que la génération précédente, 437× moins que la première ; contexte de 1 048 576 tokens via YaRN de facteur 16 depuis 65 536
Décompte contesté : 552B annoncés contre ~763,21B stockés d’après l’inspection des safetensors (551,566B de backbone, 196,929B d’engram, 14,225B DSpark/MTP, 0,485B vision) pour 511,76 Go — 128 à 256 Go de VRAM n’y suffisent pas

L'architecture compte plus que le numéro de version.

Lire la fiche Source

08 OUTILS Discussion

Base84, un encodage taillé pour les noms de fichiers

00f.net9 septembre3 min de lecture

TurboCrypt encodait les noms de fichiers chiffrés en Base91, qui tient sur Unix et macOS mais casse sur Windows. Frank Denis propose Base84 : les 94 ASCII imprimables hors espace, moins les 9 caractères interdits par Windows, moins le point. L'expansion moyenne tombe à 25,2 % contre 33,3 % pour Base64, et un nom de 255 octets transporte 197 octets d'entrée au lieu de 191.

Alphabet : ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!#$%&'()+,-;=@[]^_`{}~ — exclus : < > : " / \ | ? * et le point
Groupes de 5 caractères car 84⁵ = 4 182 119 424, soit 2,6 % sous 2³² : 32 bits par groupe dans ~95 % des cas, 31 sinon, donc 6,39 bits par caractère
Expansion moyenne 25,2 % (pire cas 29,0 %) contre 33,3 % pour Base64 ; 5 divise 255 exactement, d’où 197 octets utiles dans un nom de fichier contre 191 — implémentation jedisct1/zig-base84

Quatre-vingt-quatre caractères, et plus un nom de fichier qui casse.

Lire la fiche Source

VeilleTech — feed du dimanche 13 septembre