INCIBE-CERT ha publicado un aviso sobre CVE-2026-71851, una vulnerabilidad crítica en versiones antiguas de la biblioteca JavaScript crypto-js. El problema está en la función CryptoJS.lib.WordArray.random(): aparentaba producir valores aleatorios aptos para usos criptográficos, pero su espacio efectivo de búsqueda era mucho menor de lo esperado. En determinadas aplicaciones, un atacante puede enumerar esos valores y llegar a reconstruir secretos sensibles.
El alcance necesita una precisión importante. No basta con que un proyecto tenga instalada una versión vulnerable de crypto-js para que pueda ser atacado. La aplicación debe haber utilizado concretamente esa función para generar material sensible, como la entropía de una frase de recuperación BIP39. La versión corregida es crypto-js 4.0.0, disponible desde hace años, pero los secretos creados antes de actualizar no se vuelven seguros por instalar el parche.
Qué falla y por qué importa
El aviso de GitHub explica que las solicitudes nominales de 128 o 256 bits de entropía terminaban ofreciendo espacios efectivos aproximados de 239 y 247 posibilidades. Son cifras enormes para una persona, pero quedan muy lejos de la resistencia esperada en criptografía y pueden recorrerse con hardware corriente. La implementación afectada combinaba un generador pseudoaleatorio Multiply-With-Carry con semillas procedentes de Math.random().
La debilidad estuvo presente en las versiones 3.x, con la excepción indicada para 3.2.0 y 3.2.1, y se sustituyó en 4.0.0 por la API criptográfica nativa de la plataforma. Aplicar después PBKDF2, otra función de derivación o un hash no recupera la entropía que faltaba al principio: esas operaciones transforman la entrada, pero no crean imprevisibilidad nueva.
La investigación reproducida en el aviso recorrió el proceso completo: enumerar posibles salidas, convertirlas en frases BIP39 válidas, derivar claves y direcciones y compararlas con información pública de cadenas de bloques. Los investigadores lograron recuperar las claves privadas que controlaban direcciones con fondos. GitHub asigna al problema una puntuación CVSS 3.1 de 9,0 y lo clasifica como crítico.
Quién debe revisar sus proyectos
El primer paso para equipos de desarrollo es comprobar dependencias directas, indirectas y transitivas que resuelvan crypto-js por debajo de 4.0.0. Después hay que buscar si CryptoJS.lib.WordArray.random() intervino en la creación de frases de recuperación, claves, tokens persistentes u otros secretos. La mera presencia del paquete no demuestra exposición; el uso de la ruta vulnerable sí exige una investigación.
Conviene delimitar qué versiones de la aplicación y qué periodos utilizaron ese código. Es el mismo principio de inventario y alcance que resulta decisivo al responder a fallos complejos, como explicamos al abordar el problema de KVM en virtualización anidada o las vulnerabilidades de FortiSandbox bajo explotación: identificar una CVE es solo el comienzo; lo determinante es saber dónde se ejecutó y qué activos pudo afectar.
Los proyectos deben actualizar como mínimo a crypto-js 4.0.0 y, cuando sea posible, usar Web Crypto en navegadores o el módulo crypto de Node.js para generar aleatoriedad. También deberían localizar los secretos de larga duración creados por la función débil, tratarlos como potencialmente comprometidos y comunicar a los usuarios una migración clara.
Actualizar la aplicación no repara una frase antigua
Para una persona que haya utilizado un monedero afectado, el detalle práctico más importante es que importar la misma frase de recuperación en un software o dispositivo actualizado no soluciona el problema. La frase conserva la entropía original. La medida eficaz consiste en crear un monedero nuevo con una frase nueva generada por una fuente fiable y trasladar los activos a direcciones derivadas de ella.
El aviso también advierte de que los secretos antiguos pueden seguir expuestos indefinidamente y de que depósitos futuros en las direcciones asociadas podrían ser robados. Si se utiliza un comprobador público de direcciones, solo se debe introducir una dirección pública. Nunca debe facilitarse una frase semilla, una clave privada, una contraseña ni un archivo de copia de seguridad. Un resultado negativo tampoco garantiza seguridad: únicamente indica que esa dirección no figura en el conjunto de datos consultado.
INCIBE-CERT publicó su alerta el 10 de agosto de 2026 con el identificador INCIBE-2026-541 y recomienda actualizar a 4.0.0. El aviso de GitHub se publicó el 7 de agosto y matiza tanto las condiciones de explotación como la persistencia del riesgo. Para usuarios y desarrolladores, la prioridad es distinguir entre una dependencia antigua sin uso sensible y un secreto que realmente nació de la función vulnerable.
