Una extensión de navegador usada para mejorar la experiencia en Twitch expuso credenciales de acceso de aproximadamente 31.000 personas al enviar sus tokens OAuth a infraestructura ajena. El problema afecta a Twitch Enhanced Viewer | JeetBot, que se distribuyó tanto en Chrome Web Store como en Mozilla Add-ons, un recordatorio incómodo de que incluso los catálogos ‘oficiales’ no blindan frente a riesgos de cadena de suministro.

La pieza clave son los tokens OAuth que usa Twitch para mantener una sesión autenticada. No funcionan como una simple referencia interna: actúan como credenciales bearer, es decir, quien los posee puede operar como si fuese el usuario. En la práctica, el abuso puede ir desde leer y enviar susurros hasta escribir en el chat o tocar ajustes vinculados a la cuenta, sin necesidad de conocer la contraseña ni superar un 2FA.

El comportamiento más delicado llegó con la rama v85.x. La extensión añadió el token como parámetro de consulta &auth= durante redirecciones a nivel de red hacia servidores proxy controlados por el operador. Al viajar dentro de una URL, el token podía quedar en texto claro en registros del proxy, lo que multiplica el riesgo si esos logs se consultan de forma indebida o acaban filtrándose.

El reenvío se aplicaba a prácticamente cualquier canal que el usuario abriese, con una excepción: una lista predeterminada de 10 canales. Desde la 85.8.4, además, la extensión permitía ajustar restricciones con el parámetro Channels with restrictions, lo que introduce un control aparente, pero no evita el problema de fondo: la exfiltración del token.

No era la primera vez que la extensión jugaba con este tipo de datos. Versiones anteriores v4.x llegaron a remitir el token mediante POST a un endpoint set-token del operador e incluso definieron endpoints de respaldo alojados en deno.dev y deno.net.

La corrección ya está disponible en Firefox a partir de la versión 85.8.7, que elimina el envío del token al cambiar el método de obtención de playlists. El desarrollador ha indicado que preparaba un parche equivalente para Chrome, aunque aquí hay un matiz importante: actualizar o desactivar frena la fuga a partir de ese momento, pero no invalida los tokens que ya salieron.

La recomendación para usuarios pasa por desinstalar o desactivar Twitch Enhanced Viewer | JeetBot de inmediato y, si se usa Firefox, actualizar como mínimo a 85.8.7. Después conviene cerrar todas las sesiones activas de Twitch desde la configuración de la cuenta y volver a autenticarse para forzar la rotación de sesiones. También merece la pena revisar actividad reciente, mensajes privados y acciones en chat en busca de uso no autorizado.

En organizaciones y equipos gestionados, este incidente encaja en un patrón clásico: extensiones con capacidad para interceptar o redirigir tráfico de servicios autenticados. Aquí la higiene básica es inventariar extensiones instaladas, bloquear por política los identificadores afectados, pnhhdhhcadcjfckjhpmjneldiegbojfb en Chrome y twitchenhancedviewer@example.com en Firefox, y priorizar listas de permitidos en navegadores corporativos. La comodidad no debería tener acceso ilimitado a una sesión.

Más información

• The Hacker News – Malicious Twitch Browser Extension Leaks OAuth Tokens From Nearly 31,000 Users : https://thehackernews.com/2026/09/malicious-twitch-browser-extension.html
• JeetBot Docs – Twitch Enhanced Viewer : https://docs.jeetbot.cc/en/base-stuff/extension/
• NEXSIGHT CYBER WIRE – Twitch視聴拡張機能「JeetBot」が3万人のOAuthトークンを窃取 — Socketが報告、ロシアのボット事業者の代理サーバーへ転送 : https://cyber.nexsight.co/articles/2026/09/12/socket-twitch-jeetbot-extension-oauth-token-theft-2026-09-12/

La entrada Una extensión para Twitch filtró tokens OAuth de casi 31.000 usuarios se publicó primero en Una Al Día.

Una extensión de navegador usada para mejorar la experiencia en Twitch expuso credenciales de acceso de aproximadamente 31.000 personas al enviar sus tokens OAuth a infraestructura ajena. El problema afecta a Twitch Enhanced Viewer | JeetBot, que se distribuyó tanto en Chrome Web Store como en Mozilla Add-ons, un recordatorio incómodo de que incluso los catálogos ‘oficiales’ no blindan frente a riesgos de cadena de suministro.

La pieza clave son los tokens OAuth que usa Twitch para mantener una sesión autenticada. No funcionan como una simple referencia interna: actúan como credenciales bearer, es decir, quien los posee puede operar como si fuese el usuario. En la práctica, el abuso puede ir desde leer y enviar susurros hasta escribir en el chat o tocar ajustes vinculados a la cuenta, sin necesidad de conocer la contraseña ni superar un 2FA.

El comportamiento más delicado llegó con la rama v85.x. La extensión añadió el token como parámetro de consulta &auth= durante redirecciones a nivel de red hacia servidores proxy controlados por el operador. Al viajar dentro de una URL, el token podía quedar en texto claro en registros del proxy, lo que multiplica el riesgo si esos logs se consultan de forma indebida o acaban filtrándose.

El reenvío se aplicaba a prácticamente cualquier canal que el usuario abriese, con una excepción: una lista predeterminada de 10 canales. Desde la 85.8.4, además, la extensión permitía ajustar restricciones con el parámetro Channels with restrictions, lo que introduce un control aparente, pero no evita el problema de fondo: la exfiltración del token.

No era la primera vez que la extensión jugaba con este tipo de datos. Versiones anteriores v4.x llegaron a remitir el token mediante POST a un endpoint set-token del operador e incluso definieron endpoints de respaldo alojados en deno.dev y deno.net.

La corrección ya está disponible en Firefox a partir de la versión 85.8.7, que elimina el envío del token al cambiar el método de obtención de playlists. El desarrollador ha indicado que preparaba un parche equivalente para Chrome, aunque aquí hay un matiz importante: actualizar o desactivar frena la fuga a partir de ese momento, pero no invalida los tokens que ya salieron.

La recomendación para usuarios pasa por desinstalar o desactivar Twitch Enhanced Viewer | JeetBot de inmediato y, si se usa Firefox, actualizar como mínimo a 85.8.7. Después conviene cerrar todas las sesiones activas de Twitch desde la configuración de la cuenta y volver a autenticarse para forzar la rotación de sesiones. También merece la pena revisar actividad reciente, mensajes privados y acciones en chat en busca de uso no autorizado.

En organizaciones y equipos gestionados, este incidente encaja en un patrón clásico: extensiones con capacidad para interceptar o redirigir tráfico de servicios autenticados. Aquí la higiene básica es inventariar extensiones instaladas, bloquear por política los identificadores afectados, pnhhdhhcadcjfckjhpmjneldiegbojfb en Chrome y twitchenhancedviewer@example.com en Firefox, y priorizar listas de permitidos en navegadores corporativos. La comodidad no debería tener acceso ilimitado a una sesión.

Más información

• The Hacker News – Malicious Twitch Browser Extension Leaks OAuth Tokens From Nearly 31,000 Users : https://thehackernews.com/2026/09/malicious-twitch-browser-extension.html
• JeetBot Docs – Twitch Enhanced Viewer : https://docs.jeetbot.cc/en/base-stuff/extension/
• NEXSIGHT CYBER WIRE – Twitch視聴拡張機能「JeetBot」が3万人のOAuthトークンを窃取 — Socketが報告、ロシアのボット事業者の代理サーバーへ転送 : https://cyber.nexsight.co/articles/2026/09/12/socket-twitch-jeetbot-extension-oauth-token-theft-2026-09-12/

La entrada Una extensión para Twitch filtró tokens OAuth de casi 31.000 usuarios se publicó primero en Una Al Día.

Una extensión de navegador usada para mejorar la experiencia en Twitch expuso credenciales de acceso de aproximadamente 31.000 personas al enviar sus tokens OAuth a infraestructura ajena. El problema afecta a Twitch Enhanced Viewer | JeetBot, que se distribuyó tanto en Chrome Web Store como en Mozilla Add-ons, un recordatorio incómodo de que incluso los catálogos ‘oficiales’ no blindan frente a riesgos de cadena de suministro.

La pieza clave son los tokens OAuth que usa Twitch para mantener una sesión autenticada. No funcionan como una simple referencia interna: actúan como credenciales bearer, es decir, quien los posee puede operar como si fuese el usuario. En la práctica, el abuso puede ir desde leer y enviar susurros hasta escribir en el chat o tocar ajustes vinculados a la cuenta, sin necesidad de conocer la contraseña ni superar un 2FA.

El comportamiento más delicado llegó con la rama v85.x. La extensión añadió el token como parámetro de consulta &auth= durante redirecciones a nivel de red hacia servidores proxy controlados por el operador. Al viajar dentro de una URL, el token podía quedar en texto claro en registros del proxy, lo que multiplica el riesgo si esos logs se consultan de forma indebida o acaban filtrándose.

El reenvío se aplicaba a prácticamente cualquier canal que el usuario abriese, con una excepción: una lista predeterminada de 10 canales. Desde la 85.8.4, además, la extensión permitía ajustar restricciones con el parámetro Channels with restrictions, lo que introduce un control aparente, pero no evita el problema de fondo: la exfiltración del token.

No era la primera vez que la extensión jugaba con este tipo de datos. Versiones anteriores v4.x llegaron a remitir el token mediante POST a un endpoint set-token del operador e incluso definieron endpoints de respaldo alojados en deno.dev y deno.net.

