1. Principales Vulnerabilidades y Filtraciones de la semana

2. AliExpress usaba sonidos inaudibles para rastrearte sin que lo supieras.

3. Pass-ta-key, o cómo el malware puede robar todos tus passkeys de Google sin pedirte ni el dedo

💥CISA ordena a las agencias federales parchear CVE-2026-8452 en Citrix NetScaler ADC y Gateway antes del 29 de agosto: lo que Citrix describió en junio como un desbordamiento de memoria con riesgo de DoS resultó ser, según el análisis de watchTowr, una vía de RCE no autenticado como root. Atacantes ya despliegan web shells (x.php, z.php) en campañas de "spray and pray"; Shadowserver rastrea más de 22.000 appliances NetScaler expuestos a internet. Además, Citrix publicó el mismo mes CVE-2026-19490 (CVSS 9.3), un bypass de autenticación sin parche en ese momento sobre el mismo dispositivo (Noticia / Análisis técnico watchTowr y SecurityWeek)

💥CVE-2026-63077 (CVSS 9.8) en JetBrains TeamCity On-Premises: RCE no autenticado vía deserialización de datos en el protocolo de polling de agentes, que ejecuta comandos arbitrarios del sistema operativo con los privilegios del proceso de TeamCity (credenciales, secretos, artefactos de build, pipelines CI/CD completos al alcance del atacante). Afecta a todas las versiones on-premise; CISA lo añade al KEV el 6 de agosto, solo 9 días después de su divulgación pública. El precedente es malo: los fallos equivalentes de TeamCity de 2024 llevaron a ransomware en miles de servidores expuestos (Noticia / Aviso oficial JetBrains)

💥Explotan activamente CVE-2026-50522 en SharePoint para robar machine keys y mantener persistencia incluso después de parchear el servidor; una vez obtenidas esas claves, el atacante puede forjar tokens de autenticación y seguir accediendo aunque el fallo original esté corregido (Noticia)

💥Un investigador bajo el alias "Nightmare Eclipse" publica un exploit 0-day llamado LegacyHive para Windows que permite escalada de privilegios en sistemas completamente actualizados, seguido pocos días después de un segundo exploit llamado ShieldBreak contra Microsoft Defender, publicado el mismo día del Patch Tuesday de agosto como respuesta directa al proceso de divulgación con Microsoft (Noticia)

💥CVE-2026-60004 en Gitea: inyección de código crítica que permite a un atacante no autenticado modificar o eliminar proyectos públicos; en instancias con auto-registro habilitado (la configuración por defecto) no hacen falta credenciales previas. CISA lo añade al KEV con solo 3 días de plazo. Shadowserver rastrea cerca de 5.000 instancias Gitea expuestas a internet, y se han detectado campañas desplegando malware de minería en servidores sin parchear (Noticia)

AliExpress usaba sonidos inaudibles para rastrearte sin que lo supieras.

La historia empieza con una anomalía que cualquier usuario técnico podría haber ignorado. Matt Callaghan, desarrollador de software, notó que cada vez que abría una pestaña de AliExpress sus auriculares inalámbricos dejaban de funcionar correctamente: en vez de reproducir audio de su teléfono cuando el PC estaba inactivo, como hacen siempre los auriculares multipoint, se quedaban "ocupados" sin razón aparente. Silenciar la pestaña no resolvía nada. Cerrarla sí.

Eso le bastó para empezar a mirar el código de la página. Lo que encontró son dos scripts de seguridad de Alibaba llamados collina.js y fireyejs.js, descritos en la propia documentación interna como herramientas anti-fraude. Ambos estaban fuertemente ofuscados. Una vez desentrañados, revelan que construyen un grafo de audio mediante la WebAudio API del navegador: generan una onda de sierra (sawtooth oscillator), la pasan por un analizador que mide cómo el hardware del dispositivo la procesa, y leen los datos de frecuencia resultantes. El volumen está puesto a cero, así que el usuario no escucha absolutamente nada. Pero el grafo de audio sigue activo en segundo plano, y eso es suficiente para que el sistema operativo considere que ese dispositivo está reproduciendo audio activamente, lo que impide al auricular Bluetooth liberar el canal de audio y cambiar a otro dispositivo.

