El paquete que instalás sin mirar: Rust y WordPress comprometidos en la misma semana

Cajas de embalaje idénticas sobre una cinta transportadora oscura, una de ellas abierta y con un resplandor rojo saliendo del interior, en paleta verde azulada
0 0 votos
Valora la Publicación

El 20 de agosto, a las 07:15 UTC, apareció en crates.io una versión nueva de arrayref, un crate de Rust minúsculo con 245 millones de descargas acumuladas. La publicó una cuenta de mantenedor comprometida y traía una dependencia que ejecutaba malware durante la compilación.

Esa misma semana, del otro lado del mapa tecnológico, WordPress acumuló tres fallas críticas en plugins muy instalados: Forminator, Elementor Pro y miniOrange SAML SSO. Dos permiten ejecución remota de código sin autenticación y la tercera ya se está explotando.

Son ecosistemas que no se parecen en nada (uno compila binarios, el otro sirve páginas) pero el patrón es idéntico: código de terceros que corre en tu infraestructura antes de que alguien lo mire.

Rust: el malware que corre en el cargo build

El equipo de respuesta de seguridad de Rust publicó el reporte oficial el mismo 20 de agosto. Fueron tres crates legítimos comprometidos, todos de la misma cuenta de mantenedor (droundy, David Roundy):

  • arrayref 0.3.10: publicado 07:15 UTC, borrado 08:41 UTC (86 minutos).
  • internment 0.8.7: publicado 07:34 UTC, borrado 09:04 UTC (90 minutos).
  • append-only-vec 0.1.9: publicado 07:37 UTC, borrado 09:25 UTC (107 minutos).

El equipo de Rust aclaró que no considera que el autor haya actuado maliciosamente: la hipótesis es que le comprometieron la computadora o las credenciales. La cuenta quedó bloqueada por precaución y las versiones legítimas que el atacante había marcado como retiradas («yanked») se restauraron.

El truco: un typosquat que se llama casi igual

Las tres versiones envenenadas agregaban una dependencia nueva: proc-macro1, un typosquat (nombre casi idéntico al de un paquete legítimo) de proc-macro2, uno de los crates más usados del ecosistema.

El código malicioso vivía en el build.rs de ese paquete, o sea que se ejecutaba durante la compilación. Con eso alcanza: no hacía falta que el programa llamara jamás a la función comprometida.

El script reconstruía la dirección del servidor de comando y control a partir de fragmentos en Base64, reemplazaba la verificación de certificados TLS de Rust por un verificador propio que aceptaba cualquier certificado, y descargaba un segundo binario elegido según el sistema operativo del que estaba compilando.

Ese segundo binario es un infostealer (malware que roba información): según los análisis posteriores, extraía credenciales de Chrome, Brave y Edge leyendo directamente las bases SQLite de logins, y se dejaba persistencia con claves Run del Registro en Windows, LaunchAgents en macOS y servicios de usuario de systemd en Linux.

El atacante también creó una cuenta de GitHub que se hacía pasar por David Tolnay, el autor real de proc-macro2, para que el paquete falso pasara desapercibido.

Los 245 millones de descargas y lo que realmente se bajó

Conviene separar las dos cifras que circularon. arrayref tiene 245,4 millones de descargas históricas y 53,9 millones en los 90 días previos al ataque, pero eso mide la popularidad del crate, no el alcance del incidente.

El dato que importa está en el advisory RUSTSEC-2026-0260: la versión maliciosa se descargó 2.285 veces antes de que la borraran, menos del 10% del tráfico de descargas de arrayref en ese período.

¿Por qué tan poco? Porque la mayoría de los proyectos tenía una versión anterior fijada en su Cargo.lock. El lockfile hizo de amortiguador, que es exactamente para lo que está.

El hallazgo se le atribuye al equipo de investigación de Nextron Systems, y varias firmas señalaron coincidencias de infraestructura con campañas de supply chain atribuidas a Corea del Norte.

WordPress: tres formas de entrar sin credenciales

Forminator: subir un PHP a través de un formulario público

CVE-2026-15748 (CVSS 9.8) afecta a Forminator Forms, con más de 600.000 instalaciones activas. Permite que un atacante sin autenticar suba archivos arbitrarios, incluidos PHP ejecutables.

El problema está en la validación de tipos de archivo: la lista negra de extensiones peligrosas hace una comparación exacta de claves que se elude con claves de tipo MIME con alternativas separadas por pipe. Para explotarlo hace falta un formulario que combine un campo de subida de archivos y un campo de selección, cuya configuración el manejador público toma tal cual viene del cliente.

Están afectadas todas las versiones hasta la 1.56.1 inclusive, y el parche salió en la 1.56.2 el 31 de julio. La falla se hizo pública el 17 de agosto, así que si tu sitio no actualizó en agosto, la ventana ya lleva semanas abierta.

Elementor Pro: dos bucles que no se ponen de acuerdo

