Sicarii salió a la luz a finales de abril de 2026 como un servicio de ransomware-as-a-service más, anunciado en los foros de costumbre. Lo que parecía rutina se rompió a las pocas semanas: las víctimas que pagaban el rescate descubrían que el descifrador del propio atacante no funcionaba. Y no funcionaba para nadie.

El equipo de Halcyon hizo la ingeniería inversa y publicó el hallazgo: el binario regenera localmente un nuevo par de claves RSA en cada ejecución, cifra los archivos con esa clave y descarta inmediatamente la privada. No hay clave maestra, no hay servidor C2 que la custodie, no hay forma de recuperar nada. Halcyon atribuye con confianza moderada el desarrollo del malware a tooling asistido por IA: un error de criptografía elemental que solo se comete cuando nadie sabía lo que estaba pidiendo, y nadie revisó lo que el modelo entregó.

Y ahí está el punto. El vibe coding —construir software describiéndolo a un agente IA, sin escribir prácticamente código— no es peligroso porque genere código malo. El código humano también lo es. Es peligroso porque rompe a la vez las tres capas que históricamente contenían el riesgo: la velocidad supera la revisión, la ignorancia elimina el juicio y la autonomía cierra el ciclo sin humano en el loop. El triángulo mortal.

Infografía del triángulo mortal del vibe coding con tres vértices: Velocidad (3-4× código, 10× vulnerabilidades), Ignorancia (63% no son developers) y Autonomía (prompt to shell).
Los tres vértices del triángulo mortal del vibe coding. La intersección rompe las capas de contención del modelo AppSec clásico.

Por qué el modelo AppSec clásico ya no aplica

Durante quince años, el modelo era predecible: el desarrollador escribía, otro desarrollador revisaba, los tests pasaban y el pipeline desplegaba. Cada capa fallaba a veces, pero el resto compensaba. Tres filtros en serie. Lo bastante para producir software razonablemente seguro a la velocidad humana de tipear.

El vibe coding no respeta ninguno de los tres filtros. Plataformas como Lovable, Base44, Replit, Netlify o Cursor en modo agente permiten que alguien sin formación técnica describa una aplicación en lenguaje natural y la tenga desplegada en minutos. Es la siguiente fase del Shadow AI: ya no hablamos solo de empleados pegando datos sensibles en ChatGPT, hablamos de empleados construyendo y desplegando aplicaciones productivas con datos corporativos. Sin tickets a TI. Sin code review. Sin pipeline AppSec. Y, en muchos casos, con la app pública por defecto e indexada por Google salvo que el creador la cambie a privada manualmente.

RedAccess escaneó internet a principios de mayo de 2026 y encontró aproximadamente 380.000 aplicaciones construidas con estas herramientas accesibles públicamente. Alrededor de 5.000 estaban filtrando datos en ese momento: historiales médicos, estrategias comerciales, conversaciones internas con clientes, asignaciones hospitalarias. El 40% de las apps escaneadas exponía datos sensibles de algún tipo.

El modelo AppSec clásico no estaba diseñado para esto. Y los CISOs lo sabemos por la cifra que cualquiera de mis colegas te dirá si le preguntas en privado: no tenemos inventario fiable de cuántas de estas apps corren dentro de nuestras propias empresas.

Vértice 1: velocidad

El primer vértice del triángulo es el más obvio y, paradójicamente, el menos discutido. La IA permite producir código más rápido. El equipo de seguridad sigue revisando a velocidad humana. La brecha se ensancha cada semana.

Los datos son brutales. Según un estudio de Apiiro, los desarrolladores que usan asistentes IA producen commits a 3-4 veces la tasa de sus compañeros sin IA. La misma muestra introduce hallazgos de seguridad a 10 veces esa tasa. No es proporcional. Por cada commit extra, salen entre 2,5 y 3 veces más bugs explotables.

