El Poderoso Ataque wp2shell: cómo salvar tu página web en WordPress

Esta es una Guía de verificación, detección y remediación para WordPress brindada por nuestros expertos en Mapachio, tu hosting humano. Escrita para quien administra el sitio: desarrolladores, áreas de sistemas y proveedores de hosting.

Última actualización: 31 de julio de 2026.

¿Qué es que falló en WordPress con el ataque wp2shell?

El 17 de julio de 2026 WordPress publicó parches de emergencia para dos fallas de su núcleo,la falla de seguridad CVE-2026-63030 y el CVE-2026-60137 que en su conjunto se nombra ataque wp2shell. Por separado, ninguna de las dos entrega el servidor pero encadenadas, convierten una petición anónima de internet en ejecución de código.

Conviene entenderlas por separado, porque no todos los sitios estaban expuestos a las dos.

CVE-2026-63030 — confusión de rutas en la API

Desde la versión 6.9, WordPress permite agrupar varias operaciones de su API REST en una sola petición, a través del endpoint /wp-json/batch/v1.

El procesador de ese endpoint valida y ejecuta en dos recorridos distintos. Cuando la validación de la ruta de una subpetición falla, el error se agrega al arreglo de validación pero no al de coincidencias. Los dos arreglos quedan desfasados y, a partir de ese punto, cada subpetición siguiente se despacha con el manejador que no le corresponde.

Traducido: se autoriza una cosa y se ejecuta otra. Por sí sola no roba nada; simplemente entrega peticiones a destinos que no correspondían.

CVE-2026-60137 — inyección SQL en WP_Query

El parámetro author__not_in de WP_Query espera una lista de identificadores de usuario. Cuando se recibe un valor escalar en lugar de un arreglo, la validación no se aplica y el contenido llega tal cual a la consulta contra la base de datos.

Por sí sola ya es grave: permite leer información que no debería salir, incluidos los hashes de contraseñas. Pero es un problema de exposición de datos, no de control del servidor. Existe desde WordPress 6.8.

La corrección, en ambos casos, es pequeña: validar bien el tipo del parámetro con wp_parse_id_list(). Suele ser el caso en este tipo de cadenas.

Por qué juntas son otra cosa

Cada falla tenía su límite. La inyección SQL era peligrosa pero difícil de alcanzar sin estar autenticado. La confusión de rutas entregaba peticiones a destinos indebidos, pero sin nada dañino que entregar.

La combinación resuelve el límite de cada una: la confusión de rutas es el vehículo que lleva la petición anónima hasta el parámetro vulnerable, y la inyección SQL es lo que hace peligrosa esa petición una vez que llega. Controlando lo que devuelve la consulta, el atacante consigue que WordPress trate como legítimo un contenido fabricado por él, y lo usa para crear una cuenta de administrador. Con administrador, ejecutar código es un trámite.

¿Ok y quienes necesitan resolver este ataque de WordPress?

La cadena de ataque completo solo funciona donde existe el endpoint de agrupación de peticiones, es decir desde la versión 6.9 de WordPress. Las ramas anteriores cargan únicamente la inyección SQL.

Rama	Versiones afectadas	Corregida en	Qué le aplica
7.0.x	7.0.0 – 7.0.1	7.0.2	Cadena completa: ejecución de código
6.9.x	6.9.0 – 6.9.4	6.9.5	Cadena completa: ejecución de código
6.8.x	6.8.0 – 6.8.5	6.8.6	Solo la inyección SQL
< 6.8	No afectadas	—	No afectadas por esta cadena

Un apunte sobre las puntuaciones: no coinciden entre fuentes. El aviso oficial de GitHub la clasifica como crítica, la base de datos nacional de vulnerabilidades de EE. UU. le da 9.8, una evaluación de CISA le asigna 7.5 y CloudLinux la publicó como 10.0. WordPress la trató como crítica al margen del número, por tratarse de un vector no autenticado. Si tu proceso interno prioriza por CVSS, conviene saber que aquí ese número no es un criterio estable.

Lo que hicimos en Mapachio

Revisamos y parchamos los mas de 200 sitios que llevan soporte con nosotros, y avisamos a cada cliente una vez aplicado el parche. Contamos esto por dos razones: porque es información útil sobre nuestro propio servicio, y porque el resultado de esa revisión es lo que da forma a esta guía.

