Réplicas: El costo oculto de la velocidad a escala — Informe de seguridad de IA del 1H 2026

Introducción

La primera mitad de 2026 confirmó lo que los equipos de seguridad temían: la IA no introdujo una nueva categoría de amenazas, sino que amplificó las antiguas.

En nuestro Informe del Estado de la Seguridad de la IA, 1H 2026, examinamos cómo la adopción, explotación y defensa de la IA evolucionaron durante los primeros seis meses de 2026. El hallazgo principal es contundente: los desafíos familiares ahora se desarrollan a velocidad de máquina. La exposición no autenticada, el software sin parches, la gestión débil de secretos y la confianza abusada están acelerando dentro de sistemas más autónomos y de movimiento más rápido. El resultado es un ciclo de vida de vulnerabilidad comprimido, una infraestructura de IA expuesta a gran escala y una economía criminal que está industrializando el abuso de identidad más rápido de lo que los defensores pueden responder.

Nuestra investigación encuestó 21.6 millones de URLs en 4.6 millones de hosts únicos, identificando 43,175 instancias de servicios relacionados con IA en 25 industrias. Dentro de ese conjunto de datos, descubrimos 1,468 herramientas de IA utilizadas exclusivamente por un único sector industrial: plataformas legales de nicho, motores de detección de fraude para servicios financieros y herramientas de documentación médica que nunca aparecen en inventarios genéricos de IA o informes de adopción pública.

Estas herramientas específicas de cada sector operan fuera de los marcos de gobernanza de IA convencionales. Los equipos de seguridad típicamente construyen políticas alrededor de plataformas ampliamente desplegadas y orientadas al consumidor. Las herramientas especializadas de cada sector caen completamente en esos vacíos, dejando la infraestructura de IA específica de la industria en gran medida sin gobernar.

Pwn2Own Berlín 2026, organizado por TrendAI™ Zero Day Initiative™ (ZDI), produjo 47 días cero únicos en objetivos de IA, resultando en un récord de US$1.3 millones en pagos. El evento reveló un cambio crítico: el 85% de los concursantes incorporaron Modelos de Lenguaje Extenso (LLMs) en sus flujos de trabajo de descubrimiento de vulnerabilidades, demostrando que la IA se ha convertido en infraestructura estándar de investigación.

Sin embargo, esta aceleración ha creado una extraña paradoja. El análisis de vulnerabilidades impulsado por IA puede comprimir la línea de tiempo desde la divulgación hasta la explotación armada de semanas a horas. Pero el mercado de exploits clandestino cuenta una historia muy diferente: los atacantes no están corriendo para explotar nuevos días cero. En cambio, más del 70% de los exploits solicitados apuntan a vulnerabilidades que tienen más de 2 años. Casi el 8% apuntan a fallas entre 10 y 15 años. La solicitud más antigua involucró una vulnerabilidad divulgada por primera vez en 2011, 15 años antes.

Esta brecha entre la velocidad de descubrimiento y los patrones de explotación revela un problema más profundo: cientos de miles de sistemas permanecen expuestos a errores de años. En febrero de 2026, Shodan informó que más de 270,000 sistemas aún eran vulnerables a SMBGhost, 88,652 vulnerables a Heartbleed, y más de 18,000 vulnerables a CVE-2025-53770 siete meses después de que los parches estuvieran disponibles. En la era de la IA, esta deuda de remediación se vuelve cada vez más riesgosa. El descubrimiento acelerado de vulnerabilidades ahora se encuentra con un atraso arraigado de sistemas sin parches, y los atacantes pueden explotar esa brecha a gran escala.

Los servidores de Protocolo de Contexto de Modelo (MCP) han surgido como una nueva clase de infraestructura de IA expuesta. Las organizaciones a menudo tratan estos servidores como simples complementos o añadidos para conveniencia e integración. En realidad, son infraestructura privilegiada, intermediarios de herramientas que pueden consultar bases de datos, leer archivos locales y acceder directamente a aplicaciones empresariales. Esta clasificación errónea crea un punto ciego de gobernanza.

Nuestra investigación identificó 1,467 instancias de MCP expuestas en internet. De esas, 1,227 aún estaban ejecutando transporte de Eventos Enviados por el Servidor (SSE) obsoleto sin ninguna autenticación. La superficie de herramientas también fue significativa: execute_sql apareció en 70 hosts, Graphiti Agent Memory estuvo presente en 39 hosts, mientras que 3 servidores expuestos tenían acceso a progress_note, una función para recuperar registros médicos de pacientes. Cabe destacar que estos no son riesgos teóricos, sino vías directas hacia sistemas críticos.

El problema se profundiza al examinar cómo se construyen los servidores MCP. El análisis de más de 19,000 repositorios de servidores MCP reveló que casi la mitad (48%) recomendaban almacenar secretos (claves API, credenciales de bases de datos, tokens de nube) en archivos .env inseguros o configuraciones JSON en texto plano.

La compromisión de un solo servidor no se detiene en el servidor. Las credenciales comprometidas exponen cuentas en la nube, lo que afecta toda la infraestructura de la organización. Estimamos que entre 600 y 1,650 de esos 19,000 repositorios contienen vulnerabilidades explotables. La inyección SQL, la ejecución remota de código y la omisión de autenticación son endémicas en todo el ecosistema.