La corrección ya está disponible en Firefox a partir de la versión 85.8.7, que elimina el envío del token al cambiar el método de obtención de playlists. El desarrollador ha indicado que preparaba un parche equivalente para Chrome, aunque aquí hay un matiz importante: actualizar o desactivar frena la fuga a partir de ese momento, pero no invalida los tokens que ya salieron.

La recomendación para usuarios pasa por desinstalar o desactivar Twitch Enhanced Viewer | JeetBot de inmediato y, si se usa Firefox, actualizar como mínimo a 85.8.7. Después conviene cerrar todas las sesiones activas de Twitch desde la configuración de la cuenta y volver a autenticarse para forzar la rotación de sesiones. También merece la pena revisar actividad reciente, mensajes privados y acciones en chat en busca de uso no autorizado.

En organizaciones y equipos gestionados, este incidente encaja en un patrón clásico: extensiones con capacidad para interceptar o redirigir tráfico de servicios autenticados. Aquí la higiene básica es inventariar extensiones instaladas, bloquear por política los identificadores afectados, pnhhdhhcadcjfckjhpmjneldiegbojfb en Chrome y twitchenhancedviewer@example.com en Firefox, y priorizar listas de permitidos en navegadores corporativos. La comodidad no debería tener acceso ilimitado a una sesión.

Más información

• The Hacker News – Malicious Twitch Browser Extension Leaks OAuth Tokens From Nearly 31,000 Users : https://thehackernews.com/2026/09/malicious-twitch-browser-extension.html
• JeetBot Docs – Twitch Enhanced Viewer : https://docs.jeetbot.cc/en/base-stuff/extension/
• NEXSIGHT CYBER WIRE – Twitch視聴拡張機能「JeetBot」が3万人のOAuthトークンを窃取 — Socketが報告、ロシアのボット事業者の代理サーバーへ転送 : https://cyber.nexsight.co/articles/2026/09/12/socket-twitch-jeetbot-extension-oauth-token-theft-2026-09-12/

La entrada Una extensión para Twitch filtró tokens OAuth de casi 31.000 usuarios se publicó primero en Una Al Día.

Una extensión de navegador usada para mejorar la experiencia en Twitch expuso credenciales de acceso de aproximadamente 31.000 personas al enviar sus tokens OAuth a infraestructura ajena. El problema afecta a Twitch Enhanced Viewer | JeetBot, que se distribuyó tanto en Chrome Web Store como en Mozilla Add-ons, un recordatorio incómodo de que incluso los catálogos ‘oficiales’ no blindan frente a riesgos de cadena de suministro.

La pieza clave son los tokens OAuth que usa Twitch para mantener una sesión autenticada. No funcionan como una simple referencia interna: actúan como credenciales bearer, es decir, quien los posee puede operar como si fuese el usuario. En la práctica, el abuso puede ir desde leer y enviar susurros hasta escribir en el chat o tocar ajustes vinculados a la cuenta, sin necesidad de conocer la contraseña ni superar un 2FA.

El comportamiento más delicado llegó con la rama v85.x. La extensión añadió el token como parámetro de consulta &auth= durante redirecciones a nivel de red hacia servidores proxy controlados por el operador. Al viajar dentro de una URL, el token podía quedar en texto claro en registros del proxy, lo que multiplica el riesgo si esos logs se consultan de forma indebida o acaban filtrándose.

El reenvío se aplicaba a prácticamente cualquier canal que el usuario abriese, con una excepción: una lista predeterminada de 10 canales. Desde la 85.8.4, además, la extensión permitía ajustar restricciones con el parámetro Channels with restrictions, lo que introduce un control aparente, pero no evita el problema de fondo: la exfiltración del token.

No era la primera vez que la extensión jugaba con este tipo de datos. Versiones anteriores v4.x llegaron a remitir el token mediante POST a un endpoint set-token del operador e incluso definieron endpoints de respaldo alojados en deno.dev y deno.net.

La corrección ya está disponible en Firefox a partir de la versión 85.8.7, que elimina el envío del token al cambiar el método de obtención de playlists. El desarrollador ha indicado que preparaba un parche equivalente para Chrome, aunque aquí hay un matiz importante: actualizar o desactivar frena la fuga a partir de ese momento, pero no invalida los tokens que ya salieron.

La recomendación para usuarios pasa por desinstalar o desactivar Twitch Enhanced Viewer | JeetBot de inmediato y, si se usa Firefox, actualizar como mínimo a 85.8.7. Después conviene cerrar todas las sesiones activas de Twitch desde la configuración de la cuenta y volver a autenticarse para forzar la rotación de sesiones. También merece la pena revisar actividad reciente, mensajes privados y acciones en chat en busca de uso no autorizado.

