Quotidien suisseSamedi 26 septembre 2026Édition de 13h, technologie
Prochaine publication le 26 septembre 2026 à 17h
Une · Sécurité · Agents · CRM
SalesBleed : Agentforce, exfil CRM 0-clic et phishing Slack sous identité d’agent
Zenity Labs (Apostolov / Donato / Efrat / RoyChowdhury, 24.09 ; The Register Jessica Lyons 24.09 ; SecurityWeek 25.09) documente trois failles dans Salesforce Agentforce, regroupées sous le nom SalesBleed. Chaîne : formulaire public Web-to-Lead → injection de prompt indirecte dormante → lecture CRM via l’outil Query Records du sous-agent General CRM → contournement de la rédaction Trusted URLs → exfiltration 0-clic (balises img / unfurling Slack → DNS). Troisième vecteur : action « Reply to a Slack Thread » sans confirmation ni attribution → messages de phishing sous l’identité de l’agent. Salesforce a corrigé ; Zenity confirme les trois correctifs au 21.09.2026.
Entrée : un lead soumis via l’endpoint Web-to-Lead (non authentifié par design). Déclencheur : une requête banale d’employé (« vérifie mes derniers leads »). Sortie : données Accounts (nom de société, taille de deal, etc.) collées en sous-domaine d’un hostname contrôlé, puis résolues en DNS sans clic. Contournement Trusted URLs : TLD hors liste fixe du redacteur (ex. .fun) + caractères de terminaison (accolades, crochets) traités différemment par le redacteur et le renderer — une chaîne non-URI au sens RFC 3986 passe le filtre mais déclenche quand même une résolution DNS côté client. Variante Slack : l’unfurling de liens fait le fetch à la place de la balise image.
Phishing : le sous-agent Slack Knowledge livrait « Reply to a Slack Thread » sans les deux garde-fous présents sur « Send a Slack Direct Message » (confirmation utilisateur + attribution de l’invocateur). Insider ou injection externe via lead empoisonné : réponse de fil sous la seule identité de l’agent. Timeline : signalement Zenity 1.06 → fix Trusted URLs confirmé 19.08 → attribution Slack 20.08 → confirmation obligatoire 21.09. Leçon Zenity / Bargury : « secure-by-design » ne suffit plus si un seul écart de rendu ou d’action write ouvre le canal. Chaînes décrites = fermées ; le schéma (données externes + outils sensibles + rendu de liens) n’est pas propre à Salesforce.
Google AX : orchestrateur open source style Kubernetes pour agents autonomes
InfoQ 22.09 (Olimpiu Pop) : Google publie AX (agentexecutor.io, dépôt google/ax, Apache 2.0) — plan de contrôle déclaratif et runtime pour exécuter et scaler des workloads d’agents IA. Quatre primitives sous ax.io/v1alpha1 : Task (cycle de vie, contraintes sandbox), Workspace (montage Git, serveurs MCP, skill bundles, bootstrap), Gateway (allowlist egress + injection de credentials), Model (paramètres fournisseur LLM et secrets). Sous-jacent : Agent Substrate — acteurs stateful multiplexés, checkpoint/suspend à l’idle, reprise sous la seconde sans cold start.
CLI Go (ax apply, ax watch, ax ssh, ax suspend/resume) ; déploiement plan de contrôle sur Kubernetes via ko + Redis dans le namespace ax-system. Positionnement : primitive de compute pour flottes agentiques (sandboxes gVisor), pas un framework applicatif type LangGraph/CrewAI. Discussions HN : louanges sur le coût des agents idle vs critiques sur la lourdeur ops (clusters, CRD, registries).
RustyTux : PoC public pour CVE-2026-23239 (race espintcp_close, CVSS 7.8)
SecurityOnline 25.09 : un chercheur publie RustyTux, preuve de concept de privilege escalation locale visant une use-after-free dans le chemin ESP-in-TCP du noyau Linux (net/xfrm/espintcp.c). CVE-2026-23239 (introduite en 5.6, commit e27cca96…) : après cancel_work_sync() dans espintcp_close(), espintcp_tx_work() peut encore être planifié (ex. Delayed ACK / ksoftirqd) et déréférencer un ctx ou sk déjà libéré. Correctif amont : remplacer par disable_work_sync() (stables 6.12.75, 6.18.16, 6.19.6, 7.0-rc2).
PoC timing-sensitive confirmé sur CentOS Stream 9 (noyau 5.14.0-745.el9) et signalé présent sur Ubuntu 26.04 LTS standards ; variante crash-only (DoS local). Pas d’exploitation in-the-wild confirmée (SecurityOnline / EPSS bas). Action : paquets noyau distro + reboot ; restreindre l’accès local partagé tant que non patché.
ESP-in-TCP : pourquoi cancel_work_sync ne ferme pas vraiment le socket
CVE-2026-23239 et le PoC RustyTux (25.09) rappellent une leçon classique du noyau : « annuler le work » n’est pas « interdire tout futur schedule ». Atelier sur le mécanisme — race close vs parser de réception — sans recette d’exploitation.
Contexte protocole. ESP-in-TCP (RFC 8229) encapsule IPsec ESP dans un flux TCP pour traverser NAT/firewall hostiles au protocole 50. Sous Linux, net/xfrm/espintcp.c s’appuie sur strparser (stream parser) : messages découpés dans le flux TCP, timers et workqueues pour le TX asynchrone (espintcp_tx_work).
La race. Sur espintcp_close(), le code appelait cancel_work_sync(&ctx->work). Cela attend la fin d’un work déjà en cours et le retire de la file — mais n’empêche pas un autre chemin de rappeler schedule_work() juste après. Scénario amont (Greg KH / linux-cve-announce) : CPU0 ferme et cancel ; CPU1, via espintcp_write_space() (Delayed ACK, ksoftirqd…), replanifie le même work. Le worker tourne alors sur un espintcpctx / sk déjà libéré → use-after-free.
cancel vs disable. La famille *_work_sync du kernel distingue : cancel_work_sync = « retire et attends » ; disable_work_sync = « retire, attends, et marque le work comme définitivement inéligible au schedule ». Le correctif CVE remplace le cancel par un disable sur le chemin de close. C’est le même pattern que pour d’autres UAF workqueue : la synchronisation de teardown doit fermer la porte aux re-schedules tardifs, pas seulement drainer la queue courante.
Strparser dans le tableau. Le PoC public (SecurityOnline) décrit une fenêtre où le parser de réception est encore actif pendant le teardown : rearmer un timer de message après strp_done() élargit la race jusqu’à libérer le contexte pendant qu’un autre chemin l’utilise. Variante crash-only = DoS local non privilégié ; la montée en privilège complète est timing-sensitive et dépend du reclaim mémoire — hors scope Atelier.
Leçon Atelier. Tout objet partagé entre softirq / workqueue / close socket doit avoir une sémantique de « shutdown irréversible ». Auditer les cancel_work_sync sur chemins de destruction : s’il existe encore un schedule_work reachable après le cancel (write_space, timers, ACK retardés), c’est un candidat UAF. Préférer disable_work_sync (ou équivalent refcount + flag mort) quand le work ne doit plus jamais repartir. Appliquer le paquet noyau distro et rebooter ; ne pas cherry-picker un seul commit hors série stable.
Z.ai open-source ZCode après upload silencieux des workspaces
The Register 22.09 : Z.ai s’excuse et publie ZCode en Apache 2.0 après confirmation que certaines versions (dont 3.12.3) empaquetaient workspaces et historiques Git, les chiffraient et les poussaient vers Alibaba Cloud. v3.14.0 retire Repo Wiki / snapshot-upload ; audits CAICT / NSFOCUS cités pour suppression du bucket. Dépôt initial à deux commits seulement — historique d’implémentation retiré non disponible.
CISA KEV : trois CVE noyau Linux sous BOD 26-04 (délai 3 jours passé)
Qualys 23.09 : le 18.09, CISA ajoute au catalogue KEV CVE-2025-39682 (TLS zero-length record), CVE-2026-53266 (ebtables SNAT OOB write) et CVE-2025-39964 (race AF_ALG). Sous BOD 26-04 : 3 jours pour CVE-2025-39682 (tous actifs) ; pour les deux autres, 3 j si exposés / 14 j internes — échéance 3 jours du 21.09 passée. Red Hat confirme exploits publics et exploitation active ; triage forensique demandé. Patch noyau distro + reboot.
