Los peligros ocultos del “vibe coding”

Aunque los beneficios de los asistentes de IA en el lugar de trabajo siguen siendo discutibles, donde se están adoptando con más confianza es en el desarrollo de software. Aquí, los LLM desempeñan muchas funciones, desde la refactorización y la documentación hasta la creación de aplicaciones completas. Sin embargo, los problemas de seguridad de la información tradicionales en el desarrollo ahora se ven agravados por las vulnerabilidades particulares de los modelos de IA. En esta intersección, surgen nuevos errores y problemas casi todas las semanas.

Código generado por IA vulnerable

Cuando un LLM genera un código, puede incluir errores o fallos de seguridad. Después de todo, estos modelos se entrenan con datos disponibles públicamente en Internet, incluidos miles de ejemplos de código de baja calidad.

Un estudio reciente de Veracode descubrió que los principales modelos de IA ahora producen código que se compila con éxito el 90 % del tiempo. Hace menos de dos años, esta cifra era inferior al 20 %. Sin embargo, la seguridad de ese código no ha mejorado: el 45 % aún contiene vulnerabilidades clásicas de la lista OWASP Top-10, con pocos cambios en los últimos dos años. El estudio abarcó más de un centenar de LLM populares y fragmentos de código en Java, Python, C# y JavaScript. Por lo tanto, independientemente de si el LLM se utiliza para “autocompletar el código” en Windsurf o para el “vibe coding” en Loveable, la aplicación final debe someterse a pruebas de vulnerabilidad exhaustivas. Pero en la práctica, esto rara vez sucede: según un estudio de Wiz, el 20 % de las aplicaciones codificadas con vibe coding tienen vulnerabilidades graves o errores de configuración.

Como ejemplo de tales fallos, a menudo se usa el caso de la aplicación de citas solo para mujeres, Tea, que se ganó una mala reputación después de dos importantes filtraciones de datos. Sin embargo, esta aplicación es anterior al vibe coding. Si la IA fue la culpable del desliz de Tea se determinará en el tribunal.

En el caso de la startup Enrichlead, la IA fue sin duda la culpable. Su fundador se jactó en las redes sociales de que el 100 % del código de su plataforma fue escrito por Cursor AI, con “nada de código escrito a mano”. Apenas unos días después de su lanzamiento, se descubrió que estaba lleno de fallos de seguridad de principiante, que permitían a cualquier persona acceder a funciones pagas o alterar los datos. El proyecto se canceló después de que el fundador no lograra llevar el código a un estándar de seguridad aceptable con Cursor. Sin embargo, no se deja intimidar, y desde entonces ha iniciado nuevos proyectos basados en el vibe coding.

Vulnerabilidades comunes en el código generado por IA

Aunque la programación asistida por IA solo ha existido durante uno o dos años, ya hay datos suficientes para identificar sus errores más comunes. Por lo general, estos son los siguientes:

• La falta de validación de datos, la no limpieza de los caracteres extraños en los datos que ingresan los usuarios y otros errores básicos que producen vulnerabilidades clásicas como el scripting entre sitios (XSS) y la inyección de SQL.
• Las claves de API y otros secretos codificados de forma rígida directamente en la página web y visibles para los usuarios en su código.
• La lógica de autenticación implementada de forma exclusiva en el lado del cliente, directamente en el código del sitio que se ejecuta en el navegador. Esta lógica se puede modificar fácilmente para eludir cualquier verificación.
• Errores de registro: desde un filtrado insuficiente al escribir en los registros hasta la ausencia total de registros.
• Funciones demasiado potentes y peligrosas: los modelos de IA están optimizados para generar un código que resuelve una tarea de la manera más rápida posible. Pero la manera más rápida suele ser poco segura. Un ejemplo clásico es el uso de la función eval para operaciones matemáticas en los datos que ingresan los usuarios. Esto permite la ejecución arbitraria de código en la aplicación generada.
• Las dependencias desactualizadas o inexistentes. El código generado por IA a menudo hace referencia a versiones antiguas de bibliotecas, realiza llamadas API desactualizadas o no seguras, o incluso intenta importar bibliotecas ficticias. Esto último es particularmente peligroso porque los atacantes pueden crear una biblioteca maliciosa con un nombre “creíble”, y el agente de IA la incluirá en un proyecto real.