En organizaciones y equipos gestionados, este incidente encaja en un patrón clásico: extensiones con capacidad para interceptar o redirigir tráfico de servicios autenticados. Aquí la higiene básica es inventariar extensiones instaladas, bloquear por política los identificadores afectados, pnhhdhhcadcjfckjhpmjneldiegbojfb en Chrome y twitchenhancedviewer@example.com en Firefox, y priorizar listas de permitidos en navegadores corporativos. La comodidad no debería tener acceso ilimitado a una sesión.

Más información

• The Hacker News – Malicious Twitch Browser Extension Leaks OAuth Tokens From Nearly 31,000 Users : https://thehackernews.com/2026/09/malicious-twitch-browser-extension.html
• JeetBot Docs – Twitch Enhanced Viewer : https://docs.jeetbot.cc/en/base-stuff/extension/
• NEXSIGHT CYBER WIRE – Twitch視聴拡張機能「JeetBot」が3万人のOAuthトークンを窃取 — Socketが報告、ロシアのボット事業者の代理サーバーへ転送 : https://cyber.nexsight.co/articles/2026/09/12/socket-twitch-jeetbot-extension-oauth-token-theft-2026-09-12/

La entrada Una extensión para Twitch filtró tokens OAuth de casi 31.000 usuarios se publicó primero en Una Al Día.

Una extensión de navegador usada para mejorar la experiencia en Twitch expuso credenciales de acceso de aproximadamente 31.000 personas al enviar sus tokens OAuth a infraestructura ajena. El problema afecta a Twitch Enhanced Viewer | JeetBot, que se distribuyó tanto en Chrome Web Store como en Mozilla Add-ons, un recordatorio incómodo de que incluso los catálogos ‘oficiales’ no blindan frente a riesgos de cadena de suministro.

La pieza clave son los tokens OAuth que usa Twitch para mantener una sesión autenticada. No funcionan como una simple referencia interna: actúan como credenciales bearer, es decir, quien los posee puede operar como si fuese el usuario. En la práctica, el abuso puede ir desde leer y enviar susurros hasta escribir en el chat o tocar ajustes vinculados a la cuenta, sin necesidad de conocer la contraseña ni superar un 2FA.

El comportamiento más delicado llegó con la rama v85.x. La extensión añadió el token como parámetro de consulta &auth= durante redirecciones a nivel de red hacia servidores proxy controlados por el operador. Al viajar dentro de una URL, el token podía quedar en texto claro en registros del proxy, lo que multiplica el riesgo si esos logs se consultan de forma indebida o acaban filtrándose.

El reenvío se aplicaba a prácticamente cualquier canal que el usuario abriese, con una excepción: una lista predeterminada de 10 canales. Desde la 85.8.4, además, la extensión permitía ajustar restricciones con el parámetro Channels with restrictions, lo que introduce un control aparente, pero no evita el problema de fondo: la exfiltración del token.

No era la primera vez que la extensión jugaba con este tipo de datos. Versiones anteriores v4.x llegaron a remitir el token mediante POST a un endpoint set-token del operador e incluso definieron endpoints de respaldo alojados en deno.dev y deno.net.

La corrección ya está disponible en Firefox a partir de la versión 85.8.7, que elimina el envío del token al cambiar el método de obtención de playlists. El desarrollador ha indicado que preparaba un parche equivalente para Chrome, aunque aquí hay un matiz importante: actualizar o desactivar frena la fuga a partir de ese momento, pero no invalida los tokens que ya salieron.

La recomendación para usuarios pasa por desinstalar o desactivar Twitch Enhanced Viewer | JeetBot de inmediato y, si se usa Firefox, actualizar como mínimo a 85.8.7. Después conviene cerrar todas las sesiones activas de Twitch desde la configuración de la cuenta y volver a autenticarse para forzar la rotación de sesiones. También merece la pena revisar actividad reciente, mensajes privados y acciones en chat en busca de uso no autorizado.

En organizaciones y equipos gestionados, este incidente encaja en un patrón clásico: extensiones con capacidad para interceptar o redirigir tráfico de servicios autenticados. Aquí la higiene básica es inventariar extensiones instaladas, bloquear por política los identificadores afectados, pnhhdhhcadcjfckjhpmjneldiegbojfb en Chrome y twitchenhancedviewer@example.com en Firefox, y priorizar listas de permitidos en navegadores corporativos. La comodidad no debería tener acceso ilimitado a una sesión.

Más información

• The Hacker News – Malicious Twitch Browser Extension Leaks OAuth Tokens From Nearly 31,000 Users : https://thehackernews.com/2026/09/malicious-twitch-browser-extension.html
• JeetBot Docs – Twitch Enhanced Viewer : https://docs.jeetbot.cc/en/base-stuff/extension/
• NEXSIGHT CYBER WIRE – Twitch視聴拡張機能「JeetBot」が3万人のOAuthトークンを窃取 — Socketが報告、ロシアのボット事業者の代理サーバーへ転送 : https://cyber.nexsight.co/articles/2026/09/12/socket-twitch-jeetbot-extension-oauth-token-theft-2026-09-12/