Seguridad Adicional: Imunify360 para sitios no parcheados.

Nuestros servidores corren Imunify360, un software de seguridad que previene varios ataques al servidor. Vale la pena ser exacto sobre qué aportó, porque circuló bastante entusiasmo mal calibrado al respecto.

• CloudLinux publicó reglas específicas contra wp2shell en el ruleset 8.32, con despliegue a los servidores en un par de horas.
• El aviso de CloudLinux tiene fecha del 18 de julio, es decir el día siguiente a la divulgación. Los primeros ataques reales se reportaron la noche del 17.
• Las reglas dependen de que ModSecurity esté activo y de que el dominio no haya sido excluido de la protección. Si alguna de las dos cosas no se cumple, no hay defensa.

Imunify360 cerró la ventana rápido y bloqueó la explotación masiva que vino después, que fue la mayor parte del volumen. Pero llegó después de la primera ola, y un WAF nunca deshace un compromiso previo. Por eso, aun en servidores con Imunify, revisamos sitio por sitio en vez de darlo por resuelto.

Pasos para revisar el sitio en caso de sospecha de ataque

Paso 1 — Verificar la versión

Si tu sitio está en cualquier versión entre 6.8.0 y 7.0.1, tienes que revisarlo.

WordPress hizo algo excepcional: empujar la actualización a los sitios del mundo entero mediante el sistema automático. Esa medida se reserva para casos extremos y da la medida de cómo evaluaron el riesgo internamente. Pero parcheado no es lo mismo que verificado como parcheado.

Las actualizaciones automáticas desactivadas, los permisos de escritura restringidos y los despliegues gestionados por Composer o por plataformas que fijan una versión concreta bloquean el empujón sin avisar a nadie. WordPress nunca publicó a cuántos sitios llegó realmente. La única confirmación válida es mirar la versión instalada, sitio por sitio.

Desde el panel

Escritorio → Actualizaciones. Es la vía más rápida, pero depende de que el panel sea accesible y de que ningún plugin altere lo que muestra.

Desde el Administrador de archivos de cPanel

Es la fuente que ningún plugin de seguridad puede ocultar. Abre public_html/wp-includes/version.php con el botón Edit y busca la primera línea:

$wp_version = '6.9.5';

Por consola

# Con WP-CLI, desde la carpeta del sitio
wp core version

# Sin WP-CLI
grep "^\$wp_version" wp-includes/version.php