En un estudio sistemático, los autores analizaron el código generado por IA en busca de debilidades incluidas en la lista MITRE CWE Top 25. Los problemas más comunes fueron CWE-94 (inyección de código), CWE-78 (inyección de comandos del SO), CWE-190 (desbordamiento de enteros), CWE-306 (falta de autenticación) y CWE-434 (carga de archivos sin restricciones).

Un ejemplo sorprendente de CWE-94 fue la reciente vulneración de la plataforma Nx, de la que ya hablamos. Los atacantes lograron troyanizar una herramienta de desarrollo popular con el robo de un token que les permitía publicar nuevas versiones de productos. Este robo aprovechó una vulnerabilidad introducida por un simple fragmento de código generado por IA.

Instrucciones peligrosas

El conocido dicho entre los desarrolladores “hecho exactamente de acuerdo con las especificaciones” también se aplica cuando se trabaja con un asistente de IA. Si la instrucción para crear una función o aplicación no es clara y no menciona los elementos de seguridad, las probabilidades de generar código vulnerable aumentan drásticamente. Un estudio especializado descubrió que incluso comentarios generales como “asegúrate de que el código siga las prácticas recomendadas para generar un código seguro” redujo la tasa de vulnerabilidades a la mitad.

Sin embargo, el enfoque más eficaz es utilizar una guía de seguridad detallada y específica del lenguaje que haga referencia a las listas de errores MITRE u OWASP. Hay una gran colección de instrucciones de seguridad de este tipo de Wiz Research disponible en GitHub. Se recomienda añadirlas a las instrucciones del sistema de los asistentes de IA a través de archivos como claude.md, .windsurfrules o similares.

Degradación de la seguridad durante las correcciones

Cuando el código generado por IA se corrige repetidamente con instrucciones de seguimiento, su seguridad se deteriora. Un estudio reciente hizo que GPT-4o modificara el código escrito previamente hasta 40 veces, mientras que los investigadores analizaban cada versión en busca de vulnerabilidades después de cada ronda. Después de solo cinco reiteraciones, el código contenía un 37 % más de vulnerabilidades críticas que la versión inicial. El estudio probó cuatro estrategias de orientación, tres de las cuales tenían un énfasis diferente cada una: (i) rendimiento, (ii) seguridad y (iii) nuevas funcionalidades. El cuarto fue escrito con instrucciones poco claras.

Cuando las instrucciones se centraron en añadir nuevas funciones, aparecieron 158 vulnerabilidades, incluidas 29 que fueron críticas. Cuando la instrucción puso énfasis en la codificación segura, el número disminuyó significativamente, pero de todas formas introdujo 38 nuevas vulnerabilidades, siete de las cuales eran críticas.

Curiosamente, las instrucciones “enfocadas en la seguridad” dieron como resultado el mayor porcentaje de errores en las funciones relacionadas con la criptografía.

Desconocimiento del contexto de la industria

En sectores como las finanzas, la salud y la logística, existen requisitos técnicos, organizativos y legales que deben tenerse en cuenta durante el desarrollo de una aplicación. Los asistentes de IA no conocen estas limitaciones. Este problema a menudo se denomina “falta de información”.

Como resultado, los métodos de almacenamiento y procesamiento de datos personales, médicos y financieros exigidos por las regulaciones locales o de la industria no se reflejarán en el código generado por IA.

Por ejemplo, un asistente podría escribir una función matemáticamente correcta para calcular el interés del depósito, pero ignorar las normas de redondeo impuestas por los reguladores. Las regulaciones de datos de salud a menudo requieren un registro detallado de cada intento de acceso, algo que la IA no implementará de forma automática con el nivel de detalle necesario.

Configuración incorrecta de la aplicación

Las vulnerabilidades no se limitan al vibe code en sí. Las aplicaciones desarrolladas con vibe coding a menudo son creadas por usuarios sin experiencia, que no configuran el entorno de ejecución en absoluto o lo configuran de acuerdo con los consejos de la propia IA. Esto provoca errores de configuración peligrosos:

• Las bases de datos requeridas por la aplicación se crean con permisos de acceso externo demasiado amplios. Esto da como resultado filtraciones como Tea/Sapphos, en las cuales el atacante ni siquiera necesita usar la aplicación para descargar o eliminar la base de datos completa.
• Las aplicaciones corporativas internas se dejan accesibles al público sin autenticación.
• Las aplicaciones reciben permisos con privilegios para acceder a bases de datos importantes. Junto con las vulnerabilidades del código generado por IA, esto simplifica las inyecciones de SQL y los ataques similares.

