Si el sitio web de tu empresa corre sobre WordPress —y la probabilidad es alta, porque la plataforma mueve más del 43% de los sitios del mundo—, esta es la alerta que no puedes dejar para la próxima semana. Desde el 17 de julio existe una cadena de vulnerabilidades críticas en el núcleo de WordPress, bautizada wp2shell, que permite a un atacante remoto ejecutar código en tu servidor sin usuario ni contraseña. Y ya no es un escenario teórico: el 21 de julio la agencia estadounidense CISA incorporó las fallas a su catálogo de vulnerabilidades explotadas activamente.
Qué es wp2shell y por qué no se parece a las alertas de siempre
La mayoría de los avisos de seguridad en WordPress apuntan a plugins o temas de terceros. Este no. wp2shell combina dos fallas del propio núcleo: CVE-2026-63030, un conflicto de interpretación (CWE-436) en el procesamiento de peticiones al endpoint /wp-json/batch/v1 de la API REST, y CVE-2026-60137, una inyección SQL que aparece cuando plugins o temas pasan datos no confiables a consultas de base de datos. Encadenadas, permiten ejecución remota de código previa a la autenticación en instalaciones estándar.
El aviso oficial publicado en GitHub el 17 de julio clasificó el problema como crítico —Rapid7 señaló que la puntuación CVSS asignada inicialmente fue de 7.5— y el equipo de WordPress liberó parches de emergencia, activando además actualizaciones forzadas. En Europa, el INCIBE emitió su propio aviso crítico el 20 de julio. Con pruebas de concepto circulando en público, el escaneo masivo de sitios vulnerables era cuestión de horas.
Versiones afectadas y versiones seguras
- WordPress 6.9.0 a 6.9.4: afectadas por ambas fallas. Corrige la 6.9.5.
- WordPress 7.0.0 y 7.0.1: afectadas por ambas fallas. Corrige la 7.0.2.
- WordPress 6.8: afectada solo por CVE-2026-60137 (la inyección SQL). Corrige la 6.8.6.
- WordPress 7.1 beta: afectada por las dos; se publicó la 7.1 beta2.
- Versiones anteriores a 6.8: no están afectadas por estas fallas concretas, aunque eso no significa que sean seguras: arrastran otras.
Por qué esto le pega a una PyME más que a una corporación
Una empresa grande tiene un equipo que aplicó el parche el mismo viernes. En una PyME, el sitio suele ser el catálogo, el formulario que genera clientes potenciales, a veces la tienda en línea, y casi siempre lo administra alguien que además hace otras diez cosas. Ese sitio vive en hosting compartido, con años de plugins acumulados y sin monitoreo.
Cuando un atacante logra ejecutar código en ese servidor, lo que sigue rara vez es un defacement vistoso: instala una puerta trasera silenciosa, usa tu dominio para enviar spam o alojar phishing, inyecta redirecciones que Google castiga, roba la base de datos con los correos y teléfonos de tus clientes —lo que en México te coloca de lleno frente a tus obligaciones de protección de datos personales— o usa el servidor como trampolín hacia tu red interna. El costo real no es el sitio: es la reputación, el posicionamiento y la notificación a los titulares de los datos.
Plan de acción para las próximas 48 horas
- Verifica la versión exacta en el escritorio de WordPress. Si no es 6.8.6, 6.9.5 o 7.0.2 (o superior), estás expuesto.
- No asumas que la actualización forzada llegó. Muchos sitios tienen las actualizaciones automáticas deshabilitadas por el hosting o por un plugin de gestión. Revísalo a mano.
- Bloquea el acceso anónimo al endpoint
/wp-json/batch/v1desde tu WAF como medida temporal. Cloudflare desplegó reglas de mitigación, pero eso no sustituye al parche. - Comprueba si tu sitio es vulnerable con el verificador gratuito publicado por Searchlight Cyber.
- Rota credenciales: contraseñas de administrador, claves de la base de datos, tokens de API y las salts de seguridad.
- Confirma que tienes un respaldo restaurable anterior al 17 de julio, guardado fuera del mismo servidor.
Cómo saber si ya te comprometieron
- Peticiones repetidas a
/wp-json/batch/v1en los registros del servidor web. - Usuarios administradores que nadie de tu equipo creó.
- Archivos PHP nuevos en
wp-content/uploadso en la raíz del sitio. - Tareas programadas (cron) desconocidas y envíos de correo que se disparan sin explicación.
- Tu dominio marcado como peligroso en el navegador o caídas repentinas de tráfico orgánico.
Si encuentras cualquiera de esas señales, actualizar ya no basta: hay que asumir el servidor como comprometido, aislarlo, restaurar desde un respaldo limpio y volver a parchear antes de publicarlo de nuevo.
La lección de fondo: el mantenimiento no es un gasto opcional
wp2shell demuestra algo que en EDISAS repetimos desde hace 30 años acompañando a PyMEs y dependencias de gobierno: la seguridad no se compra una vez, se opera todos los meses. Tres decisiones concretas cambian tu perfil de riesgo: dejar activadas las actualizaciones automáticas del núcleo, mantener un inventario de qué plugins y versiones corren en cada sitio, y probar al menos una vez al trimestre que tu respaldo realmente se puede restaurar. Cuesta menos que una sola noche de crisis.
Si no tienes claro quién es responsable de aplicar este parche en tu empresa, esa es justo la vulnerabilidad más grave que hay que atender hoy.
Fuentes
- CVE-2026-63030: wp2shell, a Critical Remote Code Execution Vulnerability in WordPress Core (Rapid7)
- CISA Warns of Actively Exploited WordPress Flaws Enabling Pre-Auth RCE (Cyber Press)
- CISA Warns of WordPress Core SQL Injection Vulnerability Actively Exploited in the Wild (Cyber Security News)
- Cadena de vulnerabilidades críticas en WordPress, wp2shell (INCIBE-CERT)
- INCIBE alerta de dos vulnerabilidades críticas en WordPress que permiten ejecución remota de código (Moncloa)
- Vulnerabilidades críticas en WordPress: wp2shell ya está siendo explotado (Creativos Online)
