En julio de 2026 se dio a conocer WP2Shell, una de las fallas más graves que ha tenido WordPress en años. No depende de un plugin mal hecho ni de una contraseña débil: está en el propio núcleo de WordPress y permite que un desconocido, sin usuario ni contraseña, tome el control de un sitio que no esté actualizado. Lo hace desde internet y en segundos.
Casi todo lo que se ha publicado sobre WP2Shell está escrito para programadores. Esta guía es para el dueño del negocio. Explica qué pasó, cómo saber en unos 10 minutos si su página está en riesgo o ya fue atacada, y qué hacer en cada caso.
¿Qué es WP2Shell, explicado sin tecnicismos?
WP2Shell es el nombre que se le dio a la combinación de dos fallas de WordPress (CVE-2026-63030 y CVE-2026-60137). La empresa de seguridad Searchlight Cyber las reportó y WordPress las corrigió el 17 de julio de 2026.
Para entenderlo, piense en su página como un edificio con recepción. WordPress tiene una «ventanilla» interna que atiende varias solicitudes a la vez, para que el sitio funcione más rápido. La falla permitía colar, entre solicitudes normales, una que la recepción no revisaba. Por esa rendija el atacante llega a la base de datos y desde ahí puede:
- Crear un usuario administrador propio, invisible para usted si no lo busca.
- Instalar un plugin falso que le da control permanente del sitio.
- Subir una «webshell»: un archivo que funciona como control remoto del servidor.
- Leer el archivo de configuración donde están las claves de la base de datos.
Con ese acceso el atacante puede insertar publicidad o enlaces a sitios de apuestas, redirigir a sus clientes a páginas fraudulentas, enviar spam desde su dominio o usar su sitio para atacar a otros. Google puede marcar su página como peligrosa, y su correo puede acabar en listas negras.
¿Por qué es tan grave?
- No necesita contraseña. Funciona en un WordPress recién instalado, sin plugins.
- Los ataques empezaron casi de inmediato. La empresa de seguridad Wordfence detectó los primeros intentos el mismo 17 de julio. En pocas horas había en internet código listo para explotar la falla.
- Está confirmado que se está usando. El 21 de julio, la Agencia de Ciberseguridad de EE. UU. (CISA) incluyó ambas fallas en su catálogo de vulnerabilidades explotadas activamente.
- Muchos sitios no se actualizan solos. Días después del parche, en una muestra de 124,580 sitios, cerca de 1 de cada 5 seguía sin la corrección.
¿Su sitio está afectado? Revise la versión
Entre a su panel de WordPress y vaya a Escritorio → Actualizaciones. Ahí aparece la versión instalada.
| Versión instalada | Riesgo | Qué hacer |
|---|---|---|
| 7.0.0 o 7.0.1 | Alto: vulnerable al ataque completo | Actualizar a 7.0.2 o superior hoy mismo |
| 6.9.0 a 6.9.4 | Alto: vulnerable al ataque completo | Actualizar a 6.9.5 o superior hoy mismo |
| 6.8.0 a 6.8.5 | Medio: afectado por una de las dos fallas | Actualizar a 6.8.6 o superior |
| 7.0.2, 6.9.5, 6.8.6 o posterior | Corregido | Revisar que no hayan entrado antes de actualizar (ver abajo) |
Si su versión es más antigua que 6.8, esta falla en particular no le aplica. Pero un sitio con años sin actualizar tiene otras puertas abiertas, y conviene revisarlo de todos modos.
Ojo: que su sitio ya muestre la versión corregida no garantiza que esté limpio. Si el atacante entró entre el 17 de julio y el día en que se actualizó, el parche cierra la puerta pero no saca a quien ya entró.
Checklist de 10 minutos: ¿ya entraron a su WordPress?
Estas revisiones se hacen desde el panel de WordPress y desde el administrador de archivos de su hosting (cPanel, DirectAdmin o el que use). No necesita saber programar.
1. Usuarios administradores que usted no creó
Vaya a Usuarios y filtre por Administrador. Si aparece un nombre o un correo que no reconoce, sobre todo si se creó a partir de julio de 2026, es la señal más clara de intrusión. No lo borre todavía: anote el nombre y la fecha, porque sirven para la limpieza.
2. Plugins que no instaló
En Plugins, busque plugins con nombres genéricos que suenan a «sistema» o «seguridad», nombres con números al azar, o plugins sin autor ni descripción. Los atacantes de WP2Shell disfrazan sus puertas traseras como plugins. Revise también la carpeta wp-content/plugins en el administrador de archivos: a veces el plugin falso no aparece en la lista del panel.
3. Archivos PHP dentro de la carpeta de caché
En el administrador de archivos, abra wp-content/cache/. Ahí normalmente solo hay archivos de caché. Los investigadores del SANS Institute documentaron que en esta campaña se dejaron webshells en esa carpeta, con nombres aleatorios terminados en .php. Un archivo .php con nombre sin sentido en esa carpeta merece revisión inmediata.
4. Archivos modificados recientemente
Ordene por fecha de modificación las carpetas wp-content/uploads, wp-content/themes y la raíz del sitio. Si hay archivos .php cambiados en fechas en que nadie trabajó en la página, es una alerta. En uploads solo debería haber imágenes y documentos, nunca archivos .php.
5. Lo que ven sus clientes y Google
Abra su página en el celular en una ventana de incógnito y busque en Google site:sudominio.com. Las redirecciones extrañas, los anuncios que usted no puso o los resultados con títulos en otros idiomas (farmacia, casinos, préstamos) son síntomas típicos de un sitio comprometido.
Si encontró algo: qué hacer (y qué no)
Actualizar no basta. Si el atacante ya entró, su puerta trasera sigue funcionando aunque WordPress esté al día. El orden correcto es este:
- Respaldo completo antes de tocar nada (archivos y base de datos). Sirve como evidencia y como red de seguridad.
- Actualizar WordPress a la versión corregida, junto con plugins y tema.
- Eliminar lo que dejó el atacante: usuarios administradores falsos, plugins desconocidos y archivos .php sospechosos. Hay que revisar a fondo, porque los atacantes suelen dejar más de una puerta.
- Cambiar todas las claves: las de los administradores de WordPress, la de la base de datos, la del hosting y FTP, y las «claves de seguridad» de WordPress (en
wp-config.php). Recuerde que el atacante pudo leer ese archivo. - Si tiene un respaldo anterior al 17 de julio de 2026, valore restaurarlo y después actualizar. Suele ser el camino más limpio.
- Revisar Google Search Console por avisos de seguridad y, si ya está limpio, solicitar la revisión.
Lo que no conviene hacer: borrar archivos al azar, reinstalar el tema encima creyendo que eso limpia el sitio, o «dejarlo para después» porque la página se ve normal. Muchas infecciones están diseñadas para no notarse.
Si no puede actualizar hoy
Si un plugin o un tema antiguo le impide actualizar de inmediato, pida a su proveedor de hosting o a su desarrollador una protección temporal. Por ejemplo, un firewall de aplicaciones (como el de Cloudflare, que publicó reglas específicas para WP2Shell) o el bloqueo temporal de la ruta de la API que usa el ataque. Es un parche provisional que puede afectar algunas funciones del editor: la solución real sigue siendo actualizar.
La lección de WP2Shell para cualquier negocio con página web
Lo que más se repitió en este caso no fue lo técnico, sino la velocidad. Entre que se publicó el parche y empezaron los ataques pasaron horas, no semanas. Una página que «nadie toca» porque funciona bien es justo la que queda expuesta. Hay tres hábitos que hacen la diferencia:
- Actualizaciones vigiladas, no solo automáticas: alguien tiene que confirmar que sí se aplicaron y que el sitio sigue funcionando.
- Respaldos diarios guardados fuera del servidor, para poder regresar a una versión limpia.
- Una revisión periódica de usuarios, plugins y archivos, como la del checklist de arriba.
¿Necesita ayuda?
En Susistema administramos y protegemos sitios WordPress de PYMES en México desde 2004. Si después de esta revisión encontró algo raro, o simplemente no tiene tiempo de hacerla, podemos ayudarle:
- Reparación de sitios web hackeados: limpieza completa, cierre de puertas traseras y recuperación de su posicionamiento.
- Mantenimiento y seguridad web: actualizaciones vigiladas, respaldos y monitoreo mensual para que esto no le pase.
Escríbanos por WhatsApp al 55 3266 4876 y revisamos su sitio.
Fuentes: Searchlight Cyber, Wordfence, SANS Internet Storm Center, CISA, Greenbone, BleepingComputer, SecurityWeek e INCIBE-CERT. Información vigente a octubre de 2026.