La Cloud Security Alliance lleva la cuenta de los CVEs atribuidos directamente a herramientas de coding IA. La progresión durante el primer trimestre de 2026 es exponencial: 6 CVEs en enero, 15 en febrero, 35 en marzo. Solo el mes de marzo superó la suma de todo 2025. CSA confirma 74 CVEs en Q1 y estima que el número real es entre 5 y 10 veces mayor en repositorios públicos no auditados. Claude Code aparece atribuido a 27 de esos 74 casos, y los investigadores son explícitos sobre por qué: la prominencia se debe en parte a que Claude Code deja firmas identificativas en los mensajes de commit. Es más fácil rastrearlo, no necesariamente más inseguro.

Mientras tanto, los equipos de seguridad colapsan. ProjectDiscovery encuestó a 200 profesionales senior de ciberseguridad en Norteamérica y Europa occidental en abril de 2026 [INFORME]. El 62% declaró abiertamente no poder mantener el ritmo. El 66% pasa más del 50% de su tiempo en validación manual de hallazgos, no en remediar. La aceleración del código duplica la velocidad de despliegue y triplica el tiempo de revisión necesario.

Veracode publicó su Spring 2026 GenAI Code Security Report con datos consistentes: solo el 55% del código generado por IA supera evaluaciones básicas de seguridad. La cifra está estancada respecto a 2025: los modelos no mejoran al ritmo al que se despliegan. Para vulnerabilidades específicas, las cifras empeoran: el 85% del código IA evaluado falla en Cross-Site Scripting, el 87% falla en log injection. Donde Java y JavaScript dominan, los pass rates más bajos.

El vértice velocidad no se cierra con más herramientas SAST. Se cierra cambiando lo que significa "commit listo para revisar". Si el flujo es prompt → 200 líneas → PR sin pasar por el cerebro de nadie, ningún escáner va a llegar a tiempo.

Vértice 2: ignorancia

El segundo vértice es el que casi nadie quiere nombrar. Una parte importante de quien usa vibe coding no sabría detectar una vulnerabilidad si la tuviera delante.

El estudio de RedAccess identificó la causa raíz en su muestra de 380.000 aplicaciones: los creadores desconocen conceptos básicos —autenticación, control de acceso, almacenamiento de secretos, configuración de Row Level Security en Supabase— y las plataformas no compensan ese vacío. Lo agravan. Lovable, Base44, Replit y Netlify configuran muchas apps como públicas por defecto. El propietario debe activar explícitamente la privacidad. Google indexa el resultado en pocos días.

Moltbook lo ilustró antes de cualquier estudio. En febrero de 2026, esta red social para agentes IA construida íntegramente con vibe coding sufrió una brecha que expuso 1,5 millones de tokens de autenticación API, 35.000 direcciones de email y 4.060 mensajes privados. Su fundador declaró públicamente que no había escrito una sola línea de código. La causa raíz: la clave pública de Supabase quedó en el bundle del cliente y el Row Level Security estaba deshabilitado. Las dos cosas que un desarrollador con experiencia revisa en treinta segundos antes de desplegar.

El mismo mes, el investigador Taimur Khan auditó una sola aplicación construida con Lovable y encontró 16 vulnerabilidades, 6 de ellas críticas. La aplicación servía a estudiantes —UC Berkeley, UC Davis, instituciones K-12— y exponía 18.697 registros de usuario, 14.928 correos únicos y 870 perfiles con PII completa. El error tipo: lógica de autorización invertida. La aplicación bloqueaba a quienes debía permitir y permitía a quienes debía bloquear. Un clásico que un desarrollador con seis meses de experiencia no comete; un LLM al que pides "pon que solo los administradores puedan ver esto" lo comete una de cada tres veces.

El 78% de los profesionales de seguridad encuestados por ProjectDiscovery señaló secrets exposure —API keys, credenciales, tokens— como el riesgo número uno introducido por el coding con IA. Y hay otro vector menos visible: aproximadamente el 20% del código generado por IA referencia paquetes de npm o PyPI que no existen. Es lo que se llama slopsquatting: si tú alucinas un nombre de paquete, un actor malicioso lo crea con malware dentro y espera. El siguiente desarrollador que copie tu commit hereda la puerta trasera.

