Introducción
⏱️ Lectura: 14 min
El 21 de abril de 2026 Mozilla publicó la ficha oficial de CVE-2026-6770, una vulnerabilidad de privacidad que llevaba años oculta a plena vista dentro del motor Gecko. El hallazgo no salió de un adversario estatal ni de un grupo APT: lo descubrieron Dai Nguyen y Martin Bajanik, dos investigadores de la empresa de fingerprinting comercial fingerprint.com, mientras auditaban su propia superficie de detección. La ironía editorial es obvia, pero la consecuencia técnica es más incómoda: una sola llamada a indexedDB.databases() bastaba para construir un identificador estable capaz de relacionar pestañas en modo privado, orígenes completamente distintos y circuitos enteros de Tor Browser. El buque insignia de la navegación anónima filtraba un ID silencioso a cualquier página que supiera pedirlo.
📑 En este artículo
- Introducción
- Qué pasó
- Contexto e historia
- Datos y cifras
- Cómo se explota: la prueba de concepto
- Impacto en Tor Browser
- Qué hace distinto a este bug del fingerprinting clásico
- El fix técnico de Mozilla
- Qué deben hacer los usuarios
- La ironía de quién encontró el bug
- Qué sigue
- Preguntas frecuentes
- ¿Quién está afectado por CVE-2026-6770?
- ¿Puedo detectar si alguien me explotó el bug?
- ¿Sirve el modo Private Browsing para mitigar el bug?
- ¿El fix rompe aplicaciones web que usan IndexedDB?
- ¿Tor Browser tenía contramedidas específicas contra este ataque?
- ¿Se sabe si el bug fue explotado en la naturaleza antes del disclosure?
- Referencias
En este análisis revisamos los detalles técnicos de CVE-2026-6770, la cadena de avisos MFSA que Mozilla emitió en paralelo, el impacto específico para el modelo de amenaza de Tor, la prueba de concepto que compartió fingerprint.com y qué deben hacer los usuarios y operadores de servicios que dependen de Gecko.
Qué pasó
El 22 de abril de 2026 fingerprint.com publicó el análisis técnico en su blog corporativo. El reporte, firmado por Nguyen —Senior Engineer de Security Research— y Bajanik —Staff Engineer de Research—, detalla cómo un pequeño detalle de implementación dentro del subsistema de IndexedDB convierte una API estándar del DOM, pensada para listar las bases de datos locales, en un oráculo de identidad. El comportamiento estaba presente tanto en modo normal como en modo privado, pero era más grave en private browsing porque se supone que justamente ahí no debería quedar huella entre visitas.
En Firefox anterior a la versión 150, Firefox ESR anterior a 140.10.0, Thunderbird anterior a 150 y 140.10.0, y en todas las versiones de Tor Browser construidas sobre un Gecko sin parchar, la llamada a indexedDB.databases() devolvía un arreglo cuyo orden dependía del layout interno de una tabla hash global. Ese orden, determinístico y estable durante toda la vida del proceso del navegador, permitía a dos orígenes completamente no relacionados verificar si la máquina del otro lado era la misma. Mozilla asignó la serie MFSA 2026-30, MFSA 2026-32, MFSA 2026-33 y MFSA 2026-34 para cubrir las ramas afectadas, y el fix fue publicado junto con el aviso.
⚠️ Ojo: el bug no exige permisos elevados ni interacción del usuario. Basta con que la página cargue JavaScript que invoque databases() durante la sesión. En un navegador sin parche, el servidor remoto recibe un fingerprint persistente aunque el usuario esté en modo privado.
Contexto e historia
IndexedDB es la base de datos clave-valor transaccional del navegador. Existe desde 2011, vive en el estándar del W3C y es la primera opción cuando una aplicación web necesita guardar más de unos pocos megabytes del lado del cliente. La API indexedDB.databases(), un añadido posterior al estándar original, sirve para listar las bases del origen actual sin necesidad de abrirlas. En papel suena inofensivo: solo devuelve nombres que el propio origen ya conoce.
El problema empieza cuando el navegador necesita aislar esos nombres en modo Private Browsing. En Gecko, los nombres de bases en private browsing se mapean a archivos con nombre basado en UUID para no dejar rastro en disco. Esa traducción se implementa con una tabla hash global. El archivo dom/indexedDB/ActorsParent.cpp, dentro del árbol de Firefox, declara literalmente:
using StorageDatabaseNameHashtable = nsTHashMap<nsString, nsString>;
StaticAutoPtr<StorageDatabaseNameHashtable> gStorageDatabaseNameHashtable;Una vez que la tabla existe, cada vez que databases() necesita devolver un listado, el código itera sobre los buckets internos de la tabla hash. nsTHashMap y nsTHashSet, las estructuras base que usa Gecko para diccionarios, no garantizan orden: el recorrido depende del hash de cada clave, del tamaño de la tabla y del orden en que se insertaron los elementos. Nada de eso está relacionado con el origen que llama a la API. Si el mismo proceso del navegador crea las mismas claves desde dos orígenes distintos, ambos verán el mismo orden de iteración. Ese es el bug.
Mozilla reporta el issue bajo Mozilla Bug 2024220. El fix canonicaliza el resultado: antes de devolverlo a JavaScript, el código ordena las entradas por orden lexicográfico. Es una corrección de pocas líneas con consecuencias enormes.
Datos y cifras
Los números de CVE-2026-6770 permiten ubicar el problema con precisión.
- CVE asignado: CVE-2026-6770, publicado el 21 de abril de 2026.
- Publicación del análisis: 22 de abril de 2026 en el blog de fingerprint.com.
- Versiones vulnerables: Firefox < 150, Firefox ESR < 140.10.0, Thunderbird < 150 y < 140.10.0, Tor Browser con Gecko sin parche.
- Versiones corregidas: Firefox 150, Firefox ESR 140.10.0, Thunderbird 150 y 140.10.0.
- MFSA asociados: MFSA 2026-30, 2026-32, 2026-33 y 2026-34.
- API afectada:
indexedDB.databases()en el motor Gecko. - Archivo del bug:
dom/indexedDB/ActorsParent.cpp. - Estructura:
nsTHashMap<nsString, nsString>global y estática.
Cómo se explota: la prueba de concepto
La PoC conceptual que comparte fingerprint.com es elegante en su simplicidad. Dos orígenes completamente distintos, origen-a.com y origen-b.com, crean bases de datos con exactamente los mismos 16 nombres:
['a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p']Después cada uno llama a indexedDB.databases(). Si el usuario abrió ambos sitios en el mismo proceso del navegador y no tiene parche, los dos sitios reciben la misma permutación:
['g','c','p','a','l','f','n','d','j','b','o','h','e','m','i','k']Esa permutación compartida es el fingerprint. No hace falta nada más: si el servidor A envía su permutación al servidor B, B puede comparar y confirmar si la visita reciente proviene del mismo navegador que visitó a A. Con 16 nombres distintos hay del orden de veinte billones de permutaciones posibles, suficientes para actuar como identificador único dentro de cualquier grupo razonable de usuarios.
Lo que vuelve a CVE-2026-6770 especialmente molesto es que la llamada a databases() es totalmente benigna a ojos del usuario. No hay prompt de permisos, no hay acceso a hardware, no hay animaciones raras. Tampoco aparece en las contramedidas clásicas contra fingerprinting: no necesita canvas, ni WebGL, ni procesado de audio, ni lectura de fuentes instaladas. Solo una API que casi ningún usuario sabe que existe.
Impacto en Tor Browser
Tor Browser está construido sobre Gecko. Heredaba este bug tal cual. Y el modelo de amenaza de Tor no tolera lo que CVE-2026-6770 habilita: la propiedad fundamental que el navegador promete es unlinkability entre circuitos e identidades. Cuando un usuario pulsa New Identity o abre una nueva pestaña con un circuito distinto, no debería existir ningún canal lateral que conecte esa sesión con la anterior. Ese era precisamente el tipo de canal lateral que el bug abría.
Mientras el proceso del navegador siguiera vivo —en muchos flujos de Tor eso puede ser horas o días— el orden de iteración del nsTHashMap global se mantenía intacto. Dos pestañas aparentemente no relacionadas, dos identidades distintas e incluso dos cuentas pseudónimas en servicios diferentes podían ser correlacionadas con un par de llamadas a la API. Para un servicio Onion que quisiera deanonimizar visitantes, o para un adversario que controlara nodos de salida y cooperara con servicios web, el impacto práctico va mucho más allá de cookies o huellas tradicionales.
📌 Nota: el disclosure coordinado incluyó al proyecto Tor. Mozilla aterrizó el fix en Firefox ESR 140.10.0 justamente porque Tor Browser usa la rama ESR como base. Al momento del anuncio, Tor ya tenía una versión estable con el fix integrado.
Qué hace distinto a este bug del fingerprinting clásico
El fingerprinting tradicional del navegador usa señales visibles: resolución de pantalla, fuentes instaladas, pequeñas diferencias en el renderizado de canvas, particularidades del procesado de audio, configuración de WebGL. Los navegadores con foco en privacidad, incluido Tor, llevan años endureciendo esas superficies: resistFingerprinting homogeneiza canvas y tamaños de ventana, bloquea timing APIs y normaliza fuentes. Contra esa superficie conocida, las defensas funcionan razonablemente bien.
CVE-2026-6770 rompe el esquema porque no participa en ninguno de esos canales. Es un leak implícito del estado interno del proceso. El navegador no está rindiendo nada distinto por pantalla, no está exponiendo hardware, no está filtrando zonas horarias. Está entregando, silenciosamente, un pedazo de memoria reordenada que el desarrollador original nunca pensó como dato sensible. Por eso las listas de filtros de fingerprinting del usuario promedio —uBlock Origin, NoScript, Privacy Badger— no lo detectan: la llamada a databases() no aparece en ninguna lista negra porque, hasta ahora, nadie la consideraba peligrosa.
El fix técnico de Mozilla
La corrección que Mozilla introdujo en Gecko es lo más pequeña posible: canonicalizar el resultado. Antes de devolver los nombres a JavaScript, el código ahora los ordena lexicográficamente. Una vez ordenada, la salida de databases() deja de depender del orden de iteración interno del nsTHashMap y pasa a depender únicamente del conjunto de claves que el propio origen conoce. Dos orígenes que casualmente tengan los mismos 16 nombres seguirán viendo esa misma lista, pero ya no en un orden que funcione como identificador compartido.
El flujo del ataque antes y después del fix se puede resumir así:
graph LR
A["origen-a.com crea 16 DBs"] --> B["databases()"]
C["origen-b.com crea 16 DBs"] --> D["databases()"]
B --> E["permutacion estable"]
D --> E
E --> F{"mismo orden?"}
F -->|Si| G["mismo usuario"]
F -->|No| H["usuarios distintos"]
I["Firefox 150 ordena la salida"] --> J["permutacion canonica"]
J --> K["imposible correlacionar"]El commit tocó pocas líneas, pero restableció una propiedad crítica: que las APIs del DOM no filtren el orden interno de memoria entre orígenes distintos. Es un recordatorio de que las estructuras de datos no ordenadas nunca son realmente neutras cuando un adversario puede observarlas.
Qué deben hacer los usuarios
La acción concreta es actualizar. Nada más, nada menos.
- Firefox: actualizar a 150 o superior. El canal estable ya distribuye la versión.
- Firefox ESR: actualizar a 140.10.0. Útil para usuarios corporativos y distribuciones LTS.
- Thunderbird: actualizar a 150 o a 140.10.0, según la rama que uses.
- Tor Browser: actualizar a la versión que publique el proyecto Tor con Gecko parcheado. Verificá el build number oficial en torproject.org.
- Administradores de red: revisá el endpoint management y empujá la actualización a las máquinas gestionadas antes de asumir que el problema está mitigado.
💡 Tip: si trabajás con un perfil de amenaza serio y usás Tor Browser, cerrá completamente el proceso y arrancá el navegador ya actualizado. El fingerprint persiste mientras el proceso viejo siga corriendo, así que no basta con usar New Identity sin reiniciar.
La ironía de quién encontró el bug
Vale la pena cerrar con una observación editorial. Fingerprint.com es una empresa comercial cuyo producto principal es identificar navegadores únicos. Su negocio se apoya en combinar decenas de señales para distinguir dispositivos con alta confianza, principalmente para detección de fraude en bancos y comercio electrónico. Que haya sido su equipo de research el que encontró un canal de identificación silencioso dentro de Firefox y Tor dice dos cosas a la vez: una, que la superficie real de fingerprinting es mucho más amplia de lo que contempla el discurso de privacidad tradicional; y dos, que incluso los actores comerciales del sector pueden actuar como white-hats cuando el bug es serio. El disclosure fue coordinado, el fix llegó antes del post y los parches cubren a los usuarios que más dependen de la promesa de anonimato.
La lección técnica es igual de concreta: las estructuras de datos internas del navegador son superficie de ataque cuando están directamente observables desde la web. Cualquier API que retorne colecciones sin ordenar, cualquier diccionario cuyo orden dependa del layout de memoria y cualquier flag de está presente que se derive de una optimización interna merecen una pasada explícita por el pipeline de privacidad antes de ser expuestos a JavaScript de terceros.
Qué sigue
Con CVE-2026-6770 cerrado, la pregunta inmediata es si hay otras APIs de la misma familia con el mismo patrón. Cualquier método que liste recursos almacenados en estructuras hash globales —cookies, service workers, cache storage, IndexedDB, bases nativas de extensiones— es candidato a auditoría. El proyecto Tor ya anunció que está revisando sistemáticamente todas las APIs del DOM que retornan colecciones para verificar que su orden no filtre estado. Es la consecuencia natural de este tipo de hallazgo: un solo caso abre la puerta a una ola de revisiones análogas en superficies vecinas.
El otro vector es la telemetría del propio Mozilla. La compañía suele tardar más en identificar este tipo de bugs porque no son crashes, no son leaks de memoria sensible, no aparecen en reportes automáticos. Son canales laterales. La comunidad presionará por herramientas de análisis estático que señalen APIs públicas cuyo resultado dependa del orden de iteración de un hash interno, antes de que pasen por code review.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Quién está afectado por CVE-2026-6770?
Cualquier usuario con Firefox anterior a 150, Firefox ESR anterior a 140.10.0, Thunderbird anterior a 150 o 140.10.0 y Tor Browser construido sobre Gecko sin el parche. Si no estás seguro de tu versión, abrí el menú y verificá Acerca de Firefox o About Tor Browser.
¿Puedo detectar si alguien me explotó el bug?
No con facilidad. La llamada a indexedDB.databases() no queda registrada en logs del navegador visibles al usuario y no genera ningún prompt. La única defensa práctica era bloquear JavaScript en sitios no confiables o usar un navegador ya parcheado.
¿Sirve el modo Private Browsing para mitigar el bug?
No. El bug era más explotable precisamente en modo privado, porque ahí Gecko usa la tabla hash global para traducir nombres de bases a UUIDs. En modo normal el comportamiento también podía observarse, pero el diseño de modo privado hacía el canal más estable.
¿El fix rompe aplicaciones web que usan IndexedDB?
No debería. indexedDB.databases() nunca garantizó orden en el estándar, así que cualquier aplicación que dependiera del orden previo estaba apoyándose en comportamiento no especificado. El fix ordena lexicográficamente, que es el orden más natural para cualquier consumidor razonable.
¿Tor Browser tenía contramedidas específicas contra este ataque?
No específicas para este bug. Tor aplica múltiples mitigaciones contra fingerprinting de canvas, fuentes, timing y WebGL, pero este canal no participaba en ninguna de esas superficies. El fix llegó vía la actualización de Gecko base.
¿Se sabe si el bug fue explotado en la naturaleza antes del disclosure?
No hay evidencia pública de explotación activa. Fingerprint.com reportó a Mozilla y al proyecto Tor en privado y Mozilla publicó el parche antes del anuncio. Aun así, dado lo silencioso del ataque, un adversario que ya lo conociera podría haberlo usado sin dejar huella evidente.
Referencias
- Fingerprint.com — Firefox/Tor IndexedDB privacy vulnerability — análisis técnico original del hallazgo.
- NVD — CVE-2026-6770 — ficha oficial del CVE con métricas, referencias y CPE.
- Mozilla Foundation Security Advisory 2026-30 — aviso oficial de seguridad para Firefox 150.
- Mozilla Bug 2024220 — tracker público del issue y parche asociado.
- Lobsters — cobertura de la comunidad — discusión técnica del hallazgo.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios