Cómo los modelos abiertos de IA ayudan a los hackers a encontrar vulnerabilidades en el código

Un modelo abierto de inteligencia artificial puede ejecutarse en un servidor propio y conectarse a herramientas de análisis de programas. Leerá código, buscará errores, propondrá comprobaciones y analizará sus resultados. Si un atacante utiliza ese sistema, obtiene un asistente para investigar vulnerabilidades cuyo trabajo no controla un proveedor de IA en la nube.

Para las plataformas de intercambio de criptomonedas, los monederos y las plataformas de pago, se trata de una amenaza concreta. Un error en la comprobación de permisos, el procesamiento de retiradas o la interacción entre servicios puede ser el punto de partida de un ataque. La IA ayuda a investigar esos errores y a comprobar más hipótesis. Su eficacia, sin embargo, depende de la calidad del modelo, del código disponible y de las herramientas que verifican sus conclusiones.

Aviso informativo. Este artículo tiene carácter informativo y analítico. Su objetivo es explicar las amenazas y las medidas de protección. Las descripciones no son instrucciones para realizar ataques. La seguridad de los sistemas solo debe comprobarse con permiso de su propietario. Los ejemplos de servicios de criptoactivos ilustran riesgos posibles; los resultados de pruebas de investigación no equivalen a la probabilidad de comprometer una empresa en funcionamiento.

Por qué los hackers ejecutan modelos de IA en sus propios servidores

Un chatbot convencional en la nube tiene un operador: una empresa que mantiene el modelo, establece reglas y puede restringir el acceso. Un modelo descargado funciona de otra manera. Su propietario decide dónde se ejecuta, qué datos recibe y a qué programas tiene acceso.

Más precisamente, se trata de modelos de pesos abiertos, u open-weight. Los pesos son los parámetros que el modelo adquiere durante el entrenamiento. Tener acceso a ellos permite ejecutar el modelo de forma independiente, aunque los datos de entrenamiento y todos los detalles de su creación sigan siendo privados. Así funcionan también sistemas legítimos, como las herramientas para revisar código corporativo confidencial.

Para un atacante, el alojamiento propio es valioso porque el desarrollador del modelo pierde el control sobre el uso de esa copia concreta. No ve cada solicitud y no puede detener su funcionamiento bloqueando una cuenta. El AI Security Institute británico señala expresamente este riesgo: una vez publicados los pesos, los controles de los servicios en la nube no pueden extenderse a todos los despliegues independientes.

Un modelo abierto no carece necesariamente de restricciones de seguridad. Sin embargo, su operador puede modificar el entorno de software y el propio modelo para debilitarlas. En ese caso, obtener una herramienta peligrosa no exige vulnerar a la empresa que creó la IA.

Hay un matiz importante: la ausencia de prohibiciones no mejora por sí sola la capacidad de encontrar errores. La eficacia procede de combinar un análisis de código de calidad, herramientas adecuadas y retroalimentación. Eliminar las restricciones permite utilizar esas capacidades para tareas maliciosas.

Cómo busca la IA vulnerabilidades en el código de un servicio

Imaginemos un servicio de pagos con varios miles de archivos. La comprobación de permisos está en un módulo, la gestión de cuentas en otro y el procesamiento de retiradas en un tercero. Para detectar un error peligroso hay que entender cómo se relacionan esas partes.

La IA puede ayudar a reconstruir esa relación: de dónde procede un valor, qué controles supera y qué operación lo utiliza al final. Por ejemplo, el modelo detecta que un controlador comprueba que el usuario ha iniciado sesión, pero no verifica que la cuenta solicitada le pertenezca. Es una clase conocida de errores de autorización que OWASP describe como Broken Object Level Authorization. En términos sencillos, el servicio reconoció al usuario, pero no comprobó si podía actuar sobre un objeto concreto.

Una explicación convincente no basta. El modelo puede haber pasado por alto una comprobación en otro archivo o interpretado mal la finalidad de una función. Por eso se conecta a un entorno de herramientas que proporciona los fragmentos de código pertinentes, ejecuta pruebas y devuelve resultados. El modelo propone una hipótesis, recibe la respuesta del programa y precisa su conclusión. Así funciona un agente de IA para analizar código: puede continuar la investigación después de su primera respuesta.