La entrada Una extensión para Twitch filtró tokens OAuth de casi 31.000 usuarios se publicó primero en Una Al Día.

Entre el 15 de agosto y el 8 de septiembre de 2026, varias instancias autoalojadas de JFrog Artifactory han recibido ataques que terminan con control administrativo, creación de cuentas persistentes y despliegue de backdoors. La ventana temporal importa porque no hablamos de una prueba de concepto aislada, sino de intrusiones completas que, en algunos casos, han pasado del acceso inicial a un nuevo administrador en menos de cinco minutos.

La primera vía se apoya en el encadenamiento de CVE-2026-42018 y CVE-2026-42016. El fallo CVE-2026-42018 permite obtener un token interno asociado al usuario anónimo sin iniciar sesión, incluso si el acceso anónimo está desactivado. Con ese punto de apoyo, CVE-2026-42016 facilita cambiar un token de bajo privilegio por otro con alcance de administrador: la validación comprueba firma y emisor, pero no el alcance real del token, un detalle que convierte un acceso mínimo en una llave maestra.

Ese salto tiene otra consecuencia incómoda: ciertas acciones administrativas pueden quedar reflejadas en los registros como token:anonymous, no como una cuenta nominal. Para los equipos de seguridad, eso complica el análisis forense y puede retrasar la detección, sobre todo si el servidor está expuesto a Internet y gestiona repositorios con alto valor para el desarrollo.

Los atacantes han usado después el propio ecosistema de Artifactory para afianzarse. Se han instalado plugins Groovy maliciosos mediante el framework de plugins, lo que habilita ejecución de código en el servidor. A partir de ahí, se han ejecutado comandos de shell mediante un endpoint de ejecución de plugins, con tareas típicas de reconocimiento y enumeración de ficheros. También aparece un dropper que descarga un binario por HTTP, lo escribe en rutas de escritura global como /tmp y abre un canal de mando y control. En varios casos, el despliegue culmina con un backdoor en Rust orientado a control remoto.

En paralelo, se ha explotado de forma independiente CVE-2026-82329 entre el 1 y el 8 de septiembre de 2026. Este fallo, catalogado como bypass de autenticación crítico con CVSS 9.8, permite obtener privilegios administrativos sin necesidad de encadenar otros defectos y afecta especialmente a configuraciones por defecto en Artifactory autoalojado. La explotación observada incluye la creación de tokens de administrador y la enumeración de usuarios, grupos y conjuntos de credenciales, un patrón que encaja con preparativos para persistencia y movimientos posteriores.

La prioridad pasa por actualizar. Los parches de CVE-2026-82329 llegan en 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 y 7.161.20, según la rama 7.x desplegada. En el caso de la cadena CVE-2026-42018 más CVE-2026-42016, basta con corregir al menos uno de los dos fallos para romper el ataque, aunque la recomendación práctica es aplicar todas las correcciones disponibles y priorizar las instancias expuestas a Internet.

Si actualizar no resulta inmediato, existe una contención rápida para CVE-2026-82329: configurar una extra join key aleatoria en system.yaml. Aun así, conviene actuar como si el servidor ya estuviera bajo presión: revisar los audit logs en busca de acciones administrativas asociadas a token:anonymous y a la creación de nuevas cuentas con privilegios elevados, rotar credenciales y tokens potencialmente expuestos, y auditar cambios en usuarios, grupos y topologías de acceso federado.

El control técnico no debe quedarse en la aplicación. Toca inspeccionar el entorno en busca de plugins Groovy no autorizados y eliminar extensiones sospechosas, además de comprobar el sistema de ficheros y tareas programadas para localizar binarios en rutas como /tmp y señales de persistencia o conexiones de mando y control. Y hay un último frente que preocupa especialmente en equipos DevOps: verificar la integridad de repositorios y artefactos críticos y reforzar controles de publicación y promoción en la cadena CI/CD, porque un Artifactory comprometido no solo expone secretos, también puede convertirse en un punto de inyección de componentes maliciosos en software legítimo.

Más información

• Securitydone – Attackers Chain JFrog Artifactory Flaws to Gain Admin Control and Plant Backdoors : https://securitydone.com/attackers-chain-jfrog-artifactory-flaws-to-gain-admin-control-and-plant-backdoors/
• The Hacker News – Attackers Exploit Critical JFrog Artifactory Flaw to Mint Admin Tokens Days After Disclosure : https://thehackernews.com/2026/09/attackers-exploit-critical-jfrog.html?m=1
• SecurityWeek – Critical JFrog Artifactory Vulnerability Reportedly Exploited in the Wild : https://www.securityweek.com/critical-jfrog-artifactory-vulnerability-reportedly-exploited-in-the-wild/
• JFrog – JFrog Security Advisories : https://docs.jfrog.com/releases/docs/jfrog-security-advisories