El vértice ignorancia no se cierra con formación a los devs. Eso ayuda. No basta. Se cierra cuando aceptamos que las plataformas tienen responsabilidad de seguridad por defecto y que el ecosistema de paquetes necesita una capa antes del install que asuma que el código nuevo es sospechoso hasta verificación.

Vértice 3: autonomía

El tercer vértice es el que cambia el modelo de amenaza. Hasta ahora hablábamos de código que se genera con asistencia IA y se ejecuta cuando alguien lo dispara. La autonomía añade otra capa: agentes IA que deciden, llaman a herramientas y ejecutan sin que un humano apruebe cada paso.

Microsoft publicó el 7 de mayo de 2026 dos CVEs en su propio framework de agentes Semantic Kernel. CVE-2026-26030 es una vulnerabilidad en el In-Memory Vector Store que permite que un prompt malicioso escale a ejecución de código. CVE-2026-25592 es escritura arbitraria de archivos a través de SessionsPythonPlugin: el modelo expone una función pensada para descargar resultados, un atacante la convierte en escritura de payload en disco. Ambas parcheadas, pero el patrón se queda. Y la cita textual del informe es de las que tienen la mala costumbre de ser ciertas:

Your LLM is not a security boundary. The tools you expose define your attacker's affected scope.

DryRun Security testó en marzo de 2026 los tres agentes principales del mercado —Claude Code Sonnet 4.6, OpenAI Codex GPT 5.2 y Gemini 2.5 Pro— construyendo dos aplicaciones realistas desde especificaciones [INFORME]. De 30 pull requests analizados, 26 contenían al menos una vulnerabilidad. El 87%. Total: 143 problemas de seguridad en 38 escaneos. Claude introdujo un bypass para deshabilitar la autenticación de dos factores que ninguno de los otros agentes encontró. Los tres repitieron los mismos errores de hace una década: control de acceso roto, autenticación WebSocket ausente, secretos JWT hardcodeados, rate limiting definido pero no aplicado en runtime.

Meta lo vivió en directo. En marzo de 2026, un agente IA interno publicó una respuesta no solicitada en un foro técnico interno. Un ingeniero siguió la sugerencia. La reacción en cadena otorgó acceso no autorizado a sistemas internos durante dos horas. Meta confirmó que no se manejaron incorrectamente datos de usuarios y dejó la explicación pública en lo justo. Para el CISO de fuera importa otra cosa: nadie pidió al agente que diera ese consejo. Lo dio.

Y luego está la otra mitad del problema. Google GTIG publicó la semana del 11 de mayo el primer zero-day con bypass de 2FA atribuido a desarrollo con IA detectado en explotación activa. El ciclo se cierra: la IA escribe código inseguro en una capa, y otra IA usa código para encontrar y explotar las vulnerabilidades que el primero introdujo. La diferencia con el malware artesanal de hace cinco años es de velocidad, escala y trazabilidad: la IA deja firmas estilísticas distintas a las del humano, pero las deja a velocidad de máquina.

Y volvemos a Sicarii. El ransomware que ni el atacante puede descifrar es la versión más nítida del triángulo. Velocidad: se construyó en horas. Ignorancia: nadie auditó la implementación criptográfica. Autonomía: la IA cerró el ciclo —desde el diseño hasta el binario funcional— sin que un humano comprobara que la promesa criminal era operacionalizable. El resultado: un arma cibernética con un bug estructural que la rompe contra sus propios usuarios.

El cierre del triángulo

Los tres ejes no son independientes. Se refuerzan.

La velocidad fuerza al pipeline a saltar revisiones. La ignorancia llena el código que pasa de cosas que la revisión habría cazado. La autonomía permite que ese código ejecute decisiones sin que un humano cierre el bucle. Cada vértice empeora al otro. Y el resultado es exactamente el caso Sicarii: código que pareciera funcional, que se ejecutó autónomamente, y cuyos efectos son irreversibles incluso para quien lo desplegó.

Esto es lo que cambia respecto al modelo de amenaza tradicional: el daño ya no se mide solo por lo que un atacante puede hacerte. Se mide también por lo que tu propio stack puede hacerte a ti, ejecutando código que nadie de tu equipo escribió, autorizó ni leyó.