Vulnerabilidades de la plataforma

La mayoría de las plataformas de vibe coding ejecutan aplicaciones generadas a partir de instrucciones directamente en sus propios servidores. Esto vincula a los desarrolladores con la plataforma, incluida la exposición a sus vulnerabilidades y la dependencia de sus prácticas de seguridad. Por ejemplo, en julio se descubrió una vulnerabilidad en la plataforma de Base44 que permitía a atacantes no autenticados acceder a cualquier aplicación privada.

Amenazas en la etapa de desarrollo

La mera presencia de un asistente con amplios derechos de acceso en el ordenador del desarrollador crea riesgos. Estos son algunos ejemplos:

La vulnerabilidad CurXecute (CVE-2025-54135) permitió a los atacantes ordenar a la popular herramienta de desarrollo de IA, Cursor, que ejecutara comandos arbitrarios en la máquina del desarrollador. Todo lo que se necesitaba era un servidor de Protocolo de contexto de modelo (MCP) activo conectado a Cursor, que una parte externa podría usar para acceder. Esta es una situación típica: los servidores MCP brindan a los agentes de IA acceso a los mensajes de Slack, problemas de Jira y más. La inyección de instrucciones se puede realizar a través de cualquiera de estos canales.

La vulnerabilidad EscapeRoute (CVE-2025-53109) permitió la lectura y escritura de archivos arbitrarios en el disco del desarrollador. El fallo existía en el popular servidor MCP de Anthropic, que permite a los agentes de IA escribir y leer archivos en el sistema. Las restricciones de acceso del servidor simplemente no funcionaron.

Un servidor MCP malicioso que permitía a los agentes de IA enviar y recibir correos electrónicos a través de Postmark reenviaba simultáneamente toda la correspondencia a una dirección oculta. Habíamos predicho la aparición de servidores MCP maliciosos así en septiembre.

Una vulnerabilidad en la interfaz de línea de comandos de Gemini permitió la ejecución de comandos arbitrarios cuando un desarrollador simplemente le pedía al asistente de IA que analizara el código de un nuevo proyecto. La inyección maliciosa se activó desde un archivo readme.md.

Por poco tiempo, la extensión Q Developer de Amazon para Visual Studio Code contuvo instrucciones para borrar todos los datos del ordenador de un desarrollador. Un atacante aprovechó un error de los desarrolladores de Amazon y logró insertar esta instrucción maliciosa en el código público del asistente sin privilegios especiales. Por suerte, un pequeño error de codificación impidió su ejecución.

Una vulnerabilidad en el agente de Claude Code (CVE-2025-55284) permitió que los datos se filtraran del ordenador de un desarrollador a través de solicitudes de DNS. La inyección de instrucciones, que usaba programas comunes que se ejecutan automáticamente sin confirmación, se podía incrustar en cualquier código analizado por el agente.

El agente de IA autónomo Replit eliminó las bases de datos principales de un proyecto que estaba desarrollando porque decidió que la base de datos requería una limpieza. Esto fue en contra de una instrucción directa que prohibía las modificaciones (congelación de código). Detrás de este comportamiento inesperado de la IA se encuentra un defecto arquitectónico clave: en ese momento, Replit no tenía una separación entre las bases de datos de prueba y de producción.

Una inyección de instrucciones en un comentario del código fuente provocó que el entorno de desarrollo de Windsurf almacenara automáticamente instrucciones maliciosas en su memoria a largo plazo, lo que le permitía robar datos del sistema durante meses.

En el incidente de vulnerabilidad de Nx, las herramientas de línea de comandos para Claude, Gemini y Q se utilizaron para buscar contraseñas y claves que podían robarse de un sistema infectado.

Cómo utilizar el código generado por IA de forma segura

El nivel de riesgo del código generado por IA puede reducirse significativamente, aunque no por completo, con una combinación de medidas organizativas y técnicas:

• Implementa la revisión automática del código generado por IA tal como está escrito utilizando herramientas SAST optimizadas.
• Inserta los requisitos de seguridad en las instrucciones del sistema de todos los entornos de IA.
• Haz que especialistas humanos con experiencia realicen revisiones detalladas del código, con el apoyo de herramientas especializadas de análisis de seguridad impulsadas por IA para aumentar la efectividad.
• Forma a los desarrolladores para escribir instrucciones seguras y, de manera más amplia, proporciona educación exhaustiva sobre el uso seguro de la IA.