El 17 de octubre de 2026, un investigador informó al Chrome Root Program de que varias autoridades de certificación intermedias gestionadas por eMudhra habían generado sus claves con muy poca aleatoriedad. Las claves privadas se pueden deducir a partir de los certificados públicos. Quien lo haga puede crear un certificado para cualquier dominio, incluida tu API, que el software sin actualizar acepta como válido.
Los navegadores se corrigieron rápido. Chrome bloqueó los certificados esa misma noche, y Android recibió el bloqueo a través de Google Play Services dos días después. Apple también los bloqueó en sus plataformas. Pero mucho software no pregunta al navegador ni al sistema operativo si un certificado es de confianza. Lleva su propia lista, y esa lista solo cambia cuando alguien la actualiza o la vuelve a compilar.
A continuación explicamos lo que comprobamos en las apps de nuestros clientes y en nuestros propios servidores, para que puedas hacer lo mismo.
Qué puede pasar realmente
Alguien que controla la red entre tu app y tu API puede presentar un certificado falsificado para el dominio de tu API. Una app que todavía confía en los certificados comprometidos lo acepta sin ningún aviso. El atacante reenvía el tráfico al servidor real, así que la app sigue funcionando con normalidad, mientras los inicios de sesión, los tokens y los datos de clientes pasan por sus manos.
Controlar la red parece difícil, pero basta con un punto de acceso falso en una feria, una estación o un almacén. Por eso esto importa sobre todo en las apps móviles, y menos en los servidores de un centro de datos.
A quién afecta
| Software | ¿Afectado? | Qué hacer |
|---|---|---|
| Chrome, Firefox, Safari, Edge | No, bloqueado en pocos días | Nada |
| Apps nativas de iOS y macOS | No, bloqueado por Apple | Nada |
| Apps nativas de Android | No, actualización de Play Services el 19 de octubre | Nada |
| Apps Flutter en iOS, macOS y web | No | Nada |
| Apps Flutter en Android y Windows | Sí, hasta que se recompilen | Recompilar con Flutter 3.47.8 / Dart 3.13.7 o posterior y publicar |
| Flutter en Linux | Depende de la lista de certificados del sistema | Actualizar el paquete ca-certificates |
| Node.js | Versiones antiguas | 22.23.4, 24.22.1, 26.12.1 o posterior |
Python con certifi | Versiones antiguas | certifi 2026.10.19 o posterior |
| Imágenes Docker y servidores Linux | Si se compilaron o actualizaron antes del 20 de octubre aproximadamente | Recompilar con las actualizaciones de seguridad |
En los contenedores, la lista de certificados que cuenta es la que está dentro de la imagen, y queda fijada en el momento en que se compiló la imagen. Alpine, Ubuntu y Debian 12 y 13 publicaron paquetes ca-certificates actualizados entre el 20 y el 21 de octubre, así que una recompilación que instale las actualizaciones de seguridad los incorpora.
Hay un detalle que lo complica más que eliminar un único certificado raíz. Las intermedias comprometidas también tenían una firma cruzada de una raíz más antigua de Sectigo, AAA Certificate Services, que muchos paquetes de certificados todavía incluyen. Eliminar solo la raíz de eMudhra no basta: o esa raíz antigua también desaparece, como en la actualización de Debian, o las intermedias se bloquean directamente, como en la corrección de Flutter.
Cómo comprobar tu app
Hazle dos preguntas a quien desarrolla tu app:
- ¿Con qué versión de Flutter se compiló la última release de Android y Windows?
- Si es anterior a 3.47.8, ¿cuándo sale la nueva build?
Si la respuesta es un número de versión y una fecha, vas bien. Cuando la nueva build esté publicada, subir la versión mínima de la app garantiza que nadie siga usando la antigua.
También hay un efecto secundario positivo. En Android 14 y posteriores, las apps compiladas con la versión corregida de Flutter cargan sus certificados raíz de confianza desde una parte de Android que Google actualiza mediante las actualizaciones del sistema de Play. La próxima vez que pase algo así, esas apps recibirán los cambios en los certificados raíz sin necesidad de una nueva build.