Mi opinión como CISO

El vibe coding va a quedarse. Es demasiado útil para que ninguna política lo elimine y, francamente, hay casos de uso legítimos en los que multiplica la productividad sin destrozar el riesgo. Donde duele de verdad es donde la prisa por sacar valor se mete en zonas que la organización no controla.

Lo que veo en mi mesa es esto. Tres cosas que no funcionan ya:

  • No funciona prohibirlo. Si lo bloqueas a nivel red, la gente lo usa desde el móvil con datos corporativos en clipboard. Llevamos suficientes años con shadow IT para saber cómo termina ese guion.
  • No funciona "confiar y verificar después". Para cuando descubres que tres equipos llevan dos meses publicando endpoints sin autenticación, la fuga ya está indexada en Google. Lovable y compañía no van a llamarte para avisar.
  • No funciona el discurso de "esto es Shadow AI, gestionadlo desde IT". Vibe coding no es Shadow AI clásico. Es código en producción tocando datos sensibles. La pelota está en seguridad, lo aceptemos o no.

Y luego hay algo que tampoco voy a fingir: yo tampoco tengo el inventario exacto de qué vibe-coding corre en mi propia organización ahora mismo. Y eso es exactamente el problema. Si yo no lo tengo, el de la organización media —que invierte menos en seguridad que en su propio CRM— mucho menos.

¿Quieres profundizar en cómo gobernar la IA en tu empresa?

Si este análisis te ha resonado, en mi curso Ciberseguridad en Sistemas de IA · Módulo CISO dedico un módulo a la gobernanza del código y los agentes IA, con casos reales y planes de acción aplicables esta misma semana. 5 módulos disponibles ya. Acceso durante un año. Diploma al finalizar.

Ver el curso completo

Plan de acción CISO: 6 pasos para esta semana

Si me preguntase otro CISO por dónde empezar a recuperar control, le pasaría estos seis puntos. En este orden. Ninguno requiere herramientas exóticas; todos requieren decidir que hay que hacerlo:

  1. Inventario de stack vibe-coding interno. Logs DNS, proxy y SaaS conectados. Busca dominios y aplicaciones de Lovable, Base44, Replit, Netlify, Cursor (agent), Bolt, V0. La cifra que devuelve este paso no es la que esperas.
  2. Política explícita de qué puede y qué no puede generar la IA. Qué tipos de código pueden mergearse sin revisión, cuáles exigen revisión obligatoria y cuáles están vetados (criptografía, autenticación, manejo de secretos, lógica de autorización). Por escrito y aprobada por dirección.
  3. SAST/DAST obligatorio en pipeline post-IA + secrets scanning. Cada commit IA-asistido pasa por análisis estático, dinámico y escaneo de secretos antes de mergear. El 78% de los CISOs identifica la exposición de secretos como riesgo número uno; trátalo como tal.
  4. Agentes IA en least-privilege con auditoría de las tools expuestas. Aplica el principio Microsoft: el LLM no es el boundary, las tools sí lo son. Revisa qué funciones, ficheros y endpoints están accesibles a cada agente y recórtalo a lo mínimo operativo.
  5. Trazas de auditoría completas. Prompt, output, revisor humano, decisión final. El 57% de los profesionales ya lo exige para pentesting IA; aplica la misma vara al desarrollo. Sin trazas, no hay forense viable cuando salte el incidente.
  6. Cultura: el vibe coding NO exime de revisión. Comunícalo claro al equipo de producto y al de ingeniería. Usar Lovable o Cursor agent no es lo mismo que pedirle a un junior un PR. El PR del junior pasa por code review. El del agente también. La velocidad de la IA no compra la velocidad de la revisión, igual que la auditoría EU AI Act no compra la auditoría real.

Lo importante de este plan no son los pasos. Es la palabra que no aparece: "después". Si esto entra en el roadmap del próximo trimestre, no entra. El que ya tiene Sicarii dentro lleva semanas con la cuenta atrás corriendo y no lo sabe.

Para cerrar