En una copia aislada de la aplicación, ese sistema comprueba si el error se produce realmente. Si una prueba falla, el agente analiza la causa. Si la supuesta vulnerabilidad también se detecta en la versión corregida, hay motivos para cuestionar la prueba. Los autores de la investigación de Semgrep utilizan comprobaciones similares para distinguir la comprensión del error de una reacción a nombres y fragmentos de código conocidos.

La repetición cambia el valor práctico de la IA. Una persona no tiene que analizar manualmente cada resultado intermedio: parte de ese trabajo se delega en el agente. No obstante, configurar el entorno, verificar los hallazgos y evaluar sus consecuencias sigue requiriendo recursos y conocimientos.

El código fuente tampoco aparece automáticamente ante el modelo. Puede estudiar repositorios públicos, código publicado de contratos inteligentes y la parte cliente de un sitio web. El código privado del servidor solo estará disponible si se filtra por separado o se concede acceso. Sin él quedan la documentación y el comportamiento observable del servicio, que ofrecen una imagen mucho menos completa.

Qué pueden hacer ya los modelos abiertos en la práctica

Para evaluar la amenaza, comparamos pruebas publicadas de modelos y análisis de la actividad de atacantes. Examinamos qué datos recibía la IA, cuántos intentos se le permitían y qué consideraban un éxito los investigadores. Esto permite distinguir entre detectar código sospechoso, confirmar un error y penetrar realmente en la infraestructura.

Aikido publicó un resultado ilustrativo en agosto de 2026. Sus investigadores probaron modelos con 32 vulnerabilidades divulgadas recientemente en proyectos reales. Los modelos recibían el código fuente y tenían desactivado el acceso a internet. Se comparaba la etapa principal de análisis dentro de un sistema común, no el trabajo independiente de cada modelo sin herramientas adicionales.

DeepSeek V4 Pro 0813 encontró 17 vulnerabilidades en la primera pasada. Al combinar los hallazgos de tres pasadas, el total ascendía a 28 de 32. Sin embargo, el modelo solo encontraba 10 de forma consistente en las tres pasadas.

Esto equivale al 87,5 % de las vulnerabilidades encontradas en al menos un intento y al 31,3 % en los tres. Calculamos estos porcentajes a partir de las cifras publicadas. La diferencia explica por qué una sola respuesta describe mal las capacidades del sistema: repetir las comprobaciones amplía la cobertura, pero los resultados siguen siendo inestables. Es una prueba de redescubrimiento de errores conocidos, no un indicador del éxito al atacar plataformas de intercambio de criptomonedas.

La evaluación del AI Security Institute ofrece una perspectiva más amplia. En las tareas utilizadas, los principales modelos abiertos alcanzaban el nivel de modelos cerrados publicados entre cuatro y siete meses antes. Es una evaluación de pruebas concretas, incluidas redes preparadas artificialmente, no una clasificación universal. Para los defensores significa que capacidades importantes de análisis también están disponibles fuera de los servicios controlados en la nube.

Qué muestran los incidentes reales

En mayo de 2026, investigadores de Sysdig describieron un ataque a través de una vulnerabilidad de marimo, una herramienta para trabajar con Python. Tras la intrusión inicial, el atacante utilizó las credenciales encontradas para ampliar el acceso y llegó a una base de datos PostgreSQL interna. A partir de una combinación de indicios de la sesión registrada, los autores vincularon las acciones posteriores a la intrusión con un agente de IA que tenía en cuenta los resultados intermedios. No se estableció qué modelo se utilizó ni dónde se ejecutaba. El informe tampoco demuestra que la vulnerabilidad inicial fuera descubierta por IA.

Un análisis de Sysdig de junio sobre el uso indebido de recursos informáticos ajenos muestra otra parte del panorama. Un operador conectó un servidor Ollama accesible sin autenticación a una herramienta automatizada de pruebas de seguridad. Ollama es software para ejecutar modelos en infraestructura propia. Los investigadores observaron cómo la herramienta cambiaba e incorporaba nuevas etapas de trabajo.

En ese episodio, el servidor era ajeno y los objetivos estaban en redes privadas de entrenamiento. El caso muestra la arquitectura técnica y el abuso de recursos informáticos, pero no confirma un ataque exitoso con esa herramienta contra una empresa pública.