La entrada Una cadena de fallos en JFrog Artifactory da a atacantes control admin y puerta trasera en minutos se publicó primero en Una Al Día.

Trezor ha comunicado una intrusión en un proveedor externo de correo que utiliza para sus comunicaciones con clientes y la ha vinculado con una campaña de phishing dirigida a usuarios de sus hardware wallets. La compañía sostiene que los atacantes se apoyaron en infraestructura que aparentaba ser legítima para aumentar la credibilidad del mensaje y acelerar el clic, un riesgo especialmente delicado cuando el objetivo final suele ser la frase semilla.

Los correos maliciosos llegaron con el asunto ‘Critical Security Alert: STM32 Entropy Vulnerability’ y se presentaban como si fuesen avisos oficiales de soporte. El texto intentaba activar el modo pánico: aseguraba, de forma falsa, que existía una vulnerabilidad de hardware en los microcontroladores STM32 que reduciría la entropía y permitiría a un atacante reconstruir la semilla o facilitar ataques de fuerza bruta. No hay CVE publicados que respalden esa alerta tal y como se describe en el email, y el patrón encaja con la táctica clásica de suplantación de marca, miedo, urgencia y un enlace que lleva a una web preparada para robar secretos.

Trezor afirma que ya ha desactivado el dominio empleado en la campaña y mantiene la investigación para aclarar cómo se produjo el acceso y por qué el envío logró el nivel de ‘apariencia oficial’ que describen los usuarios. El caso ilustra un problema recurrente: cuando un incidente nace en un tercero, como un proveedor de email marketing o servicios de correo, el atacante puede enviar mensajes que pasan filtros habituales y que el usuario interpreta como parte del flujo normal de la marca.

La campaña también se beneficia del contexto. En el sector han circulado alertas recientes sobre problemas de generación de entropía en productos de otros fabricantes, y ese ruido informativo hace más verosímil un aviso técnico aunque sea falso. Investigadores de seguridad han señalado indicios de que correos similares podrían haber llegado a usuarios de BitBox, una pista que apunta a un posible patrón de compromiso en proveedores compartidos por varias compañías del ecosistema.

La recomendación práctica no cambia, pero conviene repetirla: no hay ninguna situación legítima en la que Trezor necesite tu seed phrase por correo ni en una web. Ante un mensaje no solicitado que exija actuar ‘ya’, lo sensato es no pinchar enlaces ni descargar adjuntos, verificar el aviso en los canales oficiales del fabricante y, si alguien ya introdujo credenciales o datos sensibles, actuar como si existiera compromiso, revocar accesos donde aplique y mover fondos solo mediante procedimientos verificados y desde interfaces oficiales. En empresas y equipos de seguridad, este incidente refuerza la necesidad de playbooks que contemplen fallos en terceros y controles antiphishing más agresivos, con filtrado por dominios, análisis de URLs y reglas que detecten asuntos y textos recurrentes de campañas como esta.

Más información

• BleepingComputer – Trezor warns users of email provider breach, phishing attacks : https://www.bleepingcomputer.com/news/security/trezor-warns-users-of-email-provider-breach-phishing-attacks/
• Decrypt – Bitcoin Wallet Maker Trezor Says Hackers Breached Its Email Provider : https://decrypt.co/377831/bitcoin-wallet-trezor-hackers-breach-email
• Trezor Blog – Coldcard vulnerability: Trezor devices are not affected : https://trezor.io/blog/news/coldcard-vulnerability-trezor-devices-are-not-affected

La entrada Trezor alerta de una brecha en su proveedor de correo y una oleada de phishing contra sus clientes se publicó primero en Una Al Día.

Google ha lanzado una actualización urgente para Chrome tras detectar la explotación activa de CVE-2026-85046, un día cero de severidad alta en V8, el motor de JavaScript y WebAssembly del navegador. El fallo permite que un atacante remoto ejecute código arbitrario dentro del sandbox si la víctima visita una página HTML manipulada, un escenario típico en campañas que combinan enlaces, malvertising o páginas comprometidas.

El defecto se encuadra en una confusión de tipos en V8, una clase de vulnerabilidad que suele abrir la puerta a primitivas peligrosas, como lectura y escritura arbitrarias en memoria dentro del heap de JavaScript. En este caso, el análisis técnico apunta al compilador Maglev y a optimizaciones asociadas a Array.prototype.sort, donde ciertas decisiones de inlining y especialización pueden dejar al motor en un estado inconsistente. Ese desajuste acaba traduciéndose en un comportamiento explotable, con el que un atacante puede construir una cadena de explotación fiable.

