La inteligencia de IA de frontera es el premio más codiciado de la ciberseguridad.
La única pregunta es: ¿quién se queda con el mejor corte?
Ahora mismo, la velocidad ofensiva se está llevando la ventaja. Los atacantes que despliegan frameworks de IA agéntica acaban de comprometer 50 aplicaciones empresariales en menos de 10 horas, una campaña que antes llevaba 10 días.
Más de 100 líderes tecnológicos acaban de firmar una carta abierta que advierte de que la infraestructura digital se está quedando sin tiempo. Mientras los laboratorios de frontera establecen programas con acceso restringido, como OpenAI Daybreak y Cyber Verification de Anthropic, para empoderar a los defensores, el sector afronta una carrera incómoda: ¿puede la defensa automatizada escalar antes de que la explotación a la velocidad de las máquinas tome el control?
También en este número: cómo el phishing de voz eludió la MFA en segundos, un modelo de IA que escapó de su sandbox tres veces, la multa de 825 M€ a Uber por gobernanza automatizada, y cómo Kiji detiene las fugas de PII en los prompts directamente en los equipos de los desarrolladores.
En este número
🌡️ Nivel de amenaza: Alerta alta
⚡ Noticias: Cinco historias de seguridad para ponerse al día
🔎 Análisis a fondo: La ventana de los defensores se está cerrando
🎣 ¿Es phishing?
🔬 Investigación técnica: La MFA cayó. La confianza en el dispositivo resistió.
🛠️ Herramienta de la semana: Kiji Privacy Proxy
👤 Persona de la semana: Hannes Hapke
📅 Evento de la semana: GrrCON 2026
📚 Libro de la semana: The Android Hacker’s Handbook de Joshua J. Drake et al.
😅 El meme
❓ Una pregunta antes de despedirnos
Vamos al grano.
Antes de entrar en las historias de esta semana, este es el estado del nivel de amenaza.
🌡️ Nivel de amenaza
⚡ Noticias
Una sola configuración de git de varias líneas basta para provocar RCE en GitPython
Una vulnerabilidad crítica en GitPython (CVE-2026-78676, CVSS 9.8) permite a los atacantes lograr la ejecución remota de código (RCE) cuando las aplicaciones analizan configuraciones de repositorio no confiables. Kodem Security reveló que el fallo se debe a una reserialización insegura de valores de configuración de varias líneas al escribir, lo que permite a un atacante inyectar argumentos que sobrescriben core.hooksPath durante operaciones git posteriores. Actualice a GitPython 3.1.59 de inmediato y trate todos los archivos de configuración de repositorios como entradas de usuario no confiables dentro de los pipelines automatizados de CI/CD y de escaneo.
PaperCut insta a aplicar parches de emergencia mientras los atacantes encadenan zero-days para lograr RCE en servidores de impresión
PaperCut publicó avisos de emergencia y guías de bastionado tras la explotación activa en entornos reales que informaron investigadores de seguridad y que apunta a servidores PaperCut NG y MF. Los actores de amenazas encadenaron varias vulnerabilidades para lograr ejecución remota de código sin autenticación en servidores de impresión expuestos a internet, sin necesidad de credenciales. Aplique los parches del proveedor de inmediato, restrinja el acceso a los puertos de administración a VLAN de gestión internas y privadas, y supervise los servidores de impresión para detectar ejecuciones anómalas de procesos hijo.
Cuentas de hosting sin privilegios pueden hacerse con el root completo del servidor en cPanel
cPanel publicó actualizaciones obligatorias que corrigen CVE-2026-65643, una vulnerabilidad crítica de escalada de privilegios que afecta al manejo de dominios aparcados y dominios adicionales en cPanel y WebHost Manager (WHM). Las divulgaciones de seguridad confirmaron que el fallo permite a un inquilino sin privilegios de una infraestructura de hosting compartido eludir las comprobaciones de límites y ejecutar comandos arbitrarios con privilegios de root completos. Los proveedores de hosting compartido deben aplicar de inmediato la última compilación de cPanel/WHM y auditar las configuraciones de cron de root para detectar rutas de ejecución de scripts inesperadas.
Cálculos de saldo defectuosos permiten a los atacantes drenar fondos en seis blockchains
Cosmos Labs publicó una alerta de emergencia sobre una vulnerabilidad crítica en el manejo de saldos del módulo compartido Cosmos EVM (GHSA-7g4w-cg88-2cq2). BleepingComputer informó de que los atacantes explotaron activamente el fallo lógico entre el 20 y el 25 de agosto para drenar liquidez en al menos seis redes independientes antes de que se desplegaran mitigaciones coordinadas en los validadores. Los equipos del protocolo base deben implementar una monitorización automatizada de invariantes que detenga la ejecución de transacciones siempre que los saldos globales de tokens no superen las comprobaciones de coherencia matemática.
Por qué los tokens OIDC de CI/CD sin restricciones siguen siendo una puerta abierta a la infraestructura en la nube
Investigadores de seguridad publicaron un análisis que demuestra cómo los permisos comodín id-token: write en los flujos de trabajo de GitHub Actions exponen a las organizaciones a movimiento lateral entre nubes. La investigación señaló que, cuando una dependencia comprometida infecta un flujo de trabajo de publicación de paquetes, puede emitir tokens OIDC para proveedores de nube no previstos (como AWS) a menos que se aplique de forma explícita una vinculación estricta de audiencia en la capa del proveedor de identidad. Configure las políticas de confianza de IAM en la nube con claims explícitos de audiencia (aud) y de sujeto (sub) para garantizar que los runners de compilación no puedan suplantar roles de producción no relacionados.
🔎 Análisis a fondo
La ventana de los defensores se está cerrando
Más de 100 líderes tecnológicos acaban de firmar la misma carta.
Entre los firmantes figuran OpenAI, Anthropic y Google, junto con empresas de seguridad como CrowdStrike, Fortinet y Okta. Su mensaje no es sutil: los ataques automatizados y habilitados por IA están a punto de escalar, y la infraestructura digital no está preparada.
La advertencia ya no es solo un debate teórico sobre riesgos futuros. Ya se está materializando en entornos reales.
El compromiso en 10 horas
A principios de este año, Palo Alto Networks Unit 42 estimó que pasaría un año antes de que las capacidades avanzadas de IA agéntica llegaran a manos de los atacantes.
Tardaron cinco meses.
Unit 42 está investigando actualmente un incidente en el que un atacante usó un framework de IA agéntica para explotar 50 aplicaciones empresariales. El compromiso llevó menos de 10 horas. En la era previa a la IA, la misma campaña habría tardado al menos 10 días.
Este es el cambio generacional sobre el que advierte la carta abierta. La IA es ahora un multiplicador de fuerza en toda la cadena de ataque, desde el desarrollo de malware hasta la ingeniería social y la negociación de ransomware. Los atacantes la utilizan para infiltrarse en las cadenas de suministro de software a la velocidad de las máquinas.
Dos calendarios en competencia
La carta abierta señala dos realidades que avanzan a velocidades distintas:
Automatización ofensiva: los modelos de IA son cada vez más capaces de descubrir vulnerabilidades, escribir exploits y atacar infraestructuras con una dirección humana mínima.
Deuda defensiva: los sistemas esenciales, desde hospitales hasta plantas de tratamiento de agua, siguen expuestos por software heredado, permisos excesivos y errores sin parchear.
Eso crea lo que la coalición llama la «ventana de los defensores».
Ahora mismo, los equipos defensivos tienen acceso a las mismas capacidades de frontera que los atacantes. La IA puede digerir bases de código, identificar configuraciones incorrectas y redactar correcciones más rápido que las revisiones manuales tradicionales.
La ventana solo existe mientras los defensores escalen la automatización más rápido que los adversarios.
Las cuatro prioridades
Para cerrar la brecha, la coalición plantea cuatro líneas principales:
Para los equipos de las empresas: traten la defensa con la urgencia de un incidente activo. Corrijan las configuraciones incorrectas de alto riesgo, restrinjan los permisos y utilicen modelos de menor coste para el análisis de registros y código de gran volumen, reservando los modelos de frontera para los casos límite complejos.
Para los proveedores de seguridad: prueben continuamente sus herramientas frente a las capacidades de los agentes de IA de frontera y compartan playbooks verificados con operadores con pocos recursos.
Para los gobiernos: dirijan la financiación defensiva a las infraestructuras críticas, amplíen el intercambio de inteligencia de amenazas e impongan costes reales a los actores de amenazas.
Para los laboratorios de IA: proporcionen acceso a los modelos a los equipos defensivos, garanticen que las identidades agénticas sean trazables y mantengan canales de divulgación responsable.
Los laboratorios de IA de frontera ya están poniendo en práctica este cambio mediante programas de acceso restringido para equipos de seguridad verificados. OpenAI amplió su iniciativa Daybreak, con la introducción de Daybreak Blue y Daybreak Red para dar a los defensores aprobados acceso a modelos como GPT-5.6-Cyber, sin barreras de protección, para el descubrimiento de vulnerabilidades y la validación de exploits. De forma similar, Anthropic estableció su Cyber Verification Program, que ofrece a profesionales y organizaciones de seguridad verificados salvaguardas modificadas en los modelos Claude para realizar pruebas e investigaciones autorizadas sin provocar rechazos por falsos positivos.
La tensión en el centro
La carta contiene una paradoja incómoda.
Las empresas de IA de frontera que lideran el llamado a la defensa son las mismas entidades que desarrollan las capacidades que hacen posible la explotación autónoma.
La carta reconoce que ninguna organización controlará por sí sola hacia dónde evolucionan las capacidades de la IA. La postura de seguridad de la infraestructura digital no dependerá de frenar el progreso de los modelos. Dependerá de si la corrección defensiva puede por fin avanzar más rápido que el descubrimiento automatizado.
Hasta entonces, la ventana está abierta, pero el reloj corre.
🎣 ¿Es phishing?
Dificultad: media
El correo incluye un botón que le pide proteger su cuenta:
👉 Cambiar contraseña
Enlace:
http://myaccount.google.com-securitysettingpage.ml-security.org/signonoptions/¿Qué hace?
🔐 Hacer clic en el enlace y actualizar las credenciales
🗑️ Denunciarlo como phishing y acceder manualmente a la configuración de su cuenta
🔬 Investigación técnica
La MFA cayó. La confianza en el dispositivo resistió.
Se nos repite constantemente que la autenticación multifactor es la respuesta al phishing.
Pero a veces la MFA falla por completo y, aun así, la empresa no sufre una brecha.
Esa es la incómoda realidad detrás del ataque a ReliaQuest el 22 de agosto de 2026. La empresa de ciberseguridad confirmó el 23 de agosto de 2026 que había sido objetivo de un atacante que decía estar afiliado al grupo de extorsión ShinyHunters. El propio relato de ReliaQuest indica que los atacantes derrotaron tanto la contraseña como la notificación push de MFA de un empleado.
Nota: ReliaQuest discute que se hable de «brecha». ShinyHunters publicó en su sitio de filtraciones capturas de pantalla del panel de Okta para afirmar que el compromiso fue mayor, pero los investigadores que revisaron las capturas dijeron que solo mostraban la página de configuración de un usuario, y ReliaQuest sostiene que nunca se llegó a ninguna aplicación, sistema ni dato de clientes. Lo que sigue es el relato publicado por ReliaQuest sobre el incidente.
Dónde falló el perímetro
El fallo ocurrió en la capa humana, eludida mediante un pretexto muy convincente.
Los atacantes llevaron a cabo una campaña de phishing de voz (vishing): llamaron a empleados de ReliaQuest haciéndose pasar por un miembro del propio equipo de seguridad de la empresa. El interlocutor indicó a las víctimas que iniciaran sesión en un portal de inicio de sesión único (SSO) alojado en un dominio similar: reliaquest.claims.
Un empleado cayó en el engaño. Accedió a la página falsa, introdujo sus credenciales y, lo que es crucial, aprobó manualmente la notificación push de MFA que recibió a continuación en su teléfono.
En ese preciso instante, el perímetro de identidad estándar se derrumbó. El atacante ya tenía una contraseña válida y una sesión aprobada por MFA.
El flujo del ataque
La cadena de ataque paso a paso
La llamada de vishing: los atacantes se hacen pasar por un miembro del equipo de seguridad y dirigen al empleado a un portal de inicio de sesión falso.
El dominio similar: el empleado accede a reliaquest.claims en lugar de a la URL legítima del SSO.
La captura de credenciales: el empleado introduce su contraseña válida en el sitio de captura.
La elusión de la MFA: el empleado recibe una notificación push de MFA legítima y la aprueba, creyendo que corresponde a su propio intento de inicio de sesión.
El salto al panel: el atacante obtiene acceso temporal, de solo lectura, al panel de identidad de ReliaQuest (Okta).
El bloqueo: el atacante intenta saltar del panel a aplicaciones posteriores, pero se le deniega el acceso porque la sesión de origen no está vinculada a un endpoint corporativo registrado y conforme con el MDM.
Por qué importa
Una notificación push es, en última instancia, una decisión humana.
Cuando la seguridad depende por completo de que un empleado pulse «Aprobar» o «Denegar», un ingeniero social hábil acabará convenciéndolo de pulsar «Aprobar».
Este incidente deja al descubierto la brecha entre autenticar a un usuario y autenticar un dispositivo. Los atacantes robaron el contexto de identidad del usuario, pero no pudieron presentar el portátil corporativo físico y registrado. Como ReliaQuest tenía controles de confianza en el dispositivo por debajo del portal de SSO, el intento de salto se topó con un muro concreto.
Las sesiones del atacante se cerraron, la contraseña comprometida se hizo caducar y se restablecieron los factores de autenticación. Cabe destacar que el propio ShinyHunters dijo a los periodistas que su acceso era de solo lectura y que no llegó a ninguna aplicación, sistema ni dato de clientes, lo que corrobora el relato de ReliaQuest en ese punto concreto.
Qué deben aprender los defensores
La lección para los equipos de seguridad es sencilla: si su estrategia de resistencia al phishing termina en las notificaciones push de MFA, está incompleta.
Implante MFA resistente al phishing: pase a passkeys FIDO2 / WebAuthn o a llaves de seguridad de hardware que vinculan criptográficamente el flujo de autenticación al origen legítimo del navegador, neutralizando por completo la captura de credenciales y la fatiga de notificaciones push.
Dé por hecho que la MFA push será eludida: considere que las notificaciones push de MFA estándar son vulnerables a la fatiga de MFA y a los pretextos de vishing.
Exija la confianza en el dispositivo: configure sus políticas de SSO y de acceso a la red de confianza cero (ZTNA) para bloquear el acceso a las aplicaciones salvo que la solicitud provenga de un endpoint corporativo conforme y registrado en el MDM.
Vigile los registros de dominios similares: busque de forma activa dominios recién registrados que abusen del nombre de su empresa junto con dominios de nivel superior poco comunes, exactamente como el patrón .claims utilizado aquí.
Investigue el acceso de solo lectura: trate cualquier acceso no autorizado a un panel de identidad como un incidente crítico, aunque las aplicaciones posteriores estén bloqueadas.
🛠️ Herramienta de la semana
Kiji Privacy Proxy
GitHub: https://github.com/dataiku/kiji-proxy
Gateway local de código abierto para enmascarar PII en los prompts enviados a las API de IA.
Dónde encaja: endpoints de desarrolladores, agentes locales de programación con IA y prevención de pérdida de datos (DLP).
Qué hace: a medida que los equipos de seguridad adoptan asistentes locales de programación con IA y agentes de línea de comandos, los archivos de configuración sensibles, los registros internos de clientes y las credenciales acaban con frecuencia dentro de los payloads de prompts salientes.
Dataiku ’s kiji-proxy coloca un punto de control ligero, del lado del cliente, entre las estaciones de trabajo de los desarrolladores y las API de proveedores de IA externos (OpenAI, Anthropic, Gemini):
Aprendizaje automático local: ejecuta localmente en el equipo anfitrión un modelo transformer optimizado con ONNX (DistilBERT) para detectar 26 tipos de PII, incluidos correos electrónicos, SSN, tarjetas de crédito y nombres, con una latencia inferior a 100 ms.
Sustitución según el contexto: en lugar de insertar bloques [REDACTED] destructivos que confunden el razonamiento del modelo, reemplaza los valores sensibles por datos sintéticos realistas para que el LLM conserve el contexto natural.
Restauración en tránsito: intercepta la respuesta de la API que vuelve del proveedor del modelo y, de forma silenciosa, devuelve localmente los valores reales originales a su lugar antes de entregar la salida al usuario.
Inicio rápido
# Route CLI tools or terminal agents through Kiji's local transparent proxy
export HTTP_PROXY=http://127.0.0.1:8081
export HTTPS_PROXY=http://127.0.0.1:8081
# Run your usual AI workflows—PII is sanitized in flight and restored locally
cat support_dump.txt | claude -p "summarize this customer feedback"Lo que no reemplaza
Gateways de red de nivel empresarial ni soluciones DLP de API del lado del servidor. kiji-proxy opera en el nivel de la estación de trabajo del desarrollador para evitar la exfiltración accidental de prompts antes de que los payloads de red salgan siquiera del equipo local.
👤 Persona de la semana
Hannes Hapke
Esta semana destacamos a Hannes Hapke, responsable de 575 Lab (la oficina de investigación de código abierto de Dataiku), Google Developer Expert y coautor de varios libros sobre sistemas de aprendizaje automático en producción con O’Reilly y Manning.
A medida que los equipos de desarrollo y de seguridad incorporan agentes de IA de línea de comandos y herramientas LLM en su trabajo diario, los datos sensibles (desde registros internos hasta claves de API) pueden acabar fácilmente dentro de los payloads de prompts salientes. Para abordarlo, Hannes lideró la creación y la publicación como código abierto de Kiji Privacy Proxy.
En lugar de depender de pesadas barreras de cumplimiento empresarial o de filtros del lado del servidor, Kiji adopta un enfoque centrado en el desarrollador: ejecuta un proxy de ML ligero directamente en la estación de trabajo para detectar y enmascarar la PII localmente antes de que las solicitudes de red salgan del equipo, y luego restaura los valores originales cuando vuelven las respuestas.
Por crear herramientas prácticas de código abierto que ayudan a los desarrolladores a adoptar flujos de trabajo de IA de forma segura, sin arriesgar la exposición de datos sensibles, Hannes Hapke es nuestra Persona de la semana. 👏
📅 Evento de la semana
GrrCON 2026
Unos 2,800 investigadores de seguridad, desarrolladores, directivos y hackers éticos se reunirán en Grand Rapids este septiembre para la 15.ª edición de GrrCON, organizada por MidWest InfoSec, LLC , la principal conferencia de ciberseguridad e inteligencia artificial del Medio Oeste.
Conocida por su ambiente informal y sin egos, GrrCON da prioridad a la seguridad práctica, la colaboración abierta y la investigación frente a los discursos comerciales de venta. El programa de dos días incluye varias líneas de presentaciones técnicas, además de talleres dirigidos por profesionales y villages prácticos.
Para los equipos de AppSec e ingeniería de seguridad, la conferencia ofrece análisis en profundidad sobre explotación ofensiva, threat hunting, ingeniería defensiva y gestión de riesgos emergentes de la IA, lo que la convierte en un gran lugar para obtener conocimientos accionables y establecer contactos con colegas.
📍 Lugar: DeVos Place, Grand Rapids, Michigan
📅 Fecha: 24 y 25 de septiembre de 2026
📚 Libro de la semana
Android Hacker’s Handbook
De Joshua J. Drake , Zach Lanier , Collin Mulliner , Pau Oliva Fora, Stephen A. Ridley y Georg Wicherski
¿Cómo se desmonta el funcionamiento interno del sistema operativo Android?
Publicado por Wiley, Android Hacker’s Handbook fue la primera guía técnica integral dedicada a comprender, auditar y analizar vulnerabilidades en la plataforma Android.
Áreas principales:
Arquitectura del SO y modelo de seguridad: examina la mecánica subyacente de cómo Android implementa su diseño de seguridad en el kernel de Linux, los demonios nativos y los frameworks principales.
Análisis de vulnerabilidades: explica metodologías para identificar debilidades en componentes del sistema, servicios principales y bibliotecas nativas de C/C++.
Procesos de rooteo: desglosa la disposición de las particiones de hardware y el proceso de arranque necesarios para obtener privilegios elevados.
Fuzz testing: enseña enfoques para el descubrimiento automatizado de vulnerabilidades mediante herramientas de fuzzing y auditoría de IPC/Binder.
Auditoría de aplicaciones: detalla técnicas para descomponer, aplicar ingeniería inversa y proteger aplicaciones Android individuales.
Contexto y evolución:
Publicado en 2014, el libro ofrece a los lectores una base técnica sólida sobre el funcionamiento interno de Android. En los últimos 12 años, la plataforma ha experimentado grandes cambios de arquitectura, entre ellos la transición al tiempo de ejecución ART, la aplicación obligatoria de SELinux, las implementaciones de Keystore/StrongBox respaldadas por hardware, las actualizaciones modulares APEX, la adopción de Rust en todo el sistema y el etiquetado de memoria de ARM (MTE).
Aunque los principios fundamentales siguen siendo útiles, 12 años de evolución de la plataforma justifican con claridad una segunda edición actualizada.
😅 El meme
Estado del ticket de Jira: bloqueado (por el hacker) 🥺
Si los frameworks agénticos autónomos pueden descubrir y explotar vulnerabilidades en 50 aplicaciones empresariales en menos de 10 horas, ¿cuál es el único control defensivo que su equipo no puede permitirse dejar en manos manuales?
The Breach Brief, Equipo de Ostorlab