Estos casos ayudan a entender qué partes del proceso ya existen. No permiten atribuir un robo concreto de criptoactivos a un modelo abierto en el servidor de un hacker. Para llegar a esa conclusión hacen falta pruebas adicionales, como registros de solicitudes al modelo y rastros de actividad del programa conectado a él. Las acciones rápidas o inusuales del atacante, por sí solas, no lo demuestran.

Qué errores son especialmente peligrosos para los servicios de criptoactivos

Para una empresa de criptoactivos, las consecuencias dependen de adónde conduce el error encontrado. Acceder a una página corriente y poder influir en las retiradas no tienen el mismo peso. Por eso, al analizar el riesgo, relacionamos el defecto del código con los permisos del servicio y la operación financiera que puede alterar.

Un área sensible es la API, la interfaz de intercambio de datos entre programas. La aplicación la utiliza para consultar saldos, crear operaciones y obtener su estado. Si el servidor asocia incorrectamente al usuario con una cuenta u organización, una sesión válida puede otorgar permisos excesivos. En estos puntos es importante comprobar la autorización en cada acción del servidor, incluidas las operaciones internas y por lotes menos visibles.

Otro ejemplo es procesar un mismo evento más de una vez. Un sistema de pagos debe gestionar correctamente la entrega repetida de una notificación o la ejecución simultánea de solicitudes. Si distintas partes del programa discrepan sobre si una operación ya se completó, pueden producirse errores contables. Para la IA, se trata de relacionar archivos y estados: dónde se creó la operación, cuándo se marcó como completada y qué impide procesarla de nuevo. Esto ilustra una clase de riesgo, no una vulnerabilidad descubierta en una plataforma concreta.

En los servicios descentralizados, el código publicado de los contratos inteligentes aporta material adicional para el análisis. El modelo puede ayudar a estudiar las reglas de acceso y movimiento de activos. Sin embargo, las conclusiones de seguridad también dependen de la configuración del contrato desplegado, de los contratos relacionados y de las condiciones económicas. Incluso un error de software correctamente identificado no siempre se traduce en la posibilidad de robar fondos.

Por último, importan los límites entre servicios. Un componente que procesa datos externos no debería obtener automáticamente facultades para firmar transacciones ni acceso a todos los secretos de la empresa. Cuanto más amplios sean sus permisos, más posibilidades ofrece una sola vulnerabilidad.

Cómo protegerse frente a ataques asistidos por IA

La protección empieza por revisar el mismo código que puede estudiar un atacante. Se debe priorizar la autorización, el procesamiento de eventos financieros y las conexiones entre interfaces externas y servicios privilegiados. Para cada error encontrado hay que determinar si es accesible desde el exterior y qué acciones permite.

La IA también resulta útil para los defensores. Una empresa puede analizar código privado en su propia infraestructura, complementando el trabajo de sus ingenieros. Aun así, el hallazgo debe confirmarse mediante una prueba reproducible: una condición se incumple en la versión vulnerable y deja de incumplirse tras la corrección. El resultado de una sola pasada no debe considerarse una auditoría completa.

El siguiente nivel consiste en limitar las consecuencias. Separar los permisos de los servicios, restringir el acceso a secretos y verificar de forma independiente los parámetros de retirada reduce la probabilidad de que un error en un componente permita disponer de los activos. Actualizar las dependencias vulnerables sigue siendo obligatorio: la IA puede ayudar a los atacantes a explotar defectos ya conocidos.

En una investigación hay que relacionar los eventos de la aplicación con las acciones en la infraestructura y las transacciones en la blockchain. El historial de transferencias muestra el movimiento de activos, pero normalmente no explica qué error proporcionó el acceso inicial. Para ello hacen falta registros de solicitudes, operaciones y cambios de permisos. Por eso recomendamos conservar de antemano los datos que permitan reconstruir el recorrido desde una solicitud al servicio hasta su resultado financiero.

Los modelos abiertos hacen más accesible la investigación sistemática del código. Para un servicio de criptoactivos, la respuesta práctica es comprobar regularmente las operaciones críticas y diseñar el sistema de modo que un solo error no dé acceso a todos los activos.