Cuando tu base de datos vectorial entrega RCE pre-autenticación, RAG tiene un problema en la capa de datos
El 18 de mayo de 2026, HiddenLayer publicó una investigación sobre ChromaToast — formalmente CVE-2026-45829. Puntuación CVSS: 10.0. Vector de ataque: red. Privilegios requeridos: ninguno. Interacción del usuario: ninguna. La vulnerabilidad reside en el controlador create_collection del servidor Python FastAPI de ChromaDB: el servidor confía en los identificadores de modelo proporcionados por el cliente y actúa en consecuencia — incluyendo la carga de código desde repositorios externos de HuggingFace con trust_remote_code en true — antes de que se realice la verificación de autenticación. Un atacante no autenticado envía una solicitud HTTP, el servidor descarga y ejecuta código de modelo controlado por el atacante, y el resultado es la ejecución arbitraria de código con acceso a claves API, variables de entorno, secretos montados y cualquier archivo que el proceso del servidor pueda leer.
El escaneo de HiddenLayer basado en Shodan encontró aproximadamente el 73% de las implementaciones expuestas. HiddenLayer informa el primer contacto con el proyecto Chroma el 17 de febrero de 2026, con seguimientos documentados el 24 de febrero, 5 de marzo y 16 de abril — sin recibir respuesta. El investigador independiente Azraelxuemo reportó la misma vulnerabilidad en noviembre de 2025 y tampoco recibió respuesta. La mitigación temporal es la restricción de red. No existe parche.
5 conclusiones clave
1. ChromaToast es un RCE pre-auth CVSS 10.0 activo.
HiddenLayer divulgó CVE-2026-45829 el 18 de mayo de 2026, afectando todas las versiones del servidor Python FastAPI de ChromaDB desde la 1.0.0. Aproximadamente el 73% de las implementaciones accesibles por Internet son explotables. No hay parche disponible. Capital One y UnitedHealthcare aparecen en la página principal de Chroma. No es una herramienta marginal — es infraestructura que ejecuta RAG a gran escala, y la respuesta al incidente comienza sin una vía de solución.
2. El error revela una falla arquitectónica más profunda en RAG.
ChromaDB tiene 13 millones de descargas mensuales por pip y respalda flujos de trabajo RAG en producción en Mintlify, Factory AI y Weights & Biases. Cuando la base de datos que almacena embeddings, prompts y documentos recuperados es explotable pre-auth, todos los secretos que el proceso del servidor puede leer están en riesgo — claves API, variables de entorno, credenciales montadas y todo lo conectado a ellas. No es una vulnerabilidad en la capa de aplicación. Es una vulnerabilidad en la capa de infraestructura de datos subyacente.
3. La explotación de vulnerabilidades es ahora el vector de brecha dominante por primera vez en 19 años.
El informe DBIR de Verizon 2026 reporta que el 31% de las brechas provienen de vulnerabilidades sin parchear frente al 13% por abuso de credenciales — la primera vez en la historia del informe que la explotación lidera. IBM X-Force informa que la explotación de aplicaciones expuestas públicamente aumentó un 44% interanual, con el 56% de las vulnerabilidades divulgadas sin requerir autenticación para ser explotadas. La infraestructura RAG es un objetivo real bajo esta dinámica, no un caso hipotético.
4. La mayoría de las empresas carecen de una capa de datos de IA gobernada.
Solo el 43% de las organizaciones operan hoy una puerta de enlace de datos IA centralizada. El 57% funciona con controles fragmentados, parciales o nulos. El 90% de las organizaciones gubernamentales y el 77% de las de salud carecen totalmente de centralización. La velocidad de implementación de IA supera la madurez de la gobernanza — y ChromaToast es el resultado de esa brecha en un entorno productivo.
5. La respuesta arquitectónica es gobernar los datos, no parchear la infraestructura.
Cuando los flujos RAG acceden a los datos empresariales a través de una puerta de enlace gobernada con acceso de confianza cero, aplicación de ABAC, cifrado FIPS 140-3 y registros de auditoría inviolables, un RCE pre-auth en cualquier componente no se traduce en una filtración de datos. La vulnerabilidad se convierte en un problema de contención, no de exfiltración.
Confías en que tu organización es segura. Pero ¿puedes verificarlo?
Leer ahora
Por qué un RCE pre-auth en una base de datos vectorial es un problema diferente
Las fallas RCE pre-autenticación ocurren. Lo que hace que esta sea diferente a nivel arquitectónico es el lugar que ocupa ChromaDB en la tecnología de IA. Una base de datos vectorial en un flujo RAG está junto al material más sensible del sistema: embeddings de documentos empresariales, fragmentos recuperados que fundamentan respuestas del modelo, prompts que pueden contener datos regulados y secretos de aplicación necesarios para acceder a fuentes de datos aguas arriba. Cuando se compromete la base de datos vectorial, el radio de impacto es todo el flujo RAG — los embeddings revelan el contenido de los documentos, los prompts almacenados pueden incluir información personal identificable, información de salud protegida o información no clasificada controlada, y las claves API acceden a todo lo que puedan alcanzar.
La falla más profunda es arquitectónica. La suposición de confianza en el servidor Python de ChromaDB — que es aceptable descargar y ejecutar código de modelo desde un registro externo antes de verificar quién lo solicita — es la misma suposición de confianza que se repite en la mayoría de las implementaciones RAG actuales. La capa de recuperación se trata como simple infraestructura y no como acceso gobernado a datos empresariales. Cuando la infraestructura tiene un RCE pre-auth, la gobernanza construida solo en la capa de aplicación superior no puede compensar. La infraestructura de IA es infraestructura de datos, y los mismos controles que determinan quién puede leer una carpeta sensible deben determinar quién — o qué — puede consultar un almacén de embeddings, montar un artefacto de modelo o invocar una herramienta mediante un runtime de agente.
La explotación de vulnerabilidades es ahora el vector de brecha que debe preocuparte
El informe DBIR de Verizon 2026 indica que la explotación de vulnerabilidades superó al robo de credenciales por primera vez en 19 años. Las vulnerabilidades sin parchear representaron el 31% de las brechas; el abuso de credenciales cayó al 13%. Las organizaciones solo parchearon el 26% del catálogo de vulnerabilidades explotadas conocidas de CISA en 2025, frente al 38% en 2024. El tiempo medio hasta el parcheo completo subió a 43 días desde 32. El ritmo de remediación del defensor se está ralentizando justo cuando el ritmo de explotación del atacante se acelera.
El Índice de Inteligencia de Amenazas IBM X-Force 2026 suma la dimensión de aplicaciones expuestas públicamente: la explotación de aplicaciones públicas aumentó un 44% interanual, la explotación de vulnerabilidades representó el 40% de los incidentes observados y el 56% de las vulnerabilidades divulgadas no requerían autenticación para ser explotadas. Las bases de datos vectoriales son aplicaciones públicas cuando se autoalojan con un puerto accesible por red — exactamente el patrón de implementación que mide el 73% de exposición según HiddenLayer.
Los adversarios de IA son más rápidos que los parches
Una segunda tendencia paralela al auge de la explotación de vulnerabilidades agrava el patrón de ChromaToast. El Instituto de Seguridad de IA del Reino Unido informa que la dificultad de las tareas cibernéticas que los modelos de IA de frontera pueden completar se duplicaba cada ocho meses a finales de 2025 y cada 4,7 meses en febrero de 2026. El Índice de IA de Stanford 2026 reporta que las tasas de resolución sin guía en el benchmark de ciberseguridad Cybench subieron del 15% en 2024 al 93% en 2025.
La divulgación GTG-1002 de Anthropic de noviembre de 2025 lo hace tangible: un grupo patrocinado por el Estado chino usó Claude Code más herramientas MCP para orquestar entre el 80% y el 90% del trabajo táctico de una campaña de ciberespionaje multiobjetivo contra unas 30 entidades — reconocimiento, descubrimiento de vulnerabilidades, explotación, movimiento lateral, recolección de credenciales — todo ejecutado por IA. Compáralo con la cronología de la divulgación de ChromaDB: HiddenLayer contactó por primera vez a Chroma el 17 de febrero de 2026, hizo tres seguimientos más hasta abril y no recibió respuesta. La vulnerabilidad es pública, la lógica de la prueba de concepto está documentada, no existe parche. El reloj del defensor no avanza. El del atacante ahora se mide en ciclos de computación.
Dónde están la mayoría de las empresas en gobernanza de datos de IA
Solo el 43% de las organizaciones operan una puerta de enlace de datos IA centralizada. El 27% depende de controles distribuidos con políticas. El 19% tiene controles parciales o ad hoc. El 7% no tiene controles de IA dedicados. El sector público está en un 90% sin centralización; salud en 77%; servicios financieros en 60%. Estas cifras describen la población expuesta al patrón ChromaToast. Una organización con puerta de enlace centralizada tiene un punto arquitectónico donde aplicar autenticación, autorización, cifrado y auditoría para cada interacción de datos de IA. Una organización con controles parciales o nulos tiene una proliferación de bases de datos vectoriales, almacenes de embeddings y runtimes de agentes — cada uno es una superficie pre-auth esperando ser descubierta.
La respuesta arquitectónica: gobierna la capa de datos, no el componente
La alternativa arquitectónica es tratar el acceso a datos de IA como la seguridad empresarial lo ha hecho durante una década: confianza cero en la capa de datos, con cada solicitud autenticada, autorizada según la política y auditada sin importar qué componente la origine.
Kiteworks Secure MCP Server y la puerta de enlace de datos IA implementan este patrón. Los flujos RAG consultan los datos empresariales a través de un puente gobernado. Los asistentes de IA acceden a archivos mediante el Model Context Protocol con autenticación OAuth 2.0 — los tokens quedan en el llavero del sistema operativo, nunca llegan al modelo. Las políticas ABAC evalúan cada operación en tiempo real. El rate limiting previene la extracción masiva incluso si un componente aguas arriba está comprometido. El cifrado validado FIPS 140-3, la validación TLS y un dispositivo virtual reforzado protegen todo el recorrido. Cada interacción se registra en tiempo real en SIEM mediante una auditoría inviolable.
La prueba arquitectónica es sencilla: si mañana se comprometiera la base de datos vectorial, ¿cuál sería el radio de impacto? En una arquitectura con puerta de enlace gobernada, la respuesta la limita la política ABAC, no las credenciales que el componente comprometido tuviera. Kiteworks Private Data Network extiende esto a correo electrónico, uso compartido de archivos, MFT, SFTP, formularios web, APIs e integraciones de IA bajo un único motor de políticas y un registro de auditoría consolidado.
Qué deben hacer los responsables de seguridad este trimestre
Primero, inventaría cada base de datos vectorial, almacén de embeddings y runtime de agente que acceda a datos empresariales. Mapea el modelo de autenticación de cada componente, su exposición en red y las credenciales a las que puede acceder. La mayoría de los equipos de seguridad tienen una visión incompleta porque la infraestructura de IA fue implementada por equipos de ciencia de datos sin una entrada en el CMDB.
Segundo, trata la infraestructura de IA como infraestructura de producción para la gestión de vulnerabilidades. Aplica los mismos SLA de parches, disciplina de gestión de exposición y priorización basada en KEV. El hallazgo del DBIR 2026 de que las organizaciones solo parchearon el 26% de las vulnerabilidades listadas en KEV aplica a los componentes de IA igual que a la infraestructura tradicional.
Tercero, canaliza el acceso a datos de RAG y agentes a través de una puerta de enlace de datos IA gobernada. Solo el 43% de las organizaciones lo han hecho. El 57% restante enfrenta el patrón ChromaToast multiplicado por cada carga de trabajo de IA que ejecutan. La centralización en la capa de datos convierte docenas de superficies de ataque a nivel de componente en un solo plano de control gobernado.
Cuarto, exige acceso a datos de confianza cero para los agentes de IA igual que para los usuarios humanos. Cada solicitud de datos de IA autenticada, autorizada según la política, limitada en tasa, cifrada y registrada con atribución completa. El Índice de IA de Stanford 2026 informa que las preocupaciones de seguridad y riesgo son la principal barrera para escalar la IA agente, citadas por el 62% de las organizaciones — el acceso a datos de confianza cero es la variable controlable.
Quinto, instrumenta la capa de datos de IA para visibilidad en SIEM. Un RCE pre-auth, por definición, no produce registros de autenticación. La visibilidad debe venir desde arriba — desde la puerta de enlace que media cada interacción de datos. Los feeds en tiempo real de acceso a datos de IA en SIEM son la base forense cuando llegue la próxima divulgación de clase ChromaToast.
Para saber más sobre cómo proteger tus datos sensibles de amenazas relacionadas con IA, solicita una demo personalizada hoy mismo.
Preguntas frecuentes
Restringe el acceso de red solo a clientes de confianza y considera que cualquier instancia expuesta ya podría estar comprometida hasta que se investigue. Rota todos los secretos que el proceso del servidor pudiera leer — claves API, credenciales montadas, variables de entorno. Lleva el acceso a datos de RAG detrás de una puerta de enlace de datos IA gobernada como postura a largo plazo; la restricción de red es un triage, no una arquitectura.
Altamente expuestos si cualquier componente RAG es accesible por Internet y no está gobernado. El 77% de las organizaciones de salud carecen de una puerta de enlace de datos IA centralizada y el 14% no tiene controles de IA dedicados según el pronóstico Kiteworks 2026. La Security Rule de HIPAA exige controles de acceso y registros de auditoría que los componentes RAG no gobernados no pueden generar. Un RCE pre-auth en un componente que almacena embeddings de información de salud protegida es un evento reportable.
Un RCE pre-auth en un componente de IA que maneja información no clasificada controlada es un evento reportable según CMMC y DFARS. El 90% de las organizaciones gubernamentales carecen de una puerta de enlace de datos IA centralizada según el pronóstico Kiteworks 2026. Las familias de controles AC, AU e IA de CMMC exigen autorización y registros de auditoría para cada acceso a datos, incluso por componentes de IA. La gobernanza en la capa de datos con ABAC y registros inviolables cumple los tres requisitos a la vez.
Parchear resuelve una vulnerabilidad en un componente. Gobernar el acceso a datos de IA define quién o qué puede acceder a los datos empresariales, sin importar qué componente aguas abajo esté comprometido. Las puertas de enlace centralizadas se convierten en el estándar arquitectónico precisamente porque el parcheo no puede seguir el ritmo de descubrimiento de vulnerabilidades en la infraestructura de IA — la cronología de la divulgación de ChromaToast (meses sin respuesta, sin parche) lo demuestra.
Sí — es la opción eficiente en personal. Un solo plano de control gobernado reemplaza docenas de controles a nivel de componente. Kiteworks Secure MCP Server y la puerta de enlace de datos IA ofrecen ese único punto de aplicación arquitectónica — los equipos de seguridad pequeños ganan más con un control arquitectónico que parcheando cada base de datos vectorial, almacén de embeddings y runtime de agente por separado.
Recursos adicionales
- Artículo del Blog
Estrategias Zero‑Trust para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: por qué el 91% de las pequeñas empresas juegan a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe un «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.