- Terrarium és un sandbox de Python basat en Pyodide i desplegable a Cloud Run, dissenyat per executar codi no fiable amb baix cost i latència acceptable.
- L'entorn ofereix compartimentació per invocació, suport de múltiples llibreries científiques i maneig de fitxers d'entrada i sortida mitjançant un sistema de fitxers virtual.
- La seva arquitectura combina WebAssembly, Node.js, Docker i Cloud Run per aïllar el codi, però s'han detectat problemes d'estabilitat i de gestió de salut del servei.
- La vulnerabilitat crítica CVE-2026-5752 permet executar codi amb privilegis de root, sense pegat previst, per la qual cosa es recomana avaluar mitigacions i alternatives.
Quan parlem d'executar codi Python no fiable o generat per una IA , un dels grans maldecaps és com fer-ho de forma segura , ràpida i sense arruïnar-se en infraestructura. En aquest context va aparèixer Terrarium, una solució de Cohere AI pensada com a sandbox per allotjar i executar aquest tipus de codi dins de contenidors desplegats al núvol, especialment a Google Cloud Run.
Aquest enfocament permetia que desenvolupadors i empreses poguessin aprofitar Terrarium com un entorn aïllat on llançar codi d'usuaris o de models LLM , amb un cost força ajustat i un rendiment raonablement bo. Tot i això, amb el temps també han sortit a la llum vulnerabilitats molt serioses , incloent-hi una amb identificador CVE que exposa errors crítics en la seguretat del sandbox i que ha posat Terrarium al punt de mira.
Què és Terrarium i per què es va dissenyar
Terrarium és, en essència, un entorn d'execució aïllat per a Python , pensat per funcionar com un contenidor Docker desplegable , per exemple, a Google Cloud Run. El seu objectiu principal és oferir un sandbox on llençar codi potencialment perillós o desconegut (com scripts enviats per usuaris o fragments generats per models de llenguatge) sense posar en risc directe la infraestructura principal.
La filosofia darrere el projecte se centra a disposar d'un servei econòmic, de baixa latència i fàcil d'integrar en fluxos ja existents. Terrarium es va concebre per ser anomenat mitjançant peticions HTTP, enviant el codi Python a executar -i opcionalment fitxers d'entrada- i rebent de tornada el resultat de l'execució juntament amb els fitxers generats.
A la pràctica, això es tradueix que un sistema extern, una API o fins i tot una eina interna pot delegar l'execució de codi Python a Terrarium , mantenint aquest codi dins d'un entorn relativament acotat, amb regles clares sobre recursos, temps d'execució i capacitats permeses.
Un dels punts clau del disseny és que Terrarium es recolza en Pyodide, una compilació de CPython a WebAssembly executada dins un procés de Node.js. Gràcies a aquest enfocament, el codi Python no s'executa de forma nativa al sistema amfitrió, sinó dins d'un intèrpret encapsulat, cosa que en teoria reforça l'aïllament.
Rendiment, costos i característiques principals del sandbox
Un dels grans arguments a favor de Terrarium era la seva combinació de baix cost operatiu i rendiment acceptable . En desplegaments reals sobre Google Cloud Run, amb una configuració típica de 2 GB de memòria, 1 vCPU i almenys una instància sempre activa amb autoescalat sota demanda, el cost mensual reportat rondava els 30 dòlars durant fases internes d'anotació.
En termes de velocitat, les proves descrites mostren que Terrarium podia generar, per exemple, una imatge PNG a 200 dpi d'un gràfic senzill de matplotlib al voltant dels 900 ms de temps d'execució, o una versió a SVG en aproximadament 500 ms. Aquests temps es refereixen al codi allotjat a Cloud Run, incloent-hi el cicle d'invocació típic del servei.
A més del rendiment, Terrarium presumia d'estar totalment compartimentat entre invocacions . Després de cada trucada, el sandbox es reciclava completament: es descartaven el sistema de fitxers virtual de Pyodide, les variables globals, les llibreries carregades i qualsevol tipus d'estat intern. L'objectiu era que cap invocació heretés dades o context d'una execució anterior, reduint així el risc de filtratge d'informació.
Un altre punt important és que, encara que es buscava un aïllament sòlid, Cohere deixava clar que no oferia garanties absolutes sobre la integritat del sandbox . Això ja insinuava que, malgrat les capes de protecció, hi havia la possibilitat que es descobrissin debilitats, especialment en un entorn tan complex com el de WebAssembly i la integració amb Node.js.
Terrarium estava pensat per ser senzill de consumir des d'altres serveis: n'hi havia prou amb fer una petició HTTP a l'endpoint desplegat a Cloud Run, enviant el codi a executar i un token d'autorització (si la configuració així ho requeria). A canvi s'obtenia un JSON amb els resultats i, si escau, els fitxers generats codificats en base64.
Execució d'arxius i suport de llibreries a Pyodide
Un dels atractius de Terrarium era la seva capacitat per treballar amb fitxers d'entrada i sortida de forma nativa . L'API permetia adjuntar múltiples fitxers de qualsevol tipus juntament amb el codi Python a la petició; aquests es col·locaven al sistema de fitxers virtual que Pyodide exposa a l'intèrpret de Python.
Durant l'execució, el codi Python podia llegir i manipular aquests fitxers com si fossin locals dins de la sandbox. Un cop finalitzada l'execució, Terrarium s'encarregava de recopilar tots els fitxers creats o modificats i tornar-los a la resposta al client, normalment codificats per ser transferits sobre HTTP sense problemes.
Pel que fa a l'ecosistema de llibreries, en basar-se en Pyodide, Terrarium heretava un conjunt força ampli de paquets científics i d'anàlisi de dades . Entre els suportats de forma directa s'inclouen: numpy, pandes, matplotlib, sympy, beautifulsoup4, python-sat, scikit-learn, scipy i sqlite3 (aquest últim no habilitat per defecte, però amb la possibilitat de carregar-lo si cal).
En el cas concret de matplotlib, hi havia algunes limitacions: no se suportava plt.show() en aquest entorn, però sí que funcionava correctament l'ús de plt.savefig() per generar imatges, sempre que no es forçassin paràmetres excessius, com a resolucions extremadament altes que disparessin l'ús de recursos.
Aquest conjunt de llibreries feia que Terrarium fos especialment útil per a tasques danàlisi de dades, visualització, prototipat de models de machine learning i manipulació dinformació estructurada, tot això executat dins un sandbox teòricament controlat.
Arquitectura interna: capes d'aïllament i desplegament
L'arquitectura de Terrarium està construïda per diverses capes pensades per reduir la superfície d'atac i aïllar al màxim el codi no fiable . La primera capa és el mateix procés de Node.js, que actua com a amfitrió i en què es carrega Pyodide, és a dir, CPython compilat a WebAssembly.
El codi Python enviat per l'usuari es parseja, compila i executa dins d'aquest entorn WebAssembly , no de manera nativa sobre el sistema amfitrió. Aquesta aproximació limita dentrada el que el codi pot fer, ja que Pyodide disposa dun sistema de fitxers virtual en memòria, no té accés directe al disc del host i manca de capacitats de processos en segon pla tradicionals.
Entre les restriccions més rellevants s'inclouen: sense accés al sistema de fitxers real (només al virtual intern de Pyodide), absència total de threading i multiprocessing, impossibilitat de llançar subprocessos, sense accés a la memòria del host que executa Node.js, sense compartir estat entre trucades (ja que es reinicia completament l'entorn) i, per disseny . Aquesta darrera limitació es plantejava com una decisió de disseny que es podria revisar en el futur, però que inicialment afegia una capa més de contenció.
La segona capa d'aïllament és el propi desplegament al núvol: el procés de Node.js s'executa dins d'un contenidor Docker , que es desplega a Google Cloud Run. Això no només fixa límits al temps d'execució i als recursos disponibles, sinó que també desacobla el contenidor que executa el codi de qualsevol altra part de la infraestructura de l'organització en cas d'una fuita hipotètica del sandbox.
En resum, el disseny original de Terrarium confia en la combinació de WebAssembly, Docker i Cloud Run per construir un entorn relativament blindat on allotjar l'execució de Python, amb barreres successives que compliquen la fugida del sandbox cap al sistema amfitrió i la xarxa interna.
Desplegament local, a Docker ia Google Cloud Run
Per utilitzar Terrarium en un entorn de desenvolupament, calia comptar amb Node.js instal·lat a la màquina . Un cop satisfet aquest requisit, el procediment habitual consistia a instal·lar les dependències del projecte i executar el servidor local, juntament amb la funció que fa de manejador de les peticions d'execució de codi.
Amb el servidor en marxa, es podien fer peticions a l'endpoint local per enviar fitxers de prova i scripts Python , de manera que el desenvolupador pogués validar el comportament de la sandbox abans de passar a entorns de producció. Hi havia scripts pensats per llançar un conjunt de proves sobre tots els fitxers .py d'un directori de test, simplificant així la verificació de l'entorn.
En escenaris de contenidors, Terrarium es podia construir com a imatge Docker i executar com un contenidor independent . Les instruccions típiques incloïen els passos de build, run i stop, a més d'ordres per localitzar l'identificador del contenidor en execució i gestionar-lo manualment si cal.
Quan es feia el salt a Google Cloud Run, Terrarium es desplegava com un servei HTTP autoscalable, amb paràmetres de recursos i concurrència configurables. Era recomanable ajustar aquests valors per equilibrar rendiment, cost i seguretat . Per exemple, per a càrregues intensives es podien assignar més CPU i memòria, així com limitar la concurrència per instància per evitar bloquejos.
Cal tenir en compte que Pyodide, a la configuració de Terrarium, s'executa en el procés principal de Node.js . Això implica que, si el codi Python es torna especialment pesat o entra en bucles complexos, pot bloquejar la capacitat de Node.js per respondre altres peticions. Pyodide suggereix l'ús de Workers per a escenaris on calgui interrompre execucions o aïllar-les encara més, però aquest enfocament complica la integració i, en alguns casos, limita el suport de llibreries com a matplotlib.
Gestió de salut del servei i problemes d'estabilitat
En desplegaments sobre Google Cloud Run, un dels reptes pràctics era controlar la salut del servei i la recuperació davant de bloquejos . Cloud Run, per defecte, no suporta directament les comprovacions de salut definides a Dockerfile mitjançant HEALTHCHECK, de manera que es requeria un petit ajustament addicional.
El procediment habitual consistia a descriure el servei de Cloud Run amb gcloud , exportant la configuració a un fitxer service.yaml. Dins d'aquest YAML, s'hi afegia una configuració de livenessProbe associada a la imatge del contenidor perquè Cloud Run pogués detectar quan el servei deixava de respondre correctament.
Un cop modificada la configuració, es reemplaçava el servei existent amb l'ordre adequada de gcloud, de manera que Cloud Run passava a monitoritzar activament l'estat del contenidor ia reiniciar-lo si la comprovació de vida fallava. Aquesta operació només calia la primera vegada que es desplegava un nou servei amb aquesta imatge concreta.
A nivell de Docker pur, hi ha una limitació addicional: el mateix motor Docker no ofereix reinicis automàtics basats únicament en HEALTHCHECK . A més, el procés amb PID 1 al contenidor està especialment protegit i no és tan senzill d'acabar des de dins. Per això, en alguns entorns es planteja l'ús d'eines de tercers com ara docker-autoheal, que monitoritzen l'estat del contenidor i forcen reinicis quan detecten problemes.
Quant a l'estabilitat de les execucions, l'equip va observar que, amb certa freqüència, apareixien errors del tipus RangeError: Maximum call stack size exceeded dins de Pyodide quan es manejaven càrregues especialment pesades. Això era més habitual en utilitzar valors de dpi molt elevats en la generació de PNG amb matplotlib o en executar operacions de pandes especialment complexes, cosa que apunta a límits interns en el maneig de la pila dins de l'entorn WebAssembly.
Vulnerabilitat crítica CVE-2026-5752 a Terrarium
Amb el temps, s'ha descobert una vulnerabilitat d'enorme gravetat a Terrarium , identificada com a CVE-2026-5752 i valorada amb una puntuació de 9,3 al sistema de classificació CVSS. Aquest nivell de criticitat indica que és una fallada amb un impacte potencial molt elevat sobre la seguretat dels sistemes que utilitzin aquesta sandbox.
La debilitat permet a un atacant realitzar execució de codi arbitrari amb privilegis de root en el procés amfitrió . El vector d'atac es basa en un recorregut maliciós de la cadena de prototips de JavaScript (prototype chain traversal) dins de l'entorn de Pyodide a WebAssembly, cosa que, a la pràctica, obre la porta a saltar-se les restriccions imposades pel sandbox.
El més preocupant és que per explotar aquesta vulnerabilitat no es requereixen privilegis especials ni interacció addicional de l'usuari . Un atacant que pugui injectar codi a la sandbox (per exemple, aprofitant una funcionalitat d'execució de codi en una eina que utilitzi Terrarium) pot aprofitar aquest error per escapar de l'entorn controlat.
Un cop explotada, la vulnerabilitat podria permetre accés no autoritzat a arxius sensibles del sistema , com ara /etc/passwd o altres recursos interns del contenidor , i fins i tot possibilitar l'escalada cap al host oa altres serveis que comparteixin la mateixa infraestructura, depenent de la configuració de seguretat general.
Aquesta situació suposa un risc significatiu per a totes les organitzacions que utilitzen Terrarium com a entorn d'execució de codi d'usuaris o de models d'IA . No es tracta només d'una fallada teòrica, sinó d'un escenari on la ruptura del sandbox pot derivar en exposició de dades, compromís de serveis interns i moviments laterals dins de la xarxa.
Impacte per a empreses, desenvolupadors i usuaris finals
La troballa d'aquesta vulnerabilitat afecta directament qualsevol companyia o desenvolupador que hagi integrat Terrarium a la seva infraestructura per executar codi Python no fiable . Eines de desenvolupament col·laboratiu, plataformes d'aprenentatge, serveis d'anàlisi sota demanda o productes d'assistència de codi basats en IA podrien estar exposats si utilitzen Terrarium com a capa d'execució.
Des del punt de vista de l'usuari final, el risc no és només que el proveïdor del servei vegi compromesa la seva infraestructura, sinó que la informació personal o professional emmagatzemada en aquestes plataformes es pugui veure filtrada o manipulada sense avís previ si un atacant aconsegueix explotar la decisió.
La gravetat augmenta perquè s'ha assenyalat que Terrarium ja no es manté activament . Això vol dir que no és previsible que arribi un pegat oficial que corregeixi el problema, per la qual cosa les organitzacions que segueixin depenent d'aquesta solució es troben davant d'una eina amb una vulnerabilitat coneguda i sense suport.
En aquest context, continuar utilitzant Terrarium sense mesures addicionals suposa assumir un risc considerable en termes de seguretat . Els atacants que coneguin el vector d'explotació poden adreçar-se específicament a serveis que continuïn usant aquesta tecnologia, cercant punts febles en la protecció global del sistema.
A més, en entorns on diversos serveis comparteixen la mateixa xarxa interna o fins i tot el mateix clúster de contenidors, una fugida des de Terrarium podria obrir la porta a moviments laterals cap a altres sistemes aparentment aïllats , fet que amplifica l'impacte potencial d'un atac exitós.
Estratègies de mitigació i alternatives a considerar
Davant d'una vulnerabilitat d'aquest calibre i de l'absència de manteniment actiu, la primera recomanació per a les organitzacions és avaluar amb urgència l'ús actual de Terrarium . Si esteu utilitzant per executar codi de tercers o generat per models d'IA, l'exposició és més gran i requereix accions immediates.
Entre les mesures a curt termini s'hi inclou la possibilitat de deshabilitar temporalment les funcions que permetin executar codi arbitrari en producció mentre es valora una alternativa més segura. També es pot plantejar reforçar les polítiques de xarxa, segmentar encara més els serveis que utilitzen Terrarium i limitar l'accés al contenidor des d'altres sistemes.
A mitjà termini, pot resultar més assenyat migrar cap a altres solucions de sandboxing o execució aïllada que tinguin manteniment actiu i una comunitat o proveïdor darrere que s'encarregui de pegats vulnerabilitats. Això podria passar per serveis gestionats, entorns d'execució serverless amb restriccions més fortes o arquitectures de microserveis dissenyades específicament amb seguretat per defecte.
En qualsevol cas, aquest incident posa en relleu la importància d' integrar bones pràctiques de seguretat al cicle de vida del desenvolupament : auditories periòdiques de dependències, revisió de components de tercers utilitzats a l'arquitectura, monitorització de CVE rellevants i plans de resposta ràpida quan es detecta una fallada crítica.
Les empreses que construeixen eines basades en IA i que permeten a l'usuari final executar o generar codi haurien d' analitzar de manera molt curosa el disseny dels seus sandboxs , assegurar-se que els processos d'aïllament es mantenen actualitzats i evitar dependre de projectes abandonats per a funcions tan delicades com l'execució de codi no fiable.
Tot allò relacionat amb Terrarium reflecteix fins a quin punt executar codi d'usuaris i de models LLM exigeix un enfocament de seguretat extrem . Un sandbox amb bon rendiment i baix cost pot semblar molt atractiu, però si apareix una vulnerabilitat crítica sense perspectiva de pegat, l'equilibri es trenca i el risc passa a ser inassumible per a molts casos d'ús seriosos.