CVE-2026-32475 afecta al módulo de subida de archivos de los formularios de Elementor Pro en todas las versiones hasta la 4.2.1, y se corrigió en la 4.2.2, publicada el 19 de agosto. Patchstack, que la descubrió y reportó, la calificó con CVSS 9.0; Wordfence la evaluó por su cuenta en 9.8.

El bug es de manual y vale la pena entenderlo. La validación de extensiones y el movimiento del archivo ocurren en dos bucles distintos que tratan de forma diferente una entrada de archivo vacía: el validador hace return y corta todo, el procesador hace continue y sigue.

Mandando un envío multipart con una primera parte vacía y una segunda con el payload PHP, el validador se va antes de mirar el archivo malicioso y el procesador igual lo deposita en wp-content/uploads/elementor/forms/, que es un directorio público.

Para encontrar el nombre final del archivo, el atacante puede aprovechar la baja entropía de uniqid() de PHP (que depende del tiempo) o directamente leer el mail de notificación del formulario, que por defecto incluye la URL exacta del adjunto.

No hay explotación activa reportada al momento de la publicación. BleepingComputer agrega un matiz que baja el riesgo real: el ataque necesita que el campo tenga habilitada la carga de múltiples archivos, opción que no viene activa por defecto.

miniOrange SAML SSO: entrar como administrador con una firma que no valida nada

Este es el único de los tres con explotación confirmada. Son dos fallas en el plugin de SAML 2.0 Single Sign On de miniOrange que permiten a un atacante sin autenticar forjar una respuesta SAML y aterrizar en /wp-admin como cualquier usuario existente, administradores incluidos:

  • CVE-2026-61979: confusión de algoritmo de firma. El plugin acepta el algoritmo que viene en la respuesta SAML en vez de imponer el configurado; eligiendo HMAC-SHA1, la clave pública RSA del proveedor de identidad (que es pública) pasa a funcionar como secreto compartido.
  • CVE-2026-15981: manejo de errores de OpenSSL. La función openssl_verify() devuelve -1 cuando falla internamente, el plugin lo evalúa como booleano y en PHP -1 es verdadero, así que una firma malformada pasa como válida.

Patchstack calificó ambas con CVSS 9.8 y documentó actividad de escaneo desde seis direcciones IP entre el 16 y el 18 de agosto, que interpreta como oportunista más que dirigida. El caso concreto de explotación lo detectó DigitalOcean el 16 de agosto: una sesión de administrador anómala desde fuera de su red de confianza, sobre la edición Standard del plugin.

La trampa acá es de distribución. El mismo slug tiene siete ediciones (gratuita, Premium, Standard, Enterprise, All-Inclusive, VIP y variantes multisitio) con numeraciones completamente distintas, desde la 5.4.5 gratuita hasta la 35.0.7 de VIP multisitio.

El aviso del fabricante cubrió solo la edición gratuita, y las pagas no muestran alerta de actualización en el escritorio de WordPress: hay que ir a buscar el parche a mano.

Qué revisar concretamente

Si compilás Rust, el reporte oficial pide chequear la caché local del registro por esas versiones puntuales:

  • Buscar en ~/.cargo/registry/cache rastros de arrayref 0.3.10, internment 0.8.7, append-only-vec 0.1.9 y cualquier versión de proc-macro1.
  • Revisar el Cargo.lock de los proyectos que se compilaron el 20 de agosto entre las 07:15 y las 09:25 UTC, y los runners de CI que compilan sin lockfile fijo.
  • Si aparece alguna de esas versiones, tratar las credenciales de los navegadores de esa máquina como comprometidas y buscar persistencia (clave Run, LaunchAgent, servicio systemd de usuario).

Si administrás WordPress:

  • Forminator a 1.56.2 o superior, Elementor Pro a 4.2.2 o superior, y miniOrange SAML SSO a la versión parcheada de tu edición (no alcanza con mirar el escritorio).
  • Auditar los directorios de subida por archivos PHP o ejecutables inesperados: actualizar el plugin no borra lo que ya se subió.
  • Revisar usuarios administradores nuevos o sesiones de admin desde IPs raras, sobre todo si tenés SSO por SAML.
  • Confirmar que el directorio de uploads no ejecuta PHP, que es la diferencia entre un archivo basura y un servidor tomado.

¿Cuánto código de otros corre en tu build?

Los cuatro casos comparten algo incómodo: ninguno requiere que el atacante rompa tu código. Alcanza con que confíes en un paquete que se actualiza solo o en un plugin que instalaste hace dos años y nunca volviste a mirar.

Lo que salvó a la mayoría de los proyectos de Rust fue algo bastante aburrido: tener las versiones fijadas en el lockfile. Y lo que dejó expuestos a los sitios de WordPress fue lo contrario, un parche disponible que nadie aplicó.

¿Sabés qué versiones exactas está bajando tu pipeline hoy, y hace cuánto que no auditás los plugins de tus sitios? Te leemos en los comentarios.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →
Suscribirse
Notificarme de
guest

0 Comentarios
Viejos
Nuevos Más votados
Scroll al inicio
0
Nos encantaría conocer tu opinión: ¡comenta!x