WordPress sigue siendo el sistema de gestión de contenidos más utilizado en el mundo, impulsando más del 40 por ciento de todos los sitios web en Internet. Desde sitios web de pequeñas empresas y blogs personales hasta grandes plataformas empresariales e infraestructuras de comercio electrónico, el CMS se ha convertido en la columna vertebral de la web moderna. Su popularidad se deriva de su flexibilidad, su ecosistema abierto y la gran cantidad de complementos disponibles para ampliar su funcionalidad.
Sin embargo, este mismo ecosistema también se ha convertido en uno de los mayores desafíos de seguridad de WordPress.
En Ferber Enterprises, nuestro equipo de ciberseguridad supervisa constantemente las amenazas que afectan al ecosistema de WordPress, ya que las vulnerabilidades en los plugins, los temas o las cadenas de suministro pueden derivar rápidamente en ataques a gran escala que afectan a miles de sitios web en todo el mundo. En los últimos años, los atacantes se han centrado cada vez más en los desarrolladores de plugins y en las infraestructuras de distribución, en lugar de en sitios web concretos, lo que permite que el código malicioso se propague a través de actualizaciones de software de confianza y canales de descarga oficiales.
Esta semana ha surgido una gran polémica en torno a WPFactory, un conocido desarrollador de plugins de WordPress cuyos productos están instalados en más de 170 000 sitios web de todo el mundo. Más de 80 plugins asociados a la empresa fueron retirados temporalmente de WordPress.org después de que nuestro equipo de ciberseguridad de Ferber Enterprises descubriera lo que parecía ser una puerta trasera en la versión premium de uno de sus plugins.
El incidente ha generado serias preocupaciones en la comunidad de WordPress sobre la seguridad de la cadena de suministro de software, los procesos de revisión de complementos y la creciente sofisticación de los ataques dirigidos al ecosistema de código abierto.
El descubrimiento del comportamiento sospechoso del plugin
El problema salió a la luz después de que nuestro equipo de ciberseguridad de Ferber Enterprises detectara un comportamiento anómalo al probar la versión premium del plugin «EU VAT for WooCommerce Pro», distribuido directamente desde su página web oficial.
Inicialmente, la investigación comenzó después de que el plugin generara un error fatal durante la instalación. Mientras se solucionaba el problema, nuestros analistas identificaron un archivo PHP sospechoso llamado class-alg-wc-eu-vat-customer.php. El archivo parecía ejecutar un comportamiento totalmente inconsistente con la funcionalidad esperada de un plugin de IVA de WooCommerce.
Según nuestro análisis, el código intentó:
- Descargar un archivo ZIP externo desde un servidor remoto
- Modificar directorios principales de WordPress
- Comunicarse con infraestructura externa
- Potencialmente ejecutar cargas útiles remotas en sitios web afectados
Estos indicadores sugirieron inmediatamente la posible presencia de una puerta trasera oculta o una compromiso malicioso de la cadena de suministro.
Lo que hacía que la situación fuera especialmente preocupante era que el complemento no se había obtenido de un servidor espejo no oficial ni de un repositorio pirata. El paquete se descargó directamente desde el portal oficial de clientes de WPFactory, lo que reforzaba la sospecha de que el propio canal de distribución pudiera haber sido comprometido.
En Ferber Enterprises, documentamos inmediatamente el incidente e iniciamos un proceso de divulgación responsable poniéndonos en contacto directamente con WPFactory a través de GitHub.
Respuesta inicial de WPFactory
WPFactory respondió inicialmente afirmando que el archivo sospechoso y el comportamiento descritos en el informe no formaban parte de su código fuente oficial.
Un representante de la empresa sugirió varias explicaciones alternativas, que incluyen:
- Una instalación local modificada
- Un entorno de sitio web comprometido
- Una versión de plugin obsoleta
- Una fuente de descarga potencialmente manipulada
La empresa también declaró que no pudo inspeccionar de forma segura el archivo ZIP proporcionado porque su navegador marcó el archivo como potencialmente inseguro.
Posteriormente, nuestro equipo de ciberseguridad aclaró que el complemento se había descargado directamente desde el sitio web oficial de WPFactory y que el archivo sospechoso seguía presente incluso después de descargar una copia nueva de la versión 4.6.1 desde la misma fuente.
Este detalle pasó a ser fundamental para la investigación. Si varias descargas independientes realizadas a través del canal de distribución oficial contenían sistemáticamente el mismo código sospechoso, la posibilidad de que se hubiera producido un ataque a un sitio web local se hacía cada vez más improbable. A pesar de estos hallazgos, WPFactory afirmó inicialmente que no podían reproducir el problema por su parte y alegó que el archivo sospechoso no existía en el paquete oficial del complemento.
A continuación, la empresa solicitó acceso de administrador y FTP al entorno afectado para poder continuar con la investigación. En Ferber Enterprises, rechazamos esta solicitud por motivos de ciberseguridad. Conceder acceso privilegiado al servidor a un proveedor cuya propia infraestructura pudiera haber sido comprometida habría supuesto un riesgo de seguridad inaceptable. En su lugar, nuestro equipo siguió aportando pruebas técnicas, entre ellas un vídeo de demostración en el que se mostraba el comportamiento sospechoso del complemento inmediatamente después de su instalación.
Escalada a WordPress.org
A medida que avanzaba la investigación, aumentaba la preocupación por la posible magnitud del problema. WPFactory cuenta con una amplia cartera de plugins que comprende más de 65 plugins, con más de 170 000 instalaciones activas en total. Por lo tanto, cualquier ataque que afectara a la infraestructura de distribución de la empresa podría tener consecuencias generalizadas en todo el ecosistema de WordPress.
Nuestro equipo elevó el asunto directamente a WordPress.org con el fin de evitar que otros usuarios instalaran paquetes potencialmente comprometidos mientras la investigación seguía en curso. Posteriormente, WordPress.org tomó la medida excepcional de retirar temporalmente más de 80 plugins de WPFactory del repositorio oficial.
Esta medida llamó inmediatamente la atención de toda la comunidad de seguridad de WordPress, ya que los cierres masivos de plugins a esta escala son relativamente poco frecuentes y suelen indicar problemas graves sin resolver. Tras la escalada del asunto, WPFactory reconoció posteriormente que el problema parecía legítimo y se disculpó por no haber actuado con mayor rapidez ante el informe inicial. Los representantes de la empresa afirmaron que estaban investigando activamente el asunto y trabajando para encontrar una solución. Una hipótesis planteada internamente por WPFactory sugería que un paquete de plugins obsoleto o almacenado en caché podría haberse servido involuntariamente a través de su infraestructura.
Sin embargo, nuestro equipo de ciberseguridad no estuvo de acuerdo con esta evaluación. El comportamiento observado indicaba fuertemente un problema de seguridad más profundo que potencialmente involucraba conductos de compilación comprometidos, sistemas de distribución o inyección de código no autorizado dentro de archivos de complementos descargables.
Por qué este incidente importa
La polémica en torno a WPFactory pone de relieve una amenaza creciente para la ciberseguridad conocida como «ataque a la cadena de suministro de software». Tradicionalmente, los atacantes se centraban en comprometer sitios web concretos directamente mediante ataques de fuerza bruta o vulnerabilidades en los complementos. Hoy en día, los autores de las amenazas se centran cada vez más en los propios proveedores de software, ya que comprometer a un proveedor de confianza permite que el código malicioso se propague a miles de sitios web simultáneamente.
Esta estrategia ya se ha observado en varios incidentes de ciberseguridad de alto perfil que han afectado a ecosistemas de software globales en la última década. Específicamente en el ecosistema de WordPress, los desarrolladores de plugins representan objetivos atractivos porque los plugins son intrínsecamente confiables para los administradores y a menudo operan con permisos elevados.
Si se introduce código malicioso en un paquete de plugin distribuido a través de un canal oficial, los sitios web afectados podrían instalar malware sin darse cuenta. En el caso del plugin sospechoso WPFactory, las posibles consecuencias son graves.
Basado en nuestro análisis, el comportamiento identificado podría teóricamente permitir a los atacantes:
- Implementar malware adicional
- Inyectar spam SEO
- Crear puertas traseras persistentes
- Exfiltrar datos sensibles
- Modificar instalaciones de WordPress de forma remota
- Mantener el acceso no autorizado durante períodos prolongados
El peligro de tales ataques radica en su sigilo. Las puertas traseras modernas a menudo están diseñadas para permanecer inactivas durante meses antes de activarse, lo que hace que la detección sea significativamente más difícil. A principios de este mes, el equipo de plugins de WordPress supuestamente cerró más de 30 plugins después de que código malicioso oculto incrustado en la cartera de otro plugin permaneciera inactivo durante aproximadamente ocho meses antes de activarse e inyectar spam SEO en los sitios web.
Esta tendencia demuestra cómo los atacantes priorizan cada vez más la persistencia y la activación retardada para evadir los mecanismos de detección.
Una crisis de seguridad más amplia en el ecosistema de WordPress
El incidente WPFactory pone también de manifiesto problemas de seguridad sistémicos más amplios que afectan a WordPress en su conjunto. El ecosistema de plugins se ha expandido de forma espectacular durante la última década, con decenas de miles de plugins disponibles tanto en los mercados oficiales como en los comerciales. Si bien este ecosistema fomenta la innovación y la flexibilidad, también genera una enorme complejidad a la hora de supervisar la seguridad.
Según el informe “Estado de la seguridad de WordPress en 2026” de Patchstack, casi 461 000 vulnerabilidades conocidas no se corrigieron antes de su divulgación pública. Esta estadística refleja la creciente presión a la que se ven sometidos tanto los desarrolladores de plugins como los investigadores de seguridad y los administradores de repositorios.
Al mismo tiempo, la cola oficial de revisión de plugins de WordPress, según se informa, supera ahora los 4.000 plugins a la espera de ser revisados. Estas cifras ilustran el inmenso desafío de mantener el aseguramiento de la calidad y la auditoría de seguridad a escala.
Muchos desarrolladores de plugins son equipos pequeños con recursos de seguridad limitados. Otros gestionan docenas de plugins al mismo tiempo, al tiempo que aplican estrategias de crecimiento comercial agresivas que incluyen adquisiciones y la ampliación de su cartera. La propia WPFactory se ha expandido recientemente mediante adquisiciones, entre las que se incluyen la compra de Extend-WP y sus 19 plugins en 2025, seguida de la adquisición de WBW y varios plugins adicionales más adelante ese mismo año.
La rápida expansión de carteras puede crear complejidad operativa que dificulta la auditoría de código, la gestión de infraestructuras y la verificación de la integridad de las versiones. Los atacantes son muy conscientes de estas realidades. Cada vez más, se centran en explotar prácticas de seguridad operativa débiles dentro de los proveedores de software en lugar de dirigirse directamente a los usuarios finales.
La creciente importancia de la seguridad de la cadena de suministro
Incidentes como este refuerzan la necesidad urgente de prácticas de seguridad más sólidas en la cadena de suministro en todo el ecosistema de WordPress.
En Ferber Enterprises, nuestro equipo de ciberseguridad recomienda encarecidamente a los desarrolladores de plugins que adopten varias medidas de protección clave, entre las que se incluyen:
- Firma de paquetes criptográficos
- Canales seguros de CI/CD
- Autenticación multifactor obligatoria
- Segmentación de infraestructura
- Monitoreo continuo de integridad
- Auditorías de código independientes
- Sistemas de construcción reproducibles
Los administradores de sitios web también deberían fortalecer su propia postura de seguridad. Ni siquiera los complementos descargados de fuentes oficiales o confiables deben considerarse intrínsecamente seguros.
Las organizaciones que gestionan infraestructuras críticas de WordPress deberían considerar:
- Mantenimiento de entornos de staging
- Monitoreo de tráfico saliente
- Escaneando complementos antes del despliegue
- Limitar el uso de plugins
- Aplicar controles de acceso de mínimo privilegio
- Implementación de la monitorización de la integridad de archivos
- Usando firewalls de aplicaciones web (WAF) administrados
En entornos empresariales, la validación de la cadena de suministro se está volviendo tan importante como la gestión tradicional de vulnerabilidades. La suposición de que los canales de software oficiales son siempre seguros ya no es realista en el panorama de amenazas actual.
Reacciones de la Comunidad e Investigación en Curso
La controversia se extendió rápidamente por la comunidad de WordPress después de que desarrolladores, investigadores de seguridad y proveedores de infraestructura comenzaran a discutir el problema públicamente.
Varias figuras conocidas dentro del ecosistema amplificaron la concienciación sobre la situación, incluyendo desarrolladores que publicaron listas de plugins temporalmente cerrados y animaron a los administradores a auditar sus entornos.
Mientras tanto, nuestro equipo de Ferber Enterprises sigue analizando las muestras de los plugins sospechosos y vigilando la aparición de nuevos indicadores de compromiso que puedan afectar a sitios web de WordPress en todo el mundo.
En el momento de la publicación, WPFactory ha reconocido el problema y ha declarado que está trabajando activamente para resolverlo.
Sin embargo, muchas preguntas siguen sin respuesta:
- ¿Se vio comprometida la infraestructura de distribución oficial?
- ¿Por cuánto tiempo se distribuyeron potencialmente paquetes maliciosos?
- ¿Se vieron afectados plugins adicionales?
- ¿Fueron violadas las cuentas de los clientes o los sistemas de descarga?
- ¿Los atacantes obtuvieron acceso persistente a la infraestructura interna?
- ¿Podrían existir todavía cargas útiles adicionales latentes?
Hasta que estas preguntas se resuelvan por completo, la precaución sigue siendo esencial.
El futuro de la seguridad de WordPress
Es posible que el incidente WPFactory acabe convirtiéndose en otro ejemplo emblemático de los retos de ciberseguridad a los que se enfrenta el ecosistema web de código abierto.
WordPress impulsa una enorme porción de la economía global de Internet. Cualquier compromiso a gran escala que afecte a los desarrolladores de plugins puede, por lo tanto, tener consecuencias que se extienden mucho más allá de los sitios web individuales.
Dado que los atacantes siguen evolucionando hacia ataques a la cadena de suministro y técnicas de persistencia encubierta, la seguridad de los complementos ya no puede considerarse una cuestión secundaria. En Ferber Enterprises, creemos que este suceso sirve como un recordatorio fundamental de que la ciberseguridad no consiste solo en proteger los propios sitios web, sino también en garantizar la seguridad de todas las capas de la cadena de distribución de software.
La confianza en los ecosistemas abiertos depende de la transparencia, la respuesta rápida a incidentes y unas sólidas prácticas de seguridad operativa. El ecosistema de WordPress se enfrenta ahora a un momento importante.
Cómo los desarrolladores, los mantenedores de repositorios, los proveedores de alojamiento y los equipos de seguridad respondan a incidentes como este ayudarán a determinar si WordPress puede seguir manteniendo la confianza de los millones de empresas y organizaciones que dependen de él cada día.