El triángulo —velocidad × ignorancia × autonomía— está activo en la mayoría de las empresas que conozco. No porque alguien lo haya autorizado, sino porque la fricción para usarlo es cero y la ganancia inmediata es real. La pregunta no es si te toca, es cuántos sistemas tuyos están ya dentro y no lo sabes.

Y la pregunta operativa para el próximo comité de seguridad: ¿cuántas aplicaciones internas construidas con herramientas tipo Lovable, Base44 o Cursor agent corren ahora mismo en producción tocando datos sensibles, y cuántas pasaron por code review? Si las dos cifras no coinciden —y no van a coincidir— ya tienes el primer trabajo del lunes.

Si quieres más análisis como este, sin filtros

Publico una newsletter mensual con análisis CISO de incidentes IA, gobernanza de agentes, regulación y plan de acción. Solo para responsables de seguridad. Sin spam y cancelas cuando quieras.

Suscribirme a la newsletter

Preguntas frecuentes

¿Qué es el vibe coding y por qué es un riesgo de seguridad para empresas?

Vibe coding es el patrón de construir aplicaciones funcionales sin escribir prácticamente código, describiendo el resultado deseado a un LLM o agente (Lovable, Base44, Replit, Cursor en modo agente, etc.). El riesgo de seguridad emerge de tres factores combinados: la velocidad supera la capacidad de revisión humana, los autores no tienen el conocimiento base para detectar fallos críticos —autenticación, secretos, RLS—, y muchas plataformas vienen con defaults inseguros, dejando apps públicas e indexadas por Google salvo configuración manual contraria.

¿Puede un agente IA autónomo comprometer un sistema empresarial?

Sí, y ya ha ocurrido. Microsoft documentó en mayo de 2026 dos CVEs en su propio framework Semantic Kernel (CVE-2026-26030 e CVE-2026-25592) que permiten escalada de prompt injection a ejecución de código remoto. La cita del informe es explícita: el LLM no es un límite de seguridad; lo definen las herramientas que se le exponen. Además, un agente IA interno de Meta otorgó acceso no autorizado a sistemas durante dos horas en marzo de 2026 sin que nadie se lo pidiera.

¿Qué debe hacer un CISO ante el vibe coding en su organización?

Seis pasos: inventario de stack vibe-coding interno; política explícita de qué puede y qué no puede generar la IA; SAST/DAST y secrets scanning obligatorios en pipeline post-IA; agentes IA en least-privilege con auditoría de las tools expuestas; trazas completas de prompt-output-revisor-decisión; y cultura clara de que el código vibe-coded pasa por revisión igual que un PR de un junior.

¿Cuántas vulnerabilidades introduce realmente el código generado por IA?

El informe Veracode Spring 2026 reporta que solo el 55% del código IA supera evaluaciones básicas de seguridad, tasa estancada respecto a 2025. Los devs asistidos por IA producen commits a 3-4x velocidad y a 10x ratio de hallazgos de seguridad (Apiiro). La Cloud Security Alliance documentó 74 CVEs Q1 2026 atribuidos a herramientas IA, con progresión 6 → 15 → 35 mensual.

¿Qué es el caso Sicarii y por qué importa al CISO?

Sicarii es un ransomware-as-a-service atribuido por Halcyon con confianza moderada a desarrollo asistido por IA. Su decryptor no funciona porque el binario regenera un par RSA en cada ejecución y descarta la clave privada, dejando los archivos irrecuperables aunque la víctima pague. Importa al CISO porque demuestra el caso límite del triángulo: código IA defectuoso aplicado a un dominio crítico —criptografía— produce daño irreversible, incluso al propio atacante.

¿Cómo se relaciona el vibe coding con Shadow AI?

El vibe coding es la versión productiva de Shadow AI: ya no es un empleado pegando datos en ChatGPT, es un empleado que construye y despliega aplicaciones productivas con datos corporativos sin pasar por TI ni por seguridad. RedAccess identificó 380.000 apps vibe-coded públicas en mayo de 2026; unas 5.000 filtraban datos corporativos sensibles. La causa raíz combina ignorancia del autor con defaults inseguros de la plataforma e indexación automática por Google.

Fuentes