Chrome en alerta: el fallo en Service Workers que convierte tu navegador en un bot silencioso

Un fallo en Chromium descubierto por la investigadora Lyra Rebane y documentado en el rastreador de errores de Chromium ha vuelto a poner en evidencia una doble falla: una vulnerabilidad en la ejecución de Service Workers que puede mantener JavaScript activo aún con el navegador cerrado, y una gestión interna de parches que filtró información sensible antes de desplegar una corrección efectiva. Según la investigadora, un atacante puede crear una página web que registre un Service Worker que nunca termine y, de ese modo, convertir navegadores en miembros silenciosos de una red remota de bots capaces de hacer proxy de tráfico o participar en ataques de denegación de servicio.

La exposición pública de los detalles técnicos aceleró el riesgo. Parte del problema no fue solo la existencia del bug, sino que el seguimiento administrativo en Chromium marcó la incidencia como "fixed" en el sistema antes de que la corrección llegara realmente a los usuarios, y luego se abrió de nuevo. Durante el tiempo en que los detalles quedaron accesibles, investigadores y observadores pudieron validar que el exploit seguía efectivo en versiones Dev de navegadores Chromium, lo que facilitó su reproducción.

Es importante subrayar que, según Rebane y análisis posteriores, la vulnerabilidad no parece romper las fronteras perimetrales del navegador: no da acceso directo a archivos locales, correos ni al sistema operativo. Sin embargo, permite ejecución persistente de JavaScript con conectividad de red mantenida, lo que es suficiente para montar proxies, amplificar tráfico o mantener comunicación con un centro de mando, causando impacto significativo a escala si se explota masivamente.

Para entender la técnica es útil repasar cómo funcionan los Service Workers: son scripts que actúan entre la red y la página web para gestionar caché, notificaciones y procesos en segundo plano. La documentación técnica en MDN ofrece un buen punto de partida para quien quiera profundizar en su diseño y riesgos: https://developer.mozilla.org/en-US/docs/Web/API/Service_WorkER_API. Para el contexto periodístico y técnico sobre la filtración y la situación actual, Ars Technica recopiló declaraciones y pruebas reproducibles: https://arstechnica.com/security/2026/05/google-publishes-exploit-code-threatening-millions-of-chromium-users/.

¿Qué pueden hacer los usuarios hoy para reducir el riesgo mientras llega un parche oficial? En primer lugar, desactivar la opción que permite ejecutar aplicaciones en segundo plano cuando el navegador está cerrado (Chrome: Ajustes → Sistema → "Continuar ejecutando aplicaciones en segundo plano cuando Google Chrome esté cerrado"; Edge tiene una opción equivalente en Configuración → Sistema). En segundo lugar, limpiar y revocar Service Workers de sitios que no se confíe: esto se puede gestionar desde las herramientas de desarrollador (DevTools → Application → Service Workers) o desde la gestión de datos de sitio en la configuración del navegador, y también mediante chrome://inspect/#service-workers en navegadores Chromium para inspeccionar workers activos.

Complementar la higiene del navegador con bloqueadores de contenido robustos, como uBlock Origin, y evitar la ejecución de scripts procedentes de sitios no verificados reduce la probabilidad de infección inicial. Para navegación de alto riesgo se recomienda usar perfiles separados o el modo invitado, y considerar navegadores que no compartan el mismo motor Chromium para sesiones experimentales. En entornos corporativos, es urgente aplicar políticas de grupo que deshabiliten la ejecución en segundo plano y bloquear dominios sospechosos a nivel de firewall hasta que lleguen actualizaciones firmes.

Desde la perspectiva de respuesta y detección, los equipos de seguridad deben monitorear patrones anómalos de tráfico saliente desde estaciones de trabajo que coincidan con comportamientos de bots (conexiones persistentes a dominios inusuales, picos regulares de solicitudes HTTP desde navegadores). Las soluciones EDR y los sistemas de detección de red pueden generar señales útiles para identificar clientes comprometidos; en organizaciones medianas y grandes conviene preparar reglas para bloquear o aislar equipos afectados mientras se verifica la causa.

La filtración también deja una lección organizativa: la coordinación entre la identificación de vulnerabilidades, el etiquetado en procesos internos y la publicación controlada de información es tan crítica como el parche técnico. Marcar una incidencia como solucionada sin desplegar el arreglo o abrir la información antes de tiempo crea ventanas de explotación evitables. Los programas de recompensas (VRP) deben incorporarse a procesos que aseguren que los cambios en los trackers no revelen detalles antes de la liberación del código corregido.

Finalmente, mantenga su navegador y sistema operativo actualizados y esté atento a los avisos oficiales de Google y otros mantenedores de navegadores Chromium para aplicar actualizaciones de emergencia. Mientras tanto, actúe con precaución al visitar sitios desconocidos y revise periódicamente los Service Workers registrados en su navegador: esa comprobación puede marcar la diferencia entre un equipo sano y uno que actúe silenciosamente como parte de una red maliciosa.