Una vulnerabilidad en los servicios de contenedores de Cloudflare ha puesto en evidencia los riesgos latentes del almacenamiento compartido en infraestructuras multiinquilino. El fallo, corregido en septiembre de 2026, permit\u00eda a un atacante con una cuenta Workers de pago recuperar datos residuales de otros clientes alojados en el mismo servidor f\u00edsico. Aunque Cloudflare asegura que no hubo exposici\u00f3n real de informaci\u00f3n de clientes, el incidente revela c\u00f3mo detalles sutiles en la gesti\u00f3n de bloques de almacenamiento pueden quebrantar las barreras de aislamiento entre inquilinos.<\/p>\n
Cloudflare Containers es un servicio disponible dentro del plan Workers Paid que permite a los desarrolladores ejecutar aplicaciones containerizadas directamente en la infraestructura de Cloudflare, junto a los Cloudflare Workers. Es una plataforma utilizada por empresas y desarrolladores para ejecutar servicios backend, procesar trabajos por lotes y entornos de ejecuci\u00f3n de c\u00f3digo. Al tratarse de un entorno compartido, el aislamiento entre distintos clientes \u2014la separaci\u00f3n de datos y recursos\u2014 es un pilar fundamental de seguridad. La vulnerabilidad descubierta por el investigador Oren Yomtov, de la empresa Accomplish, demostr\u00f3 que ese aislamiento pod\u00eda romperse mediante un fallo en la gesti\u00f3n del almacenamiento subyacente.<\/p>\n
El origen del problema resid\u00eda en un pool de almacenamiento compartido configurado para omitir la puesta a cero de los bloques reutilizados de 64 KiB. En t\u00e9rminos pr\u00e1cticos, cuando se eliminaba el volumen thin que respaldaba el disco ra\u00edz de un contenedor, sus bloques f\u00edsicos volv\u00edan a un pool que serv\u00eda a cargas de trabajo de distintas cuentas de clientes. Al asignar esos bloques a un nuevo contenedor, el sistema no sobrescrib\u00eda todo el bloque con ceros, sino que solo escrib\u00eda los datos necesarios en la regi\u00f3n solicitada.<\/p>\n
El exploit funcionaba de la siguiente manera: los investigadores escrib\u00edan \u00fanicamente 4 KiB en una regi\u00f3n no utilizada del disco de un nuevo contenedor. Esta operaci\u00f3n forzaba la asignaci\u00f3n de un bloque f\u00edsico reutilizado de 64 KiB. Como el bloque no hab\u00eda sido puesto a cero, solo los primeros 4 KiB eran sobrescritos por la nueva escritura; los 60 KiB restantes segu\u00edan conteniendo los datos del cliente anterior. De esta forma, un atacante pod\u00eda leer fragmentos de informaci\u00f3n residual de otros clientes sin necesidad de romper ninguna autenticaci\u00f3n adicional.<\/p>\n
La vulnerabilidad aprovechaba un pool de almacenamiento compartido que no limpiaba los bloques de 64 KiB al reasignarlos entre distintos contenedores. Al escribir solo 4 KiB en un bloque reutilizado, los 60 KiB restantes permanec\u00edan intactos, permitiendo la lectura de datos residuales de otros clientes. El fallo fue reportado por el investigador Oren Yomtov a trav\u00e9s de HackerOne el 4 de septiembre de 2026 y fue corregido por Cloudflare el 19 de septiembre de ese mismo a\u00f1o.<\/p>\n
Oren Yomtov, investigador de seguridad en Accomplish, report\u00f3 el fallo a trav\u00e9s de HackerOne el 4 de septiembre. Para demostrar la vulnerabilidad, el equipo realiz\u00f3 pruebas sobre la infraestructura de Cloudflare. Encontraron material residual en 18 de las 24 ubicaciones de contenedores probadas y en 20 de los 22 nodos subyacentes analizados. Los datos recuperables inclu\u00edan estructuras de directorios, p\u00e1ginas de bases de datos y bases de datos SQLite completas desde el punto de vista estructural.<\/p>\n
Seg\u00fan la divulgaci\u00f3n de Cloudflare, un atacante podr\u00eda haber accedido a archivos de otros clientes, como listados de directorios, bases de datos SQLite, perfiles de Chromium, archivos .env y archivos de credenciales. La explotaci\u00f3n exitosa habr\u00eda cruzado la frontera de aislamiento entre inquilinos y podr\u00eda haber expuesto metadatos del sistema de archivos, estructuras de directorios, p\u00e1ginas de bases de datos y datos de aplicaciones. Sin embargo, el atacante no tendr\u00eda control sobre la v\u00edctima o el servidor, ni podr\u00eda leer un disco que estuviera activamente montado y en uso.<\/p>\n
Cloudflare aclar\u00f3 que los investigadores utilizaron scripts que solo realizaban comprobaciones y devolv\u00edan recuentos agregados, no el contenido real de los discos. Por lo tanto, no se expusieron datos reales de clientes durante esta evaluaci\u00f3n. Tampoco se demostr\u00f3 ninguna capacidad para modificar datos de otros clientes o interferir con sus cargas de trabajo en el servicio de Cloudflare.<\/p>\n
Tras examinar registros, telemetr\u00eda y datos hist\u00f3ricos, la compa\u00f1\u00eda no encontr\u00f3 evidencia de que los datos de los clientes hubieran sido expuestos mediante el m\u00e9todo descrito por Accomplish. No obstante, la mera existencia de la vulnerabilidad subraya la importancia de los procesos de zeroing en entornos multiinquilino, especialmente cuando se utiliza almacenamiento thin provisioned.<\/p>\n
| Tipo de dato<\/th>\n | Descripci\u00f3n<\/th>\n | Frecuencia en las pruebas<\/th>\n<\/tr>\n |
|---|---|---|
| Estructuras de directorios<\/td>\n | Listados de archivos y carpetas de otros contenedores<\/td>\n | Com\u00fan (18 de 24 contenedores)<\/td>\n<\/tr>\n |
| P\u00e1ginas de bases de datos<\/td>\n | Fragmentos de bases de datos SQLite y otros motores<\/td>\n | Com\u00fan (18 de 24 contenedores)<\/td>\n<\/tr>\n |
| Bases de datos SQLite completas estructuralmente<\/td>\n | Archivos de bases de datos con esquemas y datos parciales<\/td>\n | Observado en m\u00faltiples nodos<\/td>\n<\/tr>\n |
| Archivos .env y de credenciales<\/td>\n | Variables de entorno y claves de acceso<\/td>\n | Potencialmente expuestos<\/td>\n<\/tr>\n |
| Perfiles de Chromium<\/td>\n | Datos de navegaci\u00f3n y sesiones almacenadas<\/td>\n | Potencialmente expuestos<\/td>\n<\/tr>\n<\/table>\nLa respuesta de Cloudflare: parche autom\u00e1tico y medidas correctivas<\/h2>\nCloudflare actu\u00f3 con rapidez tras recibir el reporte. El 19 de septiembre de 2026, la compa\u00f1\u00eda complet\u00f3 todas las acciones de mitigaci\u00f3n. En concreto, elimin\u00f3 la configuraci\u00f3n que provocaba la omisi\u00f3n del zeroing de bloques, retir\u00f3 los discos de contenedores existentes y limpi\u00f3 las instant\u00e1neas en cach\u00e9 que pudieran contener asignaciones antiguas. Todas estas correcciones se aplicaron autom\u00e1ticamente a la infraestructura, sin que los clientes necesitaran realizar ninguna acci\u00f3n para protegerse.<\/p>\n La empresa tambi\u00e9n afirm\u00f3 que no encontr\u00f3 evidencia de que los datos de los clientes hubieran sido comprometidos. Aun as\u00ed, la vulnerabilidad representa un recordatorio de que incluso los proveedores de infraestructura m\u00e1s sofisticados pueden tener puntos ciegos en la gesti\u00f3n del almacenamiento compartido.<\/p>\n Implicaciones para la seguridad en la nube y lecciones aprendidas<\/h2>\nEl caso de Cloudflare Containers ilustra un desaf\u00edo fundamental en la virtualizaci\u00f3n y los contenedores: el aislamiento a nivel de almacenamiento. Mientras que la mayor\u00eda de los proveedores se centran en asegurar el hipervisor o el runtime de contenedores, la capa de almacenamiento puede convertirse en un vector de ataque si no se gestiona con el mismo rigor. La omisi\u00f3n del zeroing en bloques reutilizados es un error cl\u00e1sico de configuraci\u00f3n que puede tener consecuencias graves en entornos multiinquilino.<\/p>\n Para las empresas que utilizan Cloudflare Workers, esta vulnerabilidad no represent\u00f3 un riesgo material dado que fue corregida antes de que pudiera ser explotada de forma maliciosa. Sin embargo, el incidente refuerza la necesidad de revisar las pol\u00edticas de seguridad de los proveedores de nube, especialmente en lo relativo a la limpieza de datos entre inquilinos. La transparencia con la que Cloudflare divulg\u00f3 el fallo \u2014publicando un informe t\u00e9cnico detallado y confirmando la rapidez de la correcci\u00f3n\u2014 es un ejemplo positivo de c\u00f3mo gestionar este tipo de incidentes.<\/p>\n Desde una perspectiva m\u00e1s amplia, la vulnerabilidad subraya que el modelo de responsabilidad compartida en la nube no solo aplica a la configuraci\u00f3n de los clientes, sino tambi\u00e9n a las decisiones internas de los proveedores sobre c\u00f3mo gestionan recursos como el almacenamiento. Los desarrolladores que construyen aplicaciones sobre Workers Paid deben confiar en que el proveedor mantiene un aislamiento robusto; este incidente demuestra que esa confianza debe ser verificada peri\u00f3dicamente, tanto por parte del proveedor como mediante investigaciones externas como la de Accomplish.<\/p>\n El futuro de la seguridad en plataformas serverless y de contenedores pasar\u00e1 inevitablemente por auditor\u00edas m\u00e1s profundas del comportamiento del almacenamiento subyacente. Herramientas como las pruebas de fuzzing en la capa de bloques o la verificaci\u00f3n sistem\u00e1tica del zeroing post-eliminaci\u00f3n podr\u00edan convertirse en est\u00e1ndares de la industria. Mientras tanto, la comunidad de seguridad y los equipos de infraestructura pueden extraer una lecci\u00f3n clara de este caso: nunca asumir que un bloque reutilizado est\u00e1 limpio a menos que se haya verificado expl\u00edcitamente que se ha puesto a cero.<\/p>\n","protected":false},"excerpt":{"rendered":" Una vulnerabilidad en los servicios de contenedores de Cloudflare ha puesto en evidencia los riesgos latentes del almacenamiento compartido en infraestructuras multiinquilino. El fallo, corregido en septiembre de 2026, permit\u00eda a un atacante con una cuenta Workers de pago recuperar datos residuales de otros clientes alojados en el mismo servidor f\u00edsico. Aunque Cloudflare asegura que […]<\/p>\n","protected":false},"author":2,"featured_media":70053,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/es\/70052.png","fifu_image_alt":"Cloudflare elimina fallo en Containers que expone datos de clientes","footnotes":""},"categories":[5],"tags":[],"class_list":["post-70052","post","type-post","status-publish","format-standard","has-post-thumbnail","category-tecnologia"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/es\/70052.png","fifu_image_alt":"Cloudflare elimina fallo en Containers que expone datos de clientes","_links":{"self":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts\/70052","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/comments?post=70052"}],"version-history":[{"count":1,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts\/70052\/revisions"}],"predecessor-version":[{"id":70054,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts\/70052\/revisions\/70054"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/media\/70053"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/media?parent=70052"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/categories?post=70052"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/tags?post=70052"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} |