Resumen
Uncanny Automator confirma un incidente de supply chain: una build Pro 7.3.0.5 manipulada se distribuyo durante una ventana limitada y los sitios afectados deben tratarse como comprometidos.
Uncanny Automator ha publicado un aviso de seguridad tras confirmar un incidente que afecto a automatorplugin.com y a su infraestructura de actualizaciones. Segun el proveedor, un atacante accedio a parte de sus sistemas el 12 de junio de 2026, fue expulsado el 13 de junio y, durante una ventana limitada, se sirvio una build manipulada de Uncanny Automator Pro 7.3.0.5.
No es una vulnerabilidad clasica con CVE: es un incidente de supply chain. La parte critica es que una actualizacion distribuida desde el canal del proveedor podia instalar malware y una puerta trasera en sitios WordPress que recibieron esa version. El propio aviso indica que los sitios con la build comprometida deben tratarse como comprometidos.
A quien afecta
- Sitios con Uncanny Automator Pro 7.3.0.5 descargado durante la ventana aproximada del 12 de junio a las 18:30 EDT al 13 de junio a las 16:00 EDT.
- Clientes de Uncanny Automator, porque el proveedor tambien confirma acceso a datos de cuenta como nombre, email, claves de licencia y URLs asociadas.
- No afecta a Uncanny Automator Lite, segun el aviso del proveedor. La version gratuita en WordPress.org aparece con mas de 40.000 instalaciones activas, pero el incidente descrito afecta a la distribucion Pro.
Por que importa
Para agencias y owners con muchos WordPress, este tipo de incidente es especialmente delicado: el riesgo no entra por una instalacion “pirata” ni por una vulnerabilidad publica explotada desde fuera, sino por un canal de actualizacion que normalmente se considera confiable. Si una cartera de sitios usa el plugin Pro, la prioridad no es solo actualizar: es identificar si algun sitio instalo la build 7.3.0.5 y revisar compromiso.
Tambien hay un riesgo operativo adicional: phishing dirigido. Al haberse expuesto emails, licencias y URLs de sitios, pueden aparecer mensajes falsos que imiten al proveedor y pidan instalar una “actualizacion urgente”.
Que hacer ahora
- Comprobar si algun sitio tiene o tuvo Uncanny Automator Pro 7.3.0.5.
- Actualizar solo por canales oficiales y confirmar la version limpia 7.3.0.6 o superior.
- Si un sitio recibio la build manipulada, tratarlo como comprometido: no basta con reinstalar el plugin sin revisar persistencia, usuarios, tareas programadas, archivos y cambios no autorizados.
- Revisar usuarios administradores, plugins desconocidos, tareas cron, archivos recientes y conexiones sospechosas.
- Alertar al equipo para desconfiar de emails inesperados sobre Uncanny Automator, especialmente si contienen enlaces o adjuntos.
Como priorizarlo en entornos multi-sitio
La prioridad debe ir primero a sitios con Uncanny Automator Pro activo, despues a sitios con actualizaciones automaticas o gestionadas por terceros, y por ultimo a instalaciones donde haya integraciones sensibles: ecommerce, membresias, LMS, CRM, formularios, webhooks o automatizaciones con acceso a datos de clientes.
En una agencia, conviene registrar sitio, version observada, canal de actualizacion, fecha de ultima actualizacion, usuarios admin revisados, hallazgos y acciones tomadas. Esa trazabilidad ayuda a separar sitios limpios de sitios que necesitan respuesta de incidente.
Fuentes
- Security Incident Notice: Uncanny Automator
- Uncanny Automator en WordPress.org
- SecurityOnline: Uncanny Automator Breach
Lectura desde Vulnity
Vulnity no detecta automaticamente esta build ni corrige incidentes de supply chain por si solo. Su encaje honesto esta en reducir la exposicion operativa: centralizar visibilidad multi-sitio, acelerar la respuesta, revisar hardening, detectar actividad sospechosa, bloquear IPs maliciosas cuando aplique y mantener evidencia clara de que se ha comprobado cada sitio.
Sobre Vulnity
Si gestionas varios WordPress, alertas como esta se convierten en trabajo operativo urgente. Vulnity ayuda a centralizar visibilidad, revisar hardening y responder antes en todos tus sitios.
