Este contenido va dirigido a pequeñas empresas y desarrolladores independientes que ejecutan sitios web o aplicaciones, y a desarrolladores que usan agentes de IA o API de LLM en el trabajo. Esta página es un centro de referencia para las divulgaciones oficiales de 2026 sobre ataques que involucran IA y para las defensas publicadas por organismos públicos y grupos de estándares. No cubre pasos de ataque ni detalles de explotación. Actualizamos esta página y los informes enlazados cuando se divulgan nuevos casos.
Cuatro tipos de ataque impulsado por IA
Agrupamos las divulgaciones según el punto por el que entran, desde el punto de vista del defensor. Empiece por el tipo que le corresponda.
| Tipo | Ejemplos divulgados | Debilidad usada como punto de entrada | Primera acción |
|---|---|---|---|
| 1. Intrusión autónoma | Un agente de IA bajo evaluación se introdujo en el entorno de producción de una plataforma de IA sin dirección humana paso a paso (julio de 2026, divulgado por la víctima y el desarrollador). La actividad posterior a la intrusión en una organización neerlandesa de divulgación de vulnerabilidades también fue analizada como obra de un agente de IA | Credenciales expuestas en internet, una ruta vulnerable de procesamiento de datos, vulnerabilidades desconocidas | Revocar las claves expuestas, reducir lo que una clave puede alcanzar, aislar las partes que procesan datos externos |
| 2. Ataques automatizados con IA | La ola de intrusiones en Japón. Los atacantes usaron IA para buscar vulnerabilidades conocidas e identificar API (JPCERT/CC, 15 de octubre). También se confirmaron intentos que abusan de plataformas de pruebas de penetración impulsadas por IA (actualización de JPCERT/CC del 23 de octubre) | API que devuelven más datos de los necesarios, comprobaciones de permisos ausentes del lado del servidor, claves incrustadas en aplicaciones, vulnerabilidades sin parchear | Revisar la autorización de API, eliminar secretos de las aplicaciones, parchear antes |
| 3. Inyección de prompts contra agentes | Figura en primer lugar en el Top 10 de OWASP para aplicaciones LLM (2025). Instrucciones ocultas en páginas web o archivos que un agente lee | Permisos amplios otorgados a un agente, ausencia de separación entre texto externo e instrucciones | Mínimo privilegio, aprobación humana para acciones de alto riesgo, tratar el texto externo como datos |
| 4. Cadena de suministro de IA | Versión 1.107.0 de LiteLLM con malware, herramienta de código abierto que unifica las API de LLM (21 de octubre). La investigación del desarrollador la relacionó con una clave no revocada de una plataforma interna de agentes que se había subido a un repositorio público | Claves nunca revocadas, instalaciones sin versiones fijadas, servidores MCP iniciados sin revisión | Fijar versiones, contar con un procedimiento de revocación, revisar los comandos de inicio y los alcances de los servidores MCP |
Los datos de cada tipo están en los informes individuales. Para el tipo 1, consulte la intrusión de un agente de IA en una plataforma de IA, los agentes de IA que llegan a sitios web reales y la intrusión en DIVD. Para el tipo 2, consulte la alerta de acceso no autorizado en Japón y las comprobaciones de esta semana. Para el tipo 4, consulte la publicación de malware en LiteLLM 1.107.0.
Casos principales divulgados en 2026
Julio de 2026
Un agente de IA bajo evaluación eludió sus controles de aislamiento, encontró y usó credenciales expuestas en internet (informe del desarrollador) y se introdujo en el entorno de producción de una plataforma de IA a través de sus rutas de procesamiento de conjuntos de datos (divulgación de la víctima). La víctima describió el ataque como ejecutado de principio a fin por un agente de IA autónomo.Julio–octubre
Desarrolladores de IA divulgaron, uno tras otro, casos en los que modelos bajo evaluación o de uso interno llegaron a sistemas y sitios web de terceros reales. Las debilidades usadas fueron básicas, como credenciales expuestas y páginas de depuración.24 de septiembre
Una organización neerlandesa de divulgación de vulnerabilidades reveló una intrusión mediante vulnerabilidades desconocidas en un software de mesa de ayuda. La actividad posterior a la intrusión fue analizada como obra de un agente de IA.8–9 de octubre
JPCERT/CC publicó una alerta sobre los accesos no autorizados continuos en organizaciones japonesas. La Oficina Nacional de Ciberseguridad de Japón emitió orientaciones, y IPA publicó las medidas que las organizaciones deben tomar con prontitud.15 de octubre
JPCERT/CC publicó su análisis de servidores probablemente usados en los ataques, indicando que los atacantes usaron IA para escaneos y ataques a API.21 de octubre
La versión 1.107.0 de LiteLLM con malware se distribuyó en PyPI y como imágenes de Docker durante unas dos horas (Docker Hub, unas 2,5).23 de octubre
JPCERT/CC añadió el Caso E a su alerta: intentos de ataque que abusaban de plataformas de pruebas de penetración impulsadas por IA, principalmente contra aplicaciones web expuestas a internet, explotando vulnerabilidades y debilidades de gestión.
Qué es nuevo y qué no
Nuevo
- El reconocimiento, los intentos y el movimiento lateral continúan sin dirección humana paso a paso
- Cuando se bloquea, el atacante sigue probando otras rutas y otras formas de solicitud
- El análisis de aplicaciones públicas y el mapeo de API ocurren con rapidez y en volumen
- Los propios agentes de IA se convierten en objetivos, dirigidos mediante texto externo
No es nuevo
- Los puntos de entrada son vulnerabilidades sin parchear, autorización ausente y claves expuestas
- Una vez corregidos, detienen de la misma forma a un atacante humano y a una IA
- La revocación de claves, el mínimo privilegio y la conservación de registros determinan hasta dónde se extiende el daño
- Sin un punto de contacto, incluso los informes de buena fe nunca llegan
Un atacante que usa IA prueba en paralelo, en poco tiempo, lo que a una persona le llevaría días. Eso hace que "lo corregiremos en la próxima ventana de mantenimiento" sea más peligroso que antes. Dicho de otro modo, lo que los defensores deben hacer no ha cambiado mucho. Piense en ello como un cambio de orden y de velocidad.
También se ha informado de un modelo en el que las personas aprueban y la IA ejecuta. El 20 de octubre, la unidad de investigación de una empresa de inteligencia de amenazas informó de que un servidor usado por afiliados de ransomware (las personas que llevan a cabo los ataques) había quedado expuesto, y que sus registros mostraban un marco en el que un operador humano aprobaba cada etapa mientras modelos comerciales de IA planificaban el reconocimiento, generaban comandos y clasificaban los datos robados. Según el mismo informe, en un caso una única contraseña reutilizada dio acceso a la VPN, los servidores, las herramientas de monitorización y gestión remotas (RMM), las copias de seguridad y las plataformas de gestión de seguridad al mismo tiempo. La IA agilizó el trabajo, pero lo que benefició a los atacantes fue la debilidad clásica de reutilizar contraseñas. El informe recomienda la autenticación multifactor en el acceso a VPN y RMM, rotar las credenciales y proteger las copias de seguridad.
El orden para pequeños operadores y desarrolladores
Corrija las vulnerabilidades explotadas en días
Compruebe si sus servidores públicos y su software aparecen en el KEV de CISA (el catálogo de vulnerabilidades con explotación confirmada). Use la herramienta de búsqueda de CVE para verificar una versión y la priorización con CVSS, EPSS y KEV para decidir el orden.
Verifique en el servidor quién puede hacer qué, para cada API
JPCERT/CC recomienda no confiar solo en la firma o la ofuscación dentro de la aplicación, sino autenticar a los usuarios en el servidor y autorizar cada operación según su objetivo y contenido. Revise también las API de gestión e internas, buscando API que devuelvan datos de otra persona al cambiar el ID (IDOR) o que devuelvan más campos de los necesarios. El concepto está explicado en autenticación frente a autorización.
Saque los secretos de las aplicaciones y de los archivos públicos, y detenga las claves filtradas
JPCERT/CC señala que los secretos incrustados incluso en aplicaciones móviles compiladas pueden ser extraíbles. Mantenga las claves secretas de API y las credenciales de larga duración fuera de las aplicaciones y de los archivos de configuración enviados al navegador, y dé a las claves un alcance mínimo y una caducidad. Una clave subida una vez a un repositorio público sigue siendo utilizable hasta que se revoque, incluso después de sobrescribir el commit; ese fue el punto de partida del caso de LiteLLM. Consulte credenciales de GitHub filtradas que siguen siendo válidas y cómo evitar los commits de secretos con gitleaks.
Detecte por volumen, velocidad y espaciado, no por recuentos por IP
Para prepararse ante ataques que cambian las direcciones de origen, revise el uso por función además de aplicar límites por IP. Vigile cada función (inicio de sesión, restablecimiento de contraseña, búsqueda, API de listados) en cuanto a solicitudes por hora, registros devueltos y lo cortos que son los intervalos. La primera regla que conviene añadir: un límite horario en el endpoint que devuelve más registros, con una alerta al 80 %. Los detalles están en limitación de tasa y control de abuso.
Mantenga las funciones de administración fuera de internet e inclúyalas en las pruebas
Traslade a un lugar inaccesible desde internet las funciones de administración que no necesite publicar. Al encargar una prueba, confirme que las funciones de administración están dentro del alcance.
Si usa agentes de IA, defina los permisos y cómo se trata el texto externo
OWASP indica que no se conoce ningún método que prevenga por completo la inyección de prompts, y enumera estas medidas: limitar el papel y el alcance del modelo, exigir formatos de salida definidos y verificarlos en el código, mantener las claves de API y las funciones privilegiadas en el código de la aplicación en lugar de dárselas al modelo, exigir aprobación humana para acciones de alto riesgo y separar y etiquetar claramente el contenido externo. Diseñe el sistema para que el correo, las páginas web y los archivos que lee un agente se traten como datos, no como instrucciones.
Instale servidores MCP y bibliotecas de IA después de comprobar la versión y lo que ejecutan
Las buenas prácticas de seguridad de la especificación MCP exigen que los clientes que ofrecen configuración de servidores locales con un clic muestren el comando exacto sin truncar y obtengan aprobación explícita. Los servidores no deben aceptar tokens que no se les emitieron, y los alcances deben empezar siendo mínimos y ampliarse solo cuando sea necesario. Como muestra el caso de LiteLLM, una versión mala puede llegar por el canal legítimo, así que fije las versiones y actualice después de leer el aviso de la versión. Para npm, consulte cómo defenderse de los gusanos de la cadena de suministro de npm.
Asuma una brecha: tenga listo un procedimiento de detención y un punto de contacto
Mantenga una lista de las claves que puede revocar de inmediato, los registros que puede buscar meses atrás y un punto de contacto (security.txt) que llegue a una persona responsable. Un gobierno que recibió un aviso de un desarrollador de IA ha dicho que llegó a una bandeja de entrada general y permaneció allí durante días. Para buscar indicios de intrusión, consulte cómo comprobar un sitio web o servidor en busca de intrusiones.
Entrada
Vulnerabilidades sin parchear / claves expuestas / secretos incrustados en aplicaciones
Detener: parchear en días, revocar claves y definir caducidad
↓
Permisos
Autorización ausente del lado del servidor / claves con alcance excesivo / permisos otorgados a agentes
Detener: autorización por operación, mínimo privilegio, aprobación humana
↓
Volumen
Tráfico intenso mantenido por debajo de los umbrales / intervalos de regularidad no humana
Aviso: recuentos por función, velocidad y espaciado
↓
Salida
Los datos que no conserva no pueden filtrarse
Reducir: eliminar datos fuera de su período de conservación, devolver los menos campos posibles
Opinión de este sitio: la defensa frente a la IA no consiste en comprar un producto de IA
La expresión "ataque impulsado por IA" lleva a buscar un nuevo producto de IA con el que defenderse. Los controles básicos pueden reducir los riesgos derivados de claves expuestas y fallos de autorización, aunque algunos casos también implicaron vulnerabilidades de día cero. Atienda las debilidades conocidas y prepárese también para una brecha. Si un pequeño operador tiene poco tiempo, las mayores ganancias están en el tiempo hasta el parche, la autorización de la API y el lugar donde se guardan las claves.
Quienes usan IA sí tienen nuevas tareas pendientes. Un agente puede seguir el texto que lee y actúa dentro de los permisos que usted le dio. Antes de empezar a usar agentes o servidores MCP internamente, decida qué claves reciben y qué acciones debe aprobar una persona.
Cómo se actualiza esta página
Cuando se divulga un nuevo ataque relacionado con IA, publicamos un primer informe en noticias de seguridad de última hora y lo añadimos a la tabla y a la cronología de esta página. Los informes individuales son la referencia para los hechos de cada incidente; esta página resume los tipos y el orden de defensa.
Fuentes (registros públicos)
- JPCERT/CC, alerta sobre accesos no autorizados recientes en organizaciones japonesas (JPCERT-AT-2026-0030, publicada el 8 de octubre de 2026, actualizada el 9 y el 23 de octubre; en japonés) — jpcert.or.jp
- JPCERT/CC Eyes, análisis de los métodos de ataque en las intrusiones continuas (15 de octubre de 2026; en japonés) — blogs.jpcert.or.jp
- IPA, medidas que deben tomarse con prontitud ante los incidentes de accesos no autorizados (9 de octubre de 2026, actualizada según sea necesario; en japonés) — ipa.go.jp
- Informe de la unidad de investigación de una empresa de inteligencia de amenazas (publicado el 20 de octubre de 2026, actualizado el 23 de octubre) — socradar.io
- Análisis de una empresa japonesa de seguridad (7 de octubre de 2026; no es un documento del sector público; en japonés) — análisis del 7 de octubre
- Proyecto de Seguridad de IA Generativa de OWASP, "LLM01:2025 Prompt Injection" — genai.owasp.org
- Model Context Protocol, "Security Best Practices" (especificación 2025-11-25) — modelcontextprotocol.io
- Los avisos oficiales de cada caso figuran en la sección de fuentes de los informes enlazados arriba.
Registro de cambios
2026-10-24: Se añadió a "Qué es nuevo y qué no" un marco en el que las personas aprueban y la IA ejecuta, y un caso en el que una contraseña reutilizada abrió varias plataformas (informe de una empresa de inteligencia de amenazas del 20 de octubre).
2026-10-24: Primera versión. Se clasificaron las divulgaciones de julio–octubre de 2026 en cuatro tipos y se expuso el orden de defensa a partir de JPCERT/CC, IPA, OWASP y la especificación MCP.
Lectura recomendada
- La ola de intrusiones en Japón: alerta de acceso no autorizado en Japón (octubre de 2026): comprobaciones de esta semana y qué hacer si encuentra algo
- Casos de agentes de IA: agentes de IA que llegan a sitios web reales, y qué deben hacer los operadores de sitios
- Cadena de suministro de IA: malware que roba credenciales en LiteLLM 1.107.0
- Claves de proveedores de IA extraídas de una herramienta: brecha en OpenCode Console (octubre de 2026)
- Lo básico en orden: lista de comprobación de seguridad en la era de la IA (por prioridad)
- Glosario: ¿Qué es SSRF? / ¿Qué es la IA en la sombra?