Google ha corregido el problema en la rama estable de escritorio con las versiones 152.0.7977.82 y 152.0.7977.83 para Windows y macOS, y 152.0.7977.82 para Linux. La actualización no solo tapa este agujero: también incluye correcciones para un total de 12 vulnerabilidades, lo que refuerza el carácter de parche recomendado cuanto antes.

La compañía mantiene su política de limitar los detalles de algunos fallos hasta que una mayoría de usuarios se actualiza, con el objetivo de frenar la explotación adicional. El investigador Salvatore Gulizia, conocido como Serotav, reportó el fallo el 4 de agosto de 2026 y recibió una recompensa de 1.000 dólares. El vector CVSS publicado marca 8.8, con interacción del usuario requerida, algo coherente con un ataque que necesita que la víctima cargue contenido web preparado.

Para los usuarios, la mitigación práctica es sencilla: actualizar Chrome y, sobre todo, reiniciar el navegador para que la versión parcheada quede realmente en ejecución. En entornos corporativos conviene acelerar la gestión de parches, comprobar el inventario de versiones desplegadas y priorizar equipos con mayor exposición. También deben estar atentos los navegadores basados en Chromium, como Microsoft Edge, Brave, Opera o Vivaldi, que necesitan integrar la corrección en sus propias actualizaciones cuando sus fabricantes las publiquen.

Más información

• The Hacker News – Google Releases Chrome Update to Patch Actively Exploited V8 Zero-Day : https://thehackernews.com/2026/09/google-releases-chrome-update-to-patch.html
• Chrome Releases (Google) – Stable Channel Update for Desktop (Thursday, September 3, 2026) : https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_01882797386.html
• OpenCVE – CVE-2026-85046 – V8 Type Confusion Allows Remote Code Execution in Google Chrome : https://opencve.alliance.unm.edu/cve/CVE-2026-85046
• Serotav Writeups – When Sorting Leads To Confusion : https://serotav.github.io/Writeups/v8/when-sorting-leads-to-confusion/

La entrada Google corrige un día cero de V8 en Chrome que se explota de forma activa se publicó primero en Una Al Día.

La vulnerabilidad crítica CVE-2026-82329 en JFrog Artifactory ya se explota en ataques reales y permite a un atacante no autenticado emitir o forjar tokens de administrador con solo tener acceso de red a la instancia. El problema afecta a instalaciones self managed cuando mantienen la configuración por defecto, una combinación habitual en entornos donde el repositorio se despliega con prisas y luego queda expuesto a Internet.

El fallo abre la puerta a un bypass de autenticación con resultado directo, privilegios de administrador. A partir de ahí, el intruso puede moverse con comodidad por el sistema: enumerar usuarios, grupos y conjuntos de credenciales, revisar configuraciones sensibles e incluso obtener visibilidad sobre topologías federadas. También puede leer artefactos almacenados y tocar ajustes de seguridad, un cóctel especialmente delicado en organizaciones que usan Artifactory como pieza central del ciclo de construcción y publicación de software.

El escenario más dañino llega cuando el repositorio alimenta de forma automática a herramientas de CI/CD y despliegue. Si un atacante sustituye un paquete interno, una imagen o una dependencia que la empresa considera confiable, el cambio puede propagarse aguas abajo: desde los runners de integración hasta entornos de producción. Es el patrón clásico de incidente en cadena de suministro, con un punto único de compromiso que contamina múltiples sistemas.

JFrog Cloud ya estaba protegido, pero en local la corrección exige actualizar a una de las versiones parcheadas en cada rama: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 o 7.161.20. Aun así, aplicar el parche no basta si el atacante ya emitió tokens, porque la validez, la caducidad y la revocación de esos tokens funcionan de forma independiente a la actualización del binario.

La respuesta recomendada pasa por priorizar las instancias expuestas a Internet y recortar superficie de ataque, limitando el acceso de red al servicio. Conviene revocar y reemitir tokens de administrador, revisar la política de caducidad, y rotar credenciales y secretos ligados a pipelines y sistemas que se autentican contra el repositorio. También toca mirar con lupa los registros de auditoría: generación anómala de tokens, enumeración masiva de usuarios y grupos, cambios de configuración y accesos atípicos a APIs administrativas.

En organizaciones que hayan mantenido el servicio expuesto durante la ventana vulnerable, lo prudente es tratar el entorno como potencialmente comprometido. Eso incluye validar la integridad de los artefactos publicados en ese periodo y comprobar si hubo sustituciones. En paralelo, se recomienda endurecer controles de supply chain en el despliegue, fijando imágenes a digests inmutables y verificando firmas y procedencia en el momento de desplegar, no solo cuando el artefacto se almacena. Por último, hay que extender la investigación a sistemas conectados, como runners de CI, gestores de despliegue y servidores de producción, para descartar persistencia o cambios maliciosos.