El principio detrás de esto se llama audio fingerprinting. Cada CPU y cada combinación de hardware procesa las señales de audio de forma ligeramente distinta, con pequeñas variaciones en coma flotante que son consistentes por dispositivo. Esas variaciones, medidas con suficiente precisión, producen un identificador único y estable que no depende de cookies, que no se borra al limpiar el historial, que no cambia al abrir una ventana de incógnito, y que funciona igual aunque el usuario tenga bloqueadores de anuncios. Combinado con todo lo demás que recogen los mismos scripts (dimensiones de pantalla, memoria disponible, WebGL, WebRTC, comportamiento del puntero), el resultado es lo que los investigadores llaman una "firma de dispositivo bastante completa", enviada cifrada a los servidores de telemetría de Alibaba.

Alibaba no ha respondido públicamente. La única posición conocida de la compañía es que estos scripts forman parte de sus herramientas de prevención de fraude, y eso puede ser parcialmente cierto: el fingerprinting se usa legítimamente para detectar bots, cuentas múltiples y comportamiento sospechoso. El problema es que también funciona como mecanismo de rastreo persistente sin ningún tipo de consentimiento ni aviso al usuario, y sin que ninguna API del navegador emita señal visual alguna de que el sistema de audio está siendo usado.

El punto técnico más interesante del caso es que la WebAudio API no tiene ningún modelo de permisos que se parezca al de la cámara o el micrófono. Para usar esas APIs el navegador muestra un diálogo de permiso explícito y un indicador visual mientras están activas. La WebAudio API, en cambio, puede crearse y usarse silenciosamente por cualquier script de cualquier página, sin que el usuario vea nada. Firefox lo describió como "un punto ciego real en el modelo de permisos web actual". El micrófono no estaba escuchando, pero el sistema de audio sí estaba ocupado procesando señales.

La respuesta de los navegadores a este caso es reveladora de cuánto importa elegir bien:

Firefox introdujo protecciones contra el audio fingerprinting en su versión 118 (septiembre 2023), agrupando a todos los usuarios en uno de tres "cubos" según tipo de hardware, de modo que todos los dispositivos dentro del mismo cubo devuelven resultados idénticos al script, neutralizando el tracking. Funciona en el 99,24% de los usuarios. Hay 48 usuarios en todo el mundo que quedan en cubos tan pequeños que siguen siendo identificables, probablemente por hardware muy atípico o bugs de CPU. Firefox confirmó que sus protecciones bloquean el script de AliExpress.

Brave va un paso más allá: inyecta valores aleatorios en los resultados de audio, de modo que el mismo dispositivo devuelve fingerprints distintos en cada sitio y en cada sesión, haciendo el rastreo inútil. Además bloquea específicamente collina.js y fireyejs.js por defecto. Restaurar el comportamiento normal de los auriculares Bluetooth es inmediato al instalar Brave o cambiar de pestaña.

Safari usa un enfoque distinto: inyecta errores aleatorios en el buffer de audio en vez de agrupar usuarios, con resultado similar.

Chrome no tiene ninguna protección activa contra el fingerprinting de audio por defecto. Alexander Hanff, consultor de privacidad, documentó en abril que hay al menos treinta técnicas de fingerprinting distintas funcionando en Chrome en producción, no en laboratorio, en millones de sitios reales. El bloqueador de terceros más práctico mientras tanto es añadir collina.js y fireyejs.js como filtro en uBlock Origin, lo que restaura el comportamiento del Bluetooth inmediatamente.

La historia tiene también una lectura más amplia sobre la privacidad en el ecosistema web. El fingerprinting lleva años siendo una realidad documentada y en gran medida ignorada, precisamente porque no deja rastro visible para el usuario. No hay un icono en la barra del navegador, no hay notificación, no hay forma de saberlo a menos que tengas auriculares multipoint con un comportamiento lo suficientemente extraño como para llamar la atención de alguien que sabe mirar el código fuente. Lo que descubrió Callaghan no es una rareza de AliExpress: es una práctica extendida que simplemente quedó expuesta por un efecto colateral inesperado en hardware Bluetooth.

(Investigación original de Matt Callaghan / The Register / Análisis Firefox)

Pass-ta-key, o cómo el malware puede robar todos tus passkeys de Google sin pedirte ni el dedo

El sector de la identidad lleva dos años prometiendo que los passkeys son el fin de las contraseñas. En mayo de 2026, la FIDO Alliance contaba ya 5.000 millones de passkeys en uso y el 75% de los encuestados había activado alguno. El mensaje era claro: sin contraseña que robar, el phishing queda obsoleto.

Palo Alto Networks Unit 42 publicó el 3 de agosto una investigación que no refuta eso, pero añade una cláusula importante: los passkeys eliminan el phishing de credenciales, pero desplazan el riesgo al endpoint. Si hay malware en el dispositivo, los passkeys sincronizados con Google son robables, y sin que aparezca ningún prompt en pantalla.