# Varios sitios de una vez
find /home/*/public_html -name version.php -path "*wp-includes*" \
  -exec grep -H "^\$wp_version" {} \;

Paso 2 — Buscar señales en los archivos

Todo lo de esta sección se puede hacer desde el Administrador de archivos de cPanel, sin consola. Un sitio comprometido hoy no se ve comprometido: el negocio del atacante está en pasar desapercibido, así que no hay que buscar defacements sino artefactos.

1. Archivos PHP dentro de wp-content/uploads. Esa carpeta debería contener solo imágenes y documentos. Usa el buscador del Administrador de archivos filtrando por .php dentro de uploads. Ojo: casi todos los plugins dejan ahí un index.php vacío con el comentario «Silence is golden», y eso es legítimo. Lo que importa es si el archivo ejecuta algo.
2. Ordenar por fecha de modificación. Activa la columna Last Modified y ordena descendente. Cualquier archivo PHP tocado después del 17 de julio, fuera de las carpetas de plugins y temas, merece una mirada.
3. La carpeta wp-content/mu-plugins. Es el escondite favorito: se cargan en cada visita, no se pueden desactivar desde el panel y no aparecen en la lista de plugins. Muchas instalaciones no tienen esa carpeta; si aparece de la nada, revísala entera.
4. PHP suelto en la raíz de wp-content. Ahí solo deberían existir los drop-ins conocidos: object-cache.php, advanced-cache.php, db.php, db-error.php, maintenance.php, sunrise.php. Cualquier otro archivo PHP es sospechoso.
5. Los archivos .htaccess de la raíz, de wp-content y de uploads. Busca directivas auto_prepend_file o auto_append_file, y reglas de reescritura que apunten fuera del sitio.
6. Permisos de wp-config.php. No debería ser escribible por el grupo ni por otros.
7. El escaneo de malware del panel. Si tu hosting incluye ImunifyAV o similar, córrelo. En Mapachio está activo por defecto en todos los planes; en otros proveedores suele bastar con pedirlo por ticket.

Por consola, el equivalente de los dos primeros puntos:

# PHP dentro de uploads
find wp-content/uploads -name "*.php" -type f

# PHP modificado desde la divulgación, fuera de plugins y temas
find wp-content -name "*.php" -newermt "2026-07-17" \
  -not -path "*/plugins/*" -not -path "*/themes/*" -not -path "*/cache/*"

# Patrones de ejecución ofuscada
grep -rlE "(eval|assert)[[:space:]]*\([[:space:]]*(base64_decode|gzinflate)" \
  wp-content --include="*.php"

Paso 3 — Buscar señales en la base de datos

Estas consultas se ejecutan en phpMyAdmin, en la pestaña SQL. Son todas de solo lectura. Reemplaza el prefijo wp_ por el tuyo si es distinto: lo encuentras en wp-config.php, en la línea $table_prefix.

1. Administradores creados desde la divulgación

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%'
  AND u.user_registered >= '2026-07-17'
ORDER BY u.user_registered;

Presta atención a los correos de dominios gratuitos y a los nombres que imitan un servicio (soporte, wpengine, elementor). Un administrador legítimo casi siempre tiene correo del dominio de la empresa.

2. Permisos de administrador sin usuario

Un borrado hecho desde el panel limpia también los metadatos. Un borrado hecho por SQL crudo, no. Filas huérfanas con capacidades de administrador significan que alguien creó y eliminó cuentas sin pasar por WordPress.

SELECT m.user_id, m.meta_value
FROM wp_usermeta m
LEFT JOIN wp_users u ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%'
  AND u.ID IS NULL;

3. Huecos en los identificadores de usuario

Cuentas creadas y borradas dejan números consumidos. El dato solo tiene valor si el último registro cae dentro de la ventana: si el usuario más nuevo es anterior al 17 de julio, los huecos vienen de antes y no de este ataque.

SELECT COUNT(*) AS total,
       MAX(ID) AS maximo,
       MAX(ID) - COUNT(*) AS huecos,
       MAX(user_registered) AS ultimo_registro
FROM wp_users;

4. Tareas programadas con código

Persistencia clásica: reinstala el backdoor aunque borres el archivo.

SELECT option_name, LEFT(option_value, 500) AS extracto
FROM wp_options
WHERE option_name = 'cron'
  AND (option_value LIKE '%eval%'
    OR option_value LIKE '%base64%'
    OR option_value LIKE '%assert%'
    OR option_value LIKE '%file_put%');

5. La dirección del sitio

SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Si alguno apunta a un dominio que no es el tuyo, tienes un secuestro en curso.

6. Changesets apuntando a contenido inexistente

El paso en que el atacante hace que WordPress trate como legítimo un contenido fabricado deja este rastro: un customize_changeset cuyo padre es un identificador que no existe.

SELECT ID, post_parent, post_date, post_status
FROM wp_posts
WHERE post_type = 'customize_changeset'
  AND post_parent > (SELECT MAX(ID) FROM wp_posts
                     WHERE post_type <> 'customize_changeset');

7. Contenido publicado en la ventana

Incluye borradores y contenido privado: el spam inyectado suele no aparecer en los menús pero sí quedar indexado.

SELECT ID, post_title, post_type, post_status, post_date
FROM wp_posts
WHERE post_date >= '2026-07-17'
  AND post_type IN ('post', 'page')
ORDER BY post_date DESC;

8. Opciones autocargadas anormalmente grandes

Los backdoors que se guardan en la tabla de opciones para sobrevivir a la limpieza de archivos suelen delatarse por el tamaño.

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload = 'yes' AND LENGTH(option_value) > 100000
ORDER BY bytes DESC LIMIT 20;

Nota para multisitio: en una red, las opciones son por sitio. Repite las consultas 4 a 8 sobre wp_2_options, wp_3_options y siguientes, y la 1 y 2 cambiando wp_capabilities por wp_2_capabilities y así.

Herramientas gratuitas para apoyarte con la revisión del sitio

Publicamos dos, sin registro y sin condiciones.

1. Verificador de versión en línea

Escribes la dirección de un sitio y te dice qué versión de WordPress corre y si está al día. Consulta la última versión publicada contra la API oficial de WordPress y la compara con la que declara el sitio. No prueba vulnerabilidades ni toca rutas de ataque: solo lee información que el propio sitio publica.

Es deliberadamente simple, y tiene un límite que conviene tener claro: desde afuera solo se puede ver la versión. Saber si alguien ya entró requiere mirar por dentro, y para eso está la herramienta de abajo.

2. Revisor de compromiso (descarga)

Un archivo PHP que se sube a la raíz del sitio y hace automáticamente todo lo de los pasos 2 y 3, más tres verificaciones que a mano son inviables. Lo escribió nuestro equipo de seguridad y es de solo lectura: no modifica archivos, no escribe en la base de datos y no envía nada a ningún servidor.

Lo que hace por encima de una revisión manual:

• Verifica la integridad del núcleo contra los checksums oficiales de WordPress.org, archivo por archivo. Detecta un core modificado, que es lo que deja una intrusión seria y que ningún chequeo de versión ve.
• Verifica la integridad de los plugins contra los checksums por archivo del repositorio oficial. Esto atrapa una shell escondida dentro de la carpeta de un plugin legítimo, que es el escondite más común una vez que el atacante ya entró.
• Revisa los logs de acceso cuando el hosting lo permite, buscando la firma del ataque. Es el único lugar donde puede aparecer un robo de datos de solo lectura.
• Y lo de siempre: administradores creados en la ventana, cuentas con firma de exploit, permisos huérfanos, PHP ejecutable en uploads, mu-plugins, drop-ins, cron con código, secuestro de siteurl y plugins fantasma.

Cómo se usa: súbelo a la raíz de WordPress (junto a wp-config.php), inicia sesión como administrador, abre la dirección del archivo en el navegador, lee el reporte y bórralo con el botón que aparece al final. No hace falta configurar nada: si no hay sesión de administrador, el archivo no muestra nada.

Sobre los plugins premium, conviene entender por qué quedan fuera: no están publicados en el repositorio de WordPress.org, así que no existen checksums oficiales contra los cuales compararlos. Si tu sitio usa Elementor Pro, un tema comercial o cualquier complemento de pago, esa porción no la puede verificar ninguna herramienta automática — ni esta ni otra. Comprobarlos exige comparar contra el paquete original del proveedor, a mano.

Una nota de método, por transparencia: el revisor carga WordPress para poder consultar la base de datos y las APIs de checksums. Eso significa que también carga los mu-plugins del sitio. Si ya tienes sospecha fundada de un compromiso activo, la revisión no debería hacerse desde dentro del propio sitio; escríbenos y la hacemos desde fuera.

Licencia GPLv2+. El código está comentado para que puedas auditarlo antes de ejecutarlo, y no tiene dependencias ni llamadas ocultas.

Si no puedes actualizar hoy tu versión de WordPress

Actualizar es lo único que resuelve el problema; todo lo demás es contención. Si tienes una ventana de mantenimiento que no puedes saltarte, bloquea las dos formas de alcanzar el endpoint vulnerable y restringe el acceso anónimo a la API.

LiteSpeed (vía .htaccess)

RewriteEngine On

# Ruta directa
RewriteRule ^wp-json/batch/v1 - [F,L]

# Ruta alternativa por parámetro, incluida la forma codificada
RewriteCond %{QUERY_STRING} (^|&)rest_route=(/|%2F)batch(/|%2F)v1 [NC]
RewriteRule ^ - [F,L]

nginx

# Dentro del bloque server

location ~* ^/wp-json/batch/v1 {
    return 403;
}

# La forma por parámetro, contra $request_uri para cubrir
# también la variante codificada
if ($request_uri ~* "rest_route=(/|%2f)batch(/|%2f)v1") {
    return 403;
}

Remediación de wp2shell

Si la revisión manual o automática encontró indicadores de intrusión, olvida la idea de «limpiar» el sitio. Un sitio con ejecución de código confirmada se restaura, no se desinfecta: nunca vas a estar seguro de haber encontrado todo lo que dejaron.

1. Saca copia del sitio actual, tal como está. Sirve para dos cosas: es la evidencia si esto termina en una investigación o en una notificación a la autoridad, y es de donde vas a rescatar después el contenido publicado desde la fecha a la que vas a volver.
2. Restaura desde una copia anterior al 17 de julio. Anterior a esa fecha, no «la más reciente». Si tu hosting guarda 7 o 14 días de copias, a estas alturas todas caen dentro de la ventana y ya traen dentro lo que estás tratando de sacar. Verifica la fecha real de la copia antes de restaurarla.
3. Actualiza antes de volver a publicar. La copia que restauraste tiene la versión vulnerable. Deja el sitio en mantenimiento hasta que esté en 7.0.2, 6.9.5 o 6.8.6; con explotación automatizada activa, el intervalo entre publicar y actualizar se mide en horas.
4. Cambia las contraseñas. Esto el rollback no lo hace: la contraseña de la base de datos (y actualízala en wp-config.php) y la de todos los usuarios del sitio, no solo la tuya. Si se llevaron la tabla de usuarios, los hashes que acabas de restaurar son exactamente los mismos que robaron.
5. Cambia las claves de seguridad (los salts) de wp-config.php. Son las ocho constantes que empiezan en AUTH_KEY y terminan en NONCE_SALT, y sirven para firmar las cookies de sesión. Mientras sigan siendo las mismas, cualquier cookie que el atacante se haya guardado sigue siendo válida: puede volver a entrar sin escribir contraseña, aunque las hayas cambiado todas en el paso anterior. Genera un bloque nuevo en el generador oficial de WordPress y reemplaza las ocho líneas completas. El efecto es inmediato y conviene anticiparlo: se cierran todas las sesiones abiertas del sitio, incluida la tuya y la de tus usuarios. Todos tendrán que volver a iniciar sesión. Eso es precisamente lo que buscas.
6. Recupera el contenido nuevo desde la copia del paso 1. Y aquí la regla que evita reinfectarse: se recupera contenido, no código. Entradas, páginas, imágenes, pedidos, usuarios nuevos. Nunca archivos PHP, plugins ni temas. Si desde el 17 de julio instalaste algún plugin, bájalo otra vez del repositorio oficial en lugar de copiarlo del sitio viejo.
7. Vuelve a correr la revisión sobre el sitio ya restaurado, antes de sacarlo de mantenimiento. Es la única forma de confirmar que la copia que usaste estaba limpia.

Un poco de historia: Cómo se encontró el wp2shell

La cadena de ataque la descubrió Adam Kues, del equipo Assetnote de Searchlight Cyber, y la reportó a WordPress por su programa de recompensas en HackerOne. Lo llamativo no es el hallazgo sino el método.

Kues apuntó un modelo de inteligencia artificial —originalmente diseñado para resolver problemas matemáticos avanzados— al código fuente de WordPress. Para ponérselo difícil, le quitó el historial de versiones, de modo que no pudiera limitarse a rastrear parches viejos. Dejó corriendo varios agentes automáticos.

A los pocos minutos el modelo había detectado el desajuste en la API. Kues montó una instalación limpia y le pidió que robara el correo del administrador: lo tuvo en pantalla en un par de minutos. Unas cuatro horas después, el modelo confirmó que aquello podía escalarse hasta ejecución de código.

El trabajo completo llevó alrededor de diez horas y costó unos 25 dólares en consumo de la herramienta. Kues afirma que ningún investigador humano habría completado esa cadena en ese plazo sin ayuda de IA.

Referencias

• WordPress.org — Anuncio oficial de la versión 7.0.2
• GitHub Security Advisory — GHSA-ff9f-jf42-662q (confusión de rutas)
• GitHub Security Advisory — GHSA-fpp7-x2x2-2mjf (inyección SQL)
• Searchlight Cyber — Informe original del descubrimiento
• Rapid7 — Análisis técnico de CVE-2026-63030
• CloudLinux — Mitigación en Imunify360 (ruleset 8.32)
• Cloudflare — Protección WAF y análisis
• Eye Security — Guía de respuesta a incidentes
• VulnCheck — Seguimiento de explotación activa
• Picus Security — Desglose técnico de la cadena
• SecurityWeek — Explotación en el mundo real

---

Si necesitas ayuda

En Mapachio administramos hosting desde Arequipa para clientes dentro y fuera del Perú. Si tienes dudas con cualquier paso de esta guía, o quieres que revisemos un sitio contigo, escríbenos.

WhatsApp soporte: +51 958 335 634
Correo: soporte@mapachio.com

Si tu sitio está alojado con nosotros y tiene soporte contratado, ya fue revisado y parchado; te avisamos por nuestros grupos de soporte en Whatsapp.

Esta guía se actualiza cuando aparece información nueva. Última revisión: 31 de julio de 2026.