WordPress hackeado: por qué le pasa a las PYMEs
Tres fallas críticas en plugins de WordPress muy usados y una operación con unos 2.000 sitios ajenos. Por qué los sitios chicos son blanco y qué revisar hoy.
Agosto dejó un patrón difícil de ignorar. En pocas semanas se publicaron tres vulnerabilidades críticas en plugins de WordPress, las tres con puntaje 9,8 sobre 10, y las tres con la misma consecuencia: alguien que no tiene cuenta en tu sitio puede quedarse con el control completo.
Los tres plugins hacen cosas distintas. Lo que comparten es más simple y más incómodo: son código de terceros corriendo en tu servidor, y en miles de sitios nadie los está actualizando.
Vamos por partes: qué pasó, por qué le pasa a sitios chicos y qué revisar hoy.
Las tres fallas de este mes
Las tres permiten a un atacante sin autenticación tomar control del sitio. Las tres ya tienen parche disponible. La pregunta no es si son graves, es si tú actualizaste.
| Plugin | CVE | Instalaciones activas | Versión que corrige |
|---|---|---|---|
| Forminator Forms | CVE-2026-15748 | Más de 600.000 | 1.56.2 |
| Pods | CVE-2026-19598 | Más de 100.000 | 3.3.9.1 |
| User Profile Builder | CVE-2026-15826 | Más de 40.000 | 3.16.5 |
Forminator Forms. Subida arbitraria de archivos sin autenticación que hace posible la ejecución remota de código. Afecta a todas las versiones hasta la 1.56.1 inclusive, por validación insuficiente de tipos de archivo en la función handle_file_upload, donde la lista de extensiones peligrosas se puede eludir (NVD). Un detalle importante: la explotación solo funciona en formularios que tienen a la vez un campo de subida de archivo y un campo de selección. El parche 1.56.2 salió el 31 de julio de 2026 y, al 18 de agosto, cerca de la mitad de las instalaciones seguía en una versión vulnerable, unos 300.000 sitios (SecurityWeek).
Pods. Escalada de privilegios por salto de autorización en todas las versiones hasta la 3.3.9 inclusive. El enrutador AJAX del plugin canalizaba todas sus verificaciones de acceso por una función que registraba el error pero no terminaba la solicitud, dejando los controles sin efecto. Resultado: un atacante sin cuenta podía escalar a administrador o sobrescribir la contraseña de cualquier usuario, incluido el dueño del sitio (Patchstack). El 14 de agosto de 2026 el equipo de Pods publicó los parches (3.3.9.1, más las versiones retrocompatibles 3.2.8.3, 3.1.4.2, 3.0.10.4, 2.9.19.4 y 2.8.23.4) con una recomendación sin matices: si corres cualquier versión de Pods, actualiza cuanto antes (Pods Framework).
User Profile Builder. Un error de confusión de tipos permite a un atacante sin autenticación entrar directamente como el usuario de ID 1, que en la mayoría de las instalaciones es el administrador original. La causa: la función de inicio de sesión convertía un objeto de error a número antes de validarlo, y ese número terminaba siendo 1 cuando el nombre de usuario superaba los 70 caracteres. Afecta a las versiones hasta la 3.16.4 inclusive (NVD). El parche 3.16.5 salió el 16 de julio de 2026 y la falla expone a más de 40.000 sitios (Infosecurity Magazine).
Qué hacer con esta tabla: entra a tu panel, abre Plugins y compara versiones. Si tienes alguno de los tres por debajo de la versión indicada, actualiza antes de seguir leyendo. Si no puedes actualizar en este momento, desactívalo.
La pregunta real: ¿por qué mi sitio?
Es la objeción que escuchamos siempre. “¿Qué le van a robar a mi sitio? Si no vendo nada, no guardo tarjetas, tengo cuatro páginas.”
La respuesta incomoda: no les interesa lo que vendes, les interesa tu servidor.
En agosto, Check Point Research publicó el análisis de una operación llamada StopAndProtect, detectada a mediados de mayo de 2026. En el servidor del atacante encontraron archivos que apuntaban a cerca de 2.000 dominios WordPress comprometidos, usados para distribuir el malware, controlar las máquinas infectadas y almacenar los documentos robados. Al 24 de julio de 2026 la operación registraba más de 6.000 direcciones IP de víctimas y había acumulado alrededor de 31.000 capturas de pantalla (Check Point Research, 18 de agosto de 2026).
El detalle clave para una PYME está en el rol de esos sitios: eran infraestructura, no objetivo. Sitios legítimos, de negocios reales, que servían de bodega y de central de operaciones para atacar a otros. Sus dueños probablemente no notaron nada.
Uno de los sitios comprometidos corría una versión de WordPress de 2021, casi cinco años desactualizada, con cerca de 40 vulnerabilidades identificables entre certificados expirados, inyección SQL, redirecciones abiertas y saltos de autenticación. El propio informe lo resume sin adornos: hay muchos sitios WordPress vulnerables simplemente porque sus dueños no los mantienen actualizados.
Nuestra lectura: la pregunta “¿por qué me atacarían a mí?” parte de un supuesto equivocado, que hay alguien decidiendo a quién atacar. No lo hay. Hay un escáner recorriendo internet buscando versiones con fallas conocidas, y tu sitio califica o no califica. Ser chico no te protege; te hace más probable, porque los sitios chicos son los que nadie actualiza.
Por qué WordPress concentra el problema
No porque sea malo, sino por aritmética. WordPress lo usa el 40,7% de todos los sitios web y tiene el 58,9% del mercado de gestores de contenido (W3Techs, al 25 de agosto de 2026).
Cuando una plataforma mueve esa proporción de internet, pasan dos cosas a la vez: es donde más vale la pena buscar fallas, y es donde una sola falla afecta a cientos de miles de sitios de golpe. Una vulnerabilidad en un plugin con 600.000 instalaciones no es un incidente, es una campaña.
A eso se suma la estructura de WordPress: el núcleo lo mantiene un proyecto grande y serio, pero los plugins los mantienen terceros de tamaño y rigor muy variable. Tu superficie de ataque no es WordPress, es WordPress más los quince plugins que instalaste y los tres que ya nadie actualiza.
Vale la pena notar algo de las tres fallas de este mes. Dos están en plugins que por diseño reciben datos de desconocidos: un constructor de formularios y un sistema de registro de usuarios. La tercera, Pods, no recibe nada del público: falló porque su control de permisos anotaba el rechazo en el log y dejaba pasar la solicitud igual. Es decir, ni siquiera basta con “no tengo formularios abiertos”. Basta con tener código de terceros sin actualizar.
Qué revisar hoy, en orden
Seis cosas, de la más rentable a la menos.
1. Cuenta los plugins y elimina los que no usas. Cada plugin instalado es código que vive en tu servidor, esté activo o no. El que probaste una vez en 2023 y dejaste ahí sigue siendo superficie de ataque. Bórralo, no lo desactives.
2. Revisa la fecha de la última actualización. En Escritorio y en Plugins verás las pendientes. Si hay más de diez esperando, tu problema no es una vulnerabilidad puntual: es que nadie está a cargo del sitio.
3. Mira con especial atención lo que recibe datos del público. Formularios, registro de usuarios, comentarios, subida de archivos. Si tu formulario acepta adjuntos y no los necesitas de verdad, quita esa opción: cierras la clase completa de fallas que encabezó este mes.
4. Cambia el usuario administrador si es el ID 1. La falla de User Profile Builder desembocaba justamente ahí. Crea un administrador nuevo, verifica que puedes entrar con él y elimina el original.
5. Confirma quién tiene respaldos y de cuándo. Un respaldo sirve si existe, si es reciente y si alguien lo probó restaurando. Los tres requisitos, no dos. Muchos hostings incluyen respaldos automáticos que nadie ha intentado restaurar nunca; conviene revisar qué dice tu plan, tema que desglosamos en cómo elegir hosting web en Chile sin que te estafen.
6. Deja por escrito quién actualiza. Este es el punto que más veces vemos fallar. El hosting responde por el servidor; el desarrollador entregó el sitio y siguió su camino; el dueño supone que “eso viene incluido”. Nadie actualiza. Si no hay un responsable con nombre, no hay mantención, y el costo real de eso lo desarmamos en cuánto cuesta mantener un sitio web en Chile al año.
Una referencia gratuita que sirve de checklist
La Agencia Nacional de Ciberseguridad publicó “Los 9 básicos de la ciberseguridad”, una lista corta de medidas mínimas: actualizar periódicamente, capacitar periódicamente, minimizar privilegios, respaldar la información, asegurar redes, asegurar equipos, monitorear, usar autenticación de múltiples factores y usar gestor de contraseñas (ANCI).
Conviene ser preciso con el alcance. La ANCI abrió una consulta pública para volver obligatorias seis de esas nueve medidas, pero solo para los sujetos obligados por la Ley 21.663, Marco de Ciberseguridad, no para cualquier empresa. La agencia publicó el resumen ejecutivo de esa consulta el 20 de agosto de 2026 (ANCI).
Es decir: si tienes una PYME común, esto no te obliga a nada. Pero es una lista pública, corta y gratuita, escrita por la autoridad chilena en la materia. Como pauta de autoevaluación es mejor que buena parte de lo que se vende como auditoría.
Si ya está pasando
Señales típicas de un sitio comprometido: aparecen páginas o usuarios administradores que no creaste, el sitio redirige a otro dominio para visitantes que llegan desde Google, el hosting avisa por consumo anormal de recursos, o Google marca el sitio con una advertencia.
El orden importa:
- Respalda el estado actual antes de tocar nada. Aunque esté infectado. Es tu evidencia y tu punto de retorno.
- Cambia todas las contraseñas, incluidas las de la base de datos, el FTP y el panel del hosting. Cerrar la puerta sin cambiar la llave no sirve.
- Avisa a tu hosting. Muchos tienen procedimientos de limpieza y ven desde el servidor lo que tú no ves desde el panel.
- No restaures un respaldo cualquiera. Si la entrada fue hace tres semanas, el respaldo de la semana pasada también está comprometido.
- Revisa tu correo. Un sitio comprometido se usa para enviar spam, y eso quema la reputación de tu dominio. Después de limpiar, verifica la autenticación siguiendo por qué los correos de tu sitio web llegan a spam.
Cuándo el problema es la plataforma y no el descuido
Hay una conversación que vale tener con honestidad: no todos los sitios necesitan WordPress.
Si tu sitio es informativo (servicios, nosotros, contacto, algunos artículos) y lo edita una o dos personas, un sitio sin base de datos y sin plugins elimina de raíz esta categoría de riesgo. No hay panel que forzar, no hay plugin desactualizado, no hay archivo PHP que subir. La mantención pasa de ser una obligación mensual a una revisión ocasional.
Si en cambio necesitas que un equipo publique a diario, administre cientos de productos o gestione usuarios registrados, WordPress sigue siendo una respuesta sensata. Ahí el costo de mantenerlo es el precio de lo que te resuelve, y hay que asumirlo, no negarlo.
La decisión se toma mirando quién va a editar el sitio y con qué frecuencia, no mirando cuál plataforma está de moda. Si el diagnóstico apunta a migrar, el punto delicado es no perder posiciones en el camino: lo detallamos en migrar tu sitio WordPress a Vue o Nuxt sin perder SEO.
En resumen
- Tres plugins de WordPress tuvieron fallas críticas con puntaje 9,8 estas semanas: Forminator Forms (parche 1.56.2), Pods (3.3.9.1 y retrocompatibles) y User Profile Builder (3.16.5). Revisa tus versiones hoy.
- Tu sitio no interesa por lo que vende. Check Point documentó cerca de 2.000 sitios WordPress ajenos usados como infraestructura de una operación de malware.
- WordPress concentra el 40,7% de todos los sitios web, y eso convierte una sola falla de plugin en una campaña masiva.
- No basta con “no tengo formularios abiertos”: una de las tres fallas estaba en un plugin que no recibe nada del público.
- La defensa real es aburrida: menos plugins, actualizaciones al día, respaldos probados y un responsable con nombre.
Si no tienes claro en qué estado está tu WordPress hoy, o quieres una segunda opinión sobre si vale la pena mantenerlo, conversemos y lo revisamos.
Preguntas frecuentes
- ¿Por qué alguien querría hackear el sitio de mi PYME si no vendo nada valioso?
- Porque no buscan tus datos, buscan tu servidor. Un sitio ajeno sirve para alojar archivos maliciosos, operar como servidor de control de máquinas infectadas o guardar información robada de otras víctimas. Check Point documentó una operación que usaba cerca de 2.000 sitios WordPress comprometidos exactamente para eso. Los dueños de esos sitios no eran el objetivo, eran la infraestructura.
- ¿Cómo sé si mi WordPress está en riesgo ahora mismo?
- Entra al panel, abre Plugins y revisa dos cosas: cuántos tienen actualización pendiente y hace cuánto que no se toca ninguno. Después verifica si usas alguno de los tres plugins con fallas críticas publicadas estas semanas: Forminator Forms (parche 1.56.2), Pods (parche 3.3.9.1 y versiones retrocompatibles) y User Profile Builder (parche 3.16.5). Si tu versión es anterior, actualiza hoy.
- ¿Un plugin de seguridad me protege?
- Ayuda a detectar y a poner obstáculos, pero no reemplaza actualizar. Las tres fallas de este mes están en el código de los propios plugins y se cierran instalando la nueva versión. Un firewall puede bloquear intentos conocidos mientras actualizas, no en vez de actualizar.
- ¿Conviene salirse de WordPress?
- Depende de para qué lo usas. Si tu sitio es informativo, con formulario de contacto y poco más, un sitio sin base de datos ni plugins elimina de raíz esta categoría de riesgo. Si necesitas que un equipo publique contenido a diario, administre productos o gestione usuarios registrados, WordPress sigue siendo una respuesta razonable siempre que alguien lo mantenga.
- ¿Mi hosting no debería encargarse de esto?
- El hosting responde por su infraestructura: el servidor, la versión de PHP, los respaldos. Las actualizaciones del núcleo de WordPress, de los plugins y de los temas son del sitio, no del servidor. Algunos planes administrados las incluyen; la mayoría de los planes económicos, no. Conviene tenerlo por escrito antes de asumirlo.