Tres ataques, un denominador común. Los investigadores bautizaron la familia como "Pass-ta-key" y documentaron tres variantes. Todas requieren malware ya ejecutándose en el equipo de la víctima con privilegios de usuario normal, sin administrador. Ninguna rompe la criptografía de WebAuthn o FIDO2; explotan capas de implementación alrededor de cómo Chrome gestiona claves de dispositivo, re-enrollment y verificación de usuario.

El primero, Pass-ta-key, abusa directamente del autenticador en la nube de Google Password Manager. Chrome mantiene una clave de identidad de dispositivo respaldada por hardware, pero el autenticador en la nube acepta solicitudes de autenticación enviadas a través de la API del propio proceso de Chrome. El malware puede inyectarse en Chrome e impersonar la solicitud de un sitio legítimo, recibir una aserción WebAuthn válida, y usarla para iniciar sesión desde el dispositivo del atacante, sin que la víctima vea ni una pantalla de confirmación, ni un prompt biométrico, ni nada.

El segundo, Silver Pass-ta-key, explota el flujo de re-enrollment de dispositivos. Cuando un usuario registra un nuevo dispositivo en su cuenta de Google, el proceso acepta una nueva clave de verificación de usuario sin validar adecuadamente que esa clave esté respaldada por hardware real. El malware puede registrar su propia clave de verificación de usuario en el contexto del proceso de Chrome, lo que le permite después iniciar sesión como la víctima desde cualquier máquina del atacante, sin necesidad de tocar el dispositivo original.

El tercero, Golden Pass-ta-key, es el más serio con diferencia. Google Password Manager sincroniza los passkeys entre dispositivos cifrándolos con lo que llama internamente un "security domain secret", una clave maestra de 32 bytes. Cuando un dispositivo se registra o recupera acceso a la cuenta, Chrome recibe esa clave temporalmente. Unit 42 descubrió que Chrome la dejaba en texto claro en sus logs internos de FIDO. Google eliminó el secret de los logs cuando los investigadores lo reportaron, pero la clave sigue pasando por la memoria del proceso de Chrome en algún momento del flujo, y sigue siendo accesible mediante técnicas estándar de lectura de memoria de proceso, sin privilegios de administrador.

La implicación es la que hace de este ataque algo cualitativamente distinto: con esos 32 bytes, el atacante puede descifrar todos los passkeys sincronizados en la cuenta de Google de la víctima, extraer sus claves privadas, y usarlas desde cualquier otro dispositivo para autenticarse en cualquier servicio que acepte esos passkeys. Y el problema no tiene solución de rotación: Google no proporciona actualmente ningún mecanismo para revocar o cambiar esa clave maestra, lo que significa que los passkeys actuales y futuros de la cuenta quedan comprometidos por el mismo secret robado.

Contexto importante. No hay explotación en la naturaleza reportada hasta la fecha, y no se ha asignado ningún CVE a los hallazgos de Unit 42. El prerequisito del malware es real y significativo: si el endpoint ya está comprometido, el atacante tiene acceso a cookies de sesión, historial del navegador, contraseñas guardadas y cualquier otra credencial almacenada. En ese escenario, los passkeys no son el único problema. Lo que cambia con Pass-ta-key es que los passkeys sincronizados dejan de ser el elemento "imposible de robar" que los distingue del resto de credenciales.

La arquitectura del problema. Los passkeys como estándar FIDO2 están diseñados para que la clave privada nunca salga del dispositivo. En implementaciones locales (clave almacenada en el TPM o en el secure enclave del móvil) esto se cumple. El punto débil está en la sincronización: para que un passkey funcione en todos tus dispositivos, Google necesita poder replicarlo, y eso implica cifrarlo con una clave que el servidor también conoce de alguna forma. Golden Pass-ta-key explota precisamente esa necesidad: la clave de sincronización tiene que existir en algún momento en la memoria del cliente.

Unit 42 recomienda que los servicios dejen de confiar ciegamente en el flag de user-verification de WebAuthn y validen que realmente ocurrió un evento de verificación de usuario antes de conceder acceso. A Google le piden endurecer el registro y recuperación de dispositivos y verificar que las nuevas claves están respaldadas por hardware real, no aceptarlas a ciegas. Mientras tanto, la protección más efectiva sigue siendo la misma de siempre: mantener el endpoint libre de malware, porque si hay malware en el dispositivo ninguna capa de autenticación, por avanzada que sea, garantiza nada.

(Informe técnico Unit 42 / Cobertura Malwarebytes / BleepingComputer)

Ver historial de Publicaciones