Más información

• BleepingComputer – Hackers exploit critical JFrog Artifactory flaw to forge admin tokens : https://www.bleepingcomputer.com/news/security/hackers-exploit-critical-jfrog-artifactory-flaw-to-forge-admin-tokens/
• CSO Online – Exploited JFrog Artifactory bug puts software supply chain on alert : https://www.csoonline.com/article/4217534/exploited-jfrog-artifactory-bug-puts-software-supply-chain-on-alert.html

La entrada Atacantes aprovechan un fallo crítico en JFrog Artifactory para emitir tokens de administrador se publicó primero en Una Al Día.

Administradores de centralitas VoIP y responsables de sistemas tienen un nuevo frente urgente: una vulnerabilidad crítica en Sangoma Switchvox permite a un atacante ejecutar código de forma remota sin necesidad de credenciales y ya se ha detectado su uso en campañas activas desde el 30 de agosto de 2026. El fallo, identificado como CVE-2026-9586 y con una puntuación CVSS 9.3, afecta a despliegues expuestos a Internet y pone el foco en un producto muy común en entornos SMB.

El problema vive en el endpoint HTTP /pa, que acepta peticiones con XML. En ese flujo, el sistema incorpora el valor PhoneIP a consultas en PostgreSQL sin el saneado ni la parametrización adecuados, un patrón clásico de SQL injection catalogado como CWE-89. A partir de ahí, un atacante puede ejecutar consultas arbitrarias contra la base de datos y encadenar la intrusión hasta llegar a ejecución de comandos en el sistema, con el agravante de que la ruta técnica descrita otorga capacidad de actuar con privilegios de superusuario de PostgreSQL.

La actividad observada en ataques reales incluye la apertura de reverse shells y una fase de reconocimiento bastante directa: comandos codificados en Base64 para enumerar procesos y entender qué se ejecuta en el servidor. Entre los indicadores que se han vinculado a esta explotación aparece la dirección 176.65.148.184. También se han señalado trazas que pueden quedar reflejadas en /var/log/switchvox/db-quirks.log, un punto relevante para equipos que tengan acceso por SSH y necesiten confirmar si alguien intentó inyectar SQL o ejecutar acciones posteriores mediante técnicas habituales en estos escenarios.

La corrección no es nueva, pero el contexto sí lo es. Switchvox 8.4.0.2 incluye el parche y se publicó el 14 de julio de 2026, junto con otras correcciones adicionales en el portal web. La cronología conocida sitúa el aviso inicial al fabricante el 10 de abril de 2026, el lanzamiento del arreglo a mediados de julio y la explotación confirmada a finales de agosto. En paralelo, el alcance preocupa: se habla de miles de instancias accesibles desde Internet, con una concentración destacada en Estados Unidos.

La recomendación principal pasa por actualizar de inmediato a Switchvox 8.4.0.2 o superior y priorizar el parcheo en instalaciones expuestas a Internet, o en aquellas donde el servicio HTTP que incluye /pa resulte accesible desde redes no confiables. Hasta completar la actualización, conviene reducir superficie: restringir el acceso con listas de control, VPN o segmentación de red, y vigilar conexiones salientes anómalas, sobre todo intentos de reverse shell o tráfico hacia 176.65.148.184.

En paralelo, toca buscar señales de post explotación: procesos no habituales como nc, invocaciones de bash desde servicios web, o secuencias típicas de descarga y ejecución con curl. Si aparecen indicios de compromiso, la respuesta debe ir más allá del parche: rotación de secretos y credenciales asociados al sistema, incluidas credenciales que puedan facilitar suplantación de sesiones o acceso al portal de administración, y un análisis forense que determine hasta dónde llegó el atacante.

Más información

• The Hacker News – Attackers Exploit Critical Switchvox Flaw to Deploy Reverse Shells Without Credentials : https://thehackernews.com/2026/09/attackers-exploit-critical-switchvox.html
• Horizon3.ai – CVE-2026-9586: Sangoma Switchvox RCE : https://horizon3.ai/attack-research/disclosures/cve-2026-9586-sangoma-switchvox-rce/
• Sangoma Documentation – Switchvox Release Notes Version 8.4.0.2 (July 14, 2026) : https://sangomakb.atlassian.net/wiki/spaces/Switchvox/pages/1802371073/Switchvox%2B-%2BRelease+Notes+Version+8.4.0.2+July+14+2026
• OpenCVE – CVE-2026-9586 record : https://app.opencve.io/cve/CVE-2026-9586

La entrada Atacantes aprovechan un fallo crítico en Switchvox para abrir reverse shells sin credenciales se publicó primero en Una Al Día.