Principales destacados
- Exploit de múltiples etapas: un investigador afirma que el modelo de DeepSeek desarrolló un exploit de corrupción de memoria capaz de obtener acceso completo de lectura y escritura dentro del proceso afectado.
- Rendimiento con matices: el V4.1-Flash-1017 mejoró sus resultados en programación y mantiene costes bajos, pero las pruebas independientes señalan una preocupante tendencia a las alucinaciones.
- IA y ciberseguridad: el episodio reaviva el debate sobre el potencial de los modelos de código abierto para automatizar el descubrimiento y la explotación de vulnerabilidades.
DeepSeek lanzó una actualización de su modelo de inteligencia artificial de pesos abiertos, con la promesa de ofrecer respuestas más rápidas, un menor consumo de recursos y mejores resultados en benchmarks. Sin embargo, pocos días después, el modelo empezó a llamar la atención por otro motivo: la afirmación de que habría creado un exploit capaz de escapar del sandbox de Chrome.
El 22 de octubre de 2026, un investigador identificado con el nombre de Exocija afirmó haber solicitado al modelo que desarrollara un exploit para escapar del entorno aislado del motor JavaScript V8, utilizado por el navegador de Google.
Según el relato publicado por Wccftech, el sistema habría trabajado durante aproximadamente 12 horas hasta producir un exploit de corrupción de memoria con múltiples etapas.
Lo más relevante no es solo la capacidad de generar código, sino la afirmación de que el modelo logró encadenar técnicas complejas para alcanzar un área protegida del navegador.
Sin embargo, la afirmación debe tratarse con cautela. El relato del investigador no equivale, por sí solo, a una validación independiente del exploit, de su eficacia o de las condiciones necesarias para reproducirlo.
🧠 ¿Qué habría conseguido hacer el modelo?
El investigador afirmó que el exploit permitía realizar operaciones de lectura y escritura en el proceso afectado. Este tipo de capacidad puede ser relevante en ataques que aprovechan vulnerabilidades de los navegadores.
Chrome utiliza mecanismos de aislamiento para limitar los daños que puede provocar un código malicioso. El sandbox es una de esas capas de defensa: restringe el acceso de los procesos potencialmente comprometidos a los recursos del sistema.
Escapar de ese aislamiento puede ampliar significativamente el impacto de una vulnerabilidad. Aun así, explotar V8 y escapar por completo del sandbox son etapas técnicamente diferentes, y confirmar una no demuestra automáticamente la otra.
🔎 El detalle que importa: para evaluar la gravedad del caso, sería necesario conocer la versión de Chrome afectada, las vulnerabilidades implicadas, las condiciones de reproducción y la existencia de una demostración técnica verificable.
El episodio tampoco significa que cualquier persona pueda pedirle a DeepSeek que ataque navegadores y obtener resultados satisfactorios. La creación de un exploit funcional depende de condiciones técnicas específicas, y el relato todavía debe evaluarse a partir de pruebas reproducibles.
⚡ Un modelo más barato, rápido y eficiente
El caso de seguridad involucra al DeepSeek V4.1-Flash-1017, una actualización lanzada el 17 de octubre de 2026.
La empresa afirma que esta versión ofrece una mejora de Pareto en rendimiento y coste, una expresión que indica una combinación más favorable entre la calidad de los resultados y los recursos necesarios.
El modelo sustituyó a la versión anterior en los servicios web, la aplicación y la API de DeepSeek. Los precios de las llamadas a la API se mantuvieron sin cambios.
Entre las características técnicas divulgadas se encuentran:
- Arquitectura: mezcla de expertos, o mixture-of-experts (MoE).
- Parámetros totales: 552.000 millones.
- Parámetros activos: 16.000 millones.
- Ventana de contexto: 1 millón de tokens.
- Licencia: MIT, con los pesos disponibles en Hugging Face.
La arquitectura MoE permite que el sistema utilice solo una parte de sus parámetros durante cada procesamiento, en lugar de activar el modelo completo en cada solicitud.
💰 ¿Cuánto cuesta utilizar la API?
Según los precios indicados en el material de origen, durante los periodos de menor demanda las tarifas son las siguientes:
| Tipo de token | Precio por millón |
|---|---|
| Entrada | US$ 0,15 |
| Salida | US$ 0,60 |
La eficiencia también se refleja en el uso de memoria. Según la información divulgada, la transición anterior al V4.1 Flash redujo las necesidades de memoria HBM a una cuarta parte y el almacenamiento SSD destinado a la caché KV a una octava parte, en comparación con la configuración anterior mencionada por la empresa.
En el benchmark de programación DeepSWE, la puntuación pasó de 74,2 a 77,0.
Sin embargo, estas cifras no deben confundirse con una evaluación independiente de la seguridad o la fiabilidad del modelo. El rendimiento en programación y la capacidad para generar exploits son dimensiones diferentes, al igual que la eficiencia computacional y la precisión factual.
📊 El problema que los benchmarks no resuelven
A pesar de los avances anunciados, las evaluaciones independientes señalan limitaciones importantes en la fiabilidad del modelo.
Según el material de Artificial Analysis citado en el artículo original, el DeepSeek V4.1-Flash-1017 obtuvo 45 puntos en el índice de inteligencia de la organización, situándose en segundo lugar entre los grandes modelos de pesos abiertos incluidos en la comparación.
El Claude Opus 5.5 ocupa el primer puesto de la clasificación general, con 58 puntos.
Pero el resultado más preocupante aparece en el benchmark Omniscience, orientado a evaluar los conocimientos del modelo y su capacidad para reconocer sus propias limitaciones.
| Indicador | Resultado atribuido a DeepSeek |
|---|---|
| Respuestas correctas | 43 % |
| Respuestas inventadas cuando debería abstenerse | 67 % |
| Puntuación neta | 5 |
La puntuación neta citada quedó por debajo de los resultados atribuidos a Kimi K3, con 20 puntos, y a los modelos de vanguardia, con 42 puntos o más.
¿Qué significa esto en la práctica?
Un modelo puede ser excelente generando código y, aun así, inventar datos al responder preguntas abiertas. También puede mostrar resultados impresionantes en tareas técnicas específicas sin ser fiable en investigaciones que requieren precisión factual.
Por eso, la recomendación atribuida al análisis es priorizar el modelo para tareas cuyos resultados puedan probarse o verificarse, como la programación, y actuar con mayor cautela en investigaciones abiertas y en la elaboración de documentos que dependan de información rigurosa.
🔐 Por qué el caso preocupa al sector de la seguridad
La combinación de modelos de bajo coste y capacidades avanzadas de programación puede cambiar la economía de la investigación en seguridad digital.
Tradicionalmente, encontrar vulnerabilidades complejas exige conocimientos especializados, herramientas específicas y muchas horas de trabajo. Los modelos de IA pueden ayudar a analizar código, formular hipótesis, automatizar pruebas y explorar distintas posibilidades técnicas.
Esto tiene dos caras.
Por un lado, los investigadores y los equipos de defensa pueden utilizar las mismas capacidades para identificar fallos antes de que sean explotados por delincuentes. Por otro, los actores maliciosos pueden intentar automatizar partes del desarrollo de ataques.
⚠️ La diferencia está en el contexto y la validación: una IA que sugiere código potencialmente peligroso no necesariamente ha producido un ataque funcional. Es necesario distinguir entre una hipótesis, una prueba de concepto y un exploit reproducible en condiciones reales.
La afirmación sobre Chrome surgió durante la misma semana en que se divulgaron correcciones de emergencia para vulnerabilidades críticas de PHP e información sobre la automatización de ataques por parte de un grupo alineado con China, que utilizaba una herramienta de pruebas de penetración basada en IA.
Estos acontecimientos no demuestran que los casos estén técnicamente relacionados. Sin embargo, ayudan a ilustrar por qué la automatización de tareas de ciberseguridad se ha convertido en una cuestión relevante para desarrolladores, empresas y gobiernos.
🇺🇸 El debate político también entra en escena
El caso puede alimentar las discusiones en Washington sobre los riesgos asociados a los modelos chinos de pesos abiertos.
La posibilidad de descargar, modificar y ejecutar un modelo sin depender por completo de un servicio alojado ofrece ventajas a desarrolladores e investigadores. Al mismo tiempo, dificulta el control centralizado sobre los usos posteriores del sistema.
Esto no significa que el origen chino del modelo sea, por sí mismo, una prueba de riesgo. La evaluación debe tener en cuenta las capacidades técnicas, los controles disponibles, las evidencias de uso indebido y la posibilidad de reproducir los resultados.
También es importante separar el debate político de la cuestión técnica: una afirmación sobre un exploit no demuestra automáticamente la necesidad de una prohibición, del mismo modo que el carácter abierto de un modelo no garantiza que sea seguro.
¿Qué falta por demostrar?
Hay tres cuestiones fundamentales para determinar la verdadera dimensión del episodio:
- Reproducibilidad: ¿otros investigadores pueden reproducir el resultado en las mismas condiciones?
- Alcance del exploit: ¿el código realmente escapa del sandbox o solo alcanza determinadas capacidades dentro del proceso comprometido?
- Validación independiente: ¿existen pruebas técnicas suficientes para confirmar su funcionamiento e identificar las vulnerabilidades implicadas?
Los resultados de los benchmarks también deben interpretarse con cautela, especialmente porque las puntuaciones de rendimiento divulgadas por la empresa no equivalen a una auditoría independiente de todas las capacidades del sistema.
El DeepSeek V4.1-Flash-1017 puede representar un avance relevante en la combinación de coste, velocidad y capacidad de programación. Sin embargo, el relato sobre Chrome sigue siendo una afirmación que requiere confirmación técnica.
Si se valida, el caso reforzará una cuestión cada vez más importante para la industria: a medida que los modelos económicos se vuelven capaces de ejecutar tareas complejas de programación, ¿cómo ampliar el acceso a las herramientas de defensa sin facilitar, en la misma medida, la automatización de ataques?