Lejos de ser utilidades rutinarias, estos servidores son infraestructura crítica que se despliega y mantiene como software de consumo.

Los motores de inferencia como Ollama, LocalAI y Llama.cpp fueron diseñados para entornos locales y confiables que se ejecutan en la máquina de un desarrollador, aislados de internet. Sin embargo, miles están desplegados en internet abierto sin autenticación, ejecutando versiones que están desactualizadas por meses o incluso años.

Los patrones de actualización que observamos en los motores de inferencia, incluyendo Ollama, revelan un desafío más amplio. La versión de Ollama más común que identificamos fue la 0.21, con solo seis servidores ejecutando la última versión (al momento de escribir). Esto refleja cómo las herramientas de desarrollo se actualizan típicamente en la práctica: lentamente, de manera incremental y, a menudo, años detrás de las versiones disponibles. Las versiones antiguas contienen vulnerabilidades conocidas. Las instancias expuestas que ejecutan software desactualizado presentan un riesgo real.

La popularidad no necesariamente mejora la disciplina de parches. De hecho, a menudo ocurre lo contrario. Cuanto más amplia es la implementación, mayor es el número de instancias desactualizadas y vulnerables que quedan en línea. Paradójicamente, la popularidad crea una ilusión de seguridad que no existe. Algunos de estos hosts expuestos y comprometidos ya estaban siendo secuestrados para operaciones de criptominería, su capacidad de cómputo robada y su integridad comprometida.

El riesgo se incrementa con los almacenes vectoriales. Incluso un almacén vectorial completamente parcheado, pero expuesto y sin autenticación, presenta una oportunidad persistente para el envenenamiento de datos.

Los incidentes más dañinos en el primer semestre de 2026 siguieron patrones de ataque establecidos: paquetes envenenados, robo de credenciales, lanzamientos falsos, habilidades de agentes maliciosos y ataques de expansión OAuth. En lugar de técnicas novedosas como jailbreaks o ataques adversariales, los atacantes explotaron la confianza de los desarrolladores.

El compromiso de LiteLLM ilustra este punto. Se subieron dos versiones maliciosas (1.82.7, 1.82.8) a PyPI, el repositorio oficial de paquetes de Python. LiteLLM se utiliza ampliamente como un proxy de IA, un puente entre desarrolladores, proveedores de modelos e infraestructura de producción. Las versiones maliciosas lo transformaron en un recolector de credenciales, exfiltrando silenciosamente más de 50 tipos de datos sensibles, incluidos claves SSH, credenciales de la nube, configuraciones de Kubernetes, claves API y contraseñas de bases de datos. El compromiso podría haber permanecido sin ser detectado indefinidamente. Solo se descubrió cuando un error en el malware causó que los sistemas fallaran, una alerta accidental.

Otras campañas observadas siguieron el mismo patrón:

• TeamPCP envenenó Xinference en PyPI en cuestión de días
• Los atacantes utilizaron envenenamiento SEO para posicionar sitios de descarga maliciosos por encima de las páginas oficiales de Google Gemini CLI y Claude Code
• Extensiones de editor comprometidas (Nx Console) entregaron ladrones de credenciales
• Lanzamientos falsos de GitHub empaquetaron malware con la marca Claude Code

Estos ataques explotaron la misma vulnerabilidad, canales de distribución de apariencia oficial en los que los desarrolladores confían.

El ecosistema de desarrolladores incluye muchos puntos de distribución, como bibliotecas, SDKs, GitHub Actions, extensiones de IDE, habilidades de agentes y plataformas de despliegue. Un compromiso en cualquier punto se propaga a través de sistemas conectados. Las credenciales almacenadas en plataformas de despliegue son particularmente vulnerables. Cuando una plataforma de despliegue es comprometida, cada sistema conectado, incluidas cuentas en la nube, bases de datos y APIs, queda expuesto. Una brecha en la plataforma se convierte entonces en una brecha organizacional.

Los sistemas agénticos toman acciones autónomas; realizan llamadas a API, ejecutan código, modifican archivos, acceden a sistemas y mantienen el estado a través de sesiones. Un sistema agéntico comprometido con memoria persistente y permisos delegados se convierte en una plataforma de ataque de larga duración. Los atacantes pueden usar IA para automatizar el abuso de identidad, como el perfilado, la creación de deepfakes y el lanzamiento de ataques de ingeniería social.

Esto crea un desequilibrio ya que los atacantes automatizan operaciones usando IA mientras que los defensores responden manualmente, parcheando e investigando a velocidad humana. Cuando la IA se integra en flujos de trabajo críticos, las fallas de seguridad conocidas se amplifican por la velocidad y la escala.

Implicaciones para Defensores, CISOs y Desarrolladores

Los defensores deben: Tratar la infraestructura de IA, modelos y agentes como sistemas privilegiados. Inventariar, autenticar, parchear, monitorear y gobernarlos como activos críticos.

Los CISOs deben: Incluir herramientas de IA de nicho en los marcos de riesgo de proveedores y gobernanza de seguridad. Extender los controles de la cadena de suministro más allá del código para incluir la confianza de los desarrolladores, credenciales y plataformas de despliegue.

Los desarrolladores deben: Proteger estaciones de trabajo y credenciales como activos de alto valor. Implementar gestión de secretos, verificar la procedencia del software y gobernar el código generado con rigor.