Une faille de sécurité critique a été révélée dans Grist-Core, une version open source auto-hébergée de la base de données relationnelle Grist, qui pourrait entraîner l'exécution de code à distance.
La vulnérabilité, suivie comme CVE-2026-24002 (score CVSS : 9,1), a été nommé rupture cellulaire par les Laboratoires de recherche Cyera.
“Une formule malveillante peut transformer une feuille de calcul en une tête de pont pour l'exécution de code à distance (RCE),” a déclaré le chercheur en sécurité Vladimir Tokarev, qui a découvert la faille. “Cette évasion sandbox permet à l'auteur de la formule d'exécuter des commandes du système d'exploitation ou d'exécuter JavaScript au moment de l'exécution de l'hôte, réduisant ainsi la frontière entre la “logique cellulaire” et l'exécution de l'hôte.”
Cellbreak est classé comme un cas d'évasion de bac à sable Pyodide, le même type de vulnérabilité qui a également récemment affecté n8n (CVE-2025-68668, score CVSS : 9,9, également connu sous le nom de N8scape). La vulnérabilité a été corrigée dans la version 1.7.9, publiée le 9 janvier 2026.
“Un examen de sécurité a identifié une vulnérabilité dans la méthode d'isolation 'pyodide' disponible dans Grist”, ont indiqué les chefs de projet. “Vous pouvez vérifier si vous êtes concerné dans la section sandbox du panneau d'administration de votre instance. Si vous y voyez 'gvisor', alors vous n'êtes pas affecté. Si vous voyez 'pyodide', alors il est important de mettre à niveau vers cette version de Grist ou une version ultérieure. “
En termes simples, le problème provient de l'exécution de formules Python de Grist, qui permet d'exécuter des formules non fiables dans Pyodide, une distribution Python qui permet d'exécuter du code Python normal directement dans un navigateur Web dans les limites d'un bac à sable WebAssembly (WASM).
Bien que l'idée derrière ce processus de réflexion soit de garantir que le code de formule Python s'exécute dans un environnement isolé, le fait que Grist utilise une approche de style liste de blocage permet d'échapper au bac à sable et finalement d'exécuter des commandes sur l'hôte sous-jacent.
“La conception du bac à sable permet de parcourir la hiérarchie des classes de Python et laisse les ctypes disponibles, qui, ensemble, ouvrent l'accès aux fonctions d'exécution d'Emscripten qui ne devraient jamais être accessibles à partir d'une cellule de formule”, a expliqué Tokarev. “Cette combinaison permet l'exécution de commandes hôtes et l'exécution de JavaScript au moment de l'exécution de l'hôte, avec des résultats pratiques tels que l'accès au système de fichiers et la révélation des secrets.”
Selon Grist, lorsqu'un utilisateur définit GRIST_SANDBOX_FLAVOR sur Pyodide et ouvre un document malveillant, ce document pourrait être utilisé pour exécuter des processus arbitraires sur le serveur hébergeant Grist. Armé de cette capacité à exécuter des commandes ou du JavaScript via une formule, un attaquant peut exploiter ce comportement pour accéder aux informations d'identification de la base de données et aux clés API, lire des fichiers sensibles et présenter des opportunités de mouvement latéral.
Grist a résolu le problème en déplaçant par défaut l'exécution de la formule Pyodide vers le runtime Deno JavaScript. Cependant, il convient de noter que le risque réapparaît si un opérateur choisit explicitement de fixer GRIST_PYODIDE_SKIP_DENO à la valeur “1”. Cette configuration doit être évitée dans les scénarios dans lesquels des formules non fiables ou semi-fiables sont susceptibles d'être exécutées.
Il est recommandé aux utilisateurs de mettre à jour vers la dernière version dès que possible pour atténuer les risques potentiels. Pour atténuer temporairement le problème, il est recommandé de définir la variable d'environnement GRIST_SANDBOX_FLAVOR sur “gvisor”.
“Cela reflète le risque systémique rencontré dans d'autres plates-formes d'automatisation : une seule surface d'exécution avec un accès privilégié peut faire tomber les frontières de confiance de l'organisation en cas de défaillance de son environnement de test”, a déclaré Tokarev.
« Lorsque l'exécution d'une formule dépend d'un bac à sable permissif, une seule évasion peut transformer la « logique des données » en « exécution de l'hôte ». Les conclusions de Grist-Core montrent pourquoi le bac à sable devrait être basé sur les capacités et la défense en profondeur, et non sur une liste de blocage fragile. Le coût d'un échec n'est pas seulement une erreur : c'est une violation dans le plan des données.
