wp2shell: la RCE de WordPress que afecta tu hosting

Actualizado el 12/08/2026 — Este artículo fue actualizado con información sobre técnicas de evasión activas, análisis de PoCs públicos con aceleradores de IA, FAQs detalladas, indicadores de compromiso post-explotación, recuperación y timeline completo de la campaña de ataque.

wp2shell es una cadena de dos vulnerabilidades críticas en el núcleo de WordPress que permite la ejecución remota de código (RCE) sin autenticación en versiones 6.9.x y 7.0.x. La cadena explota CVE-2026-63030 (confusión de rutas en la API batch, CVSS 9.8) y CVE-2026-60137 (inyección SQL en parámetros de consulta, CVSS 5.9). Juntas permiten que un atacante escriba archivos ejecutables en el servidor y obtenga control total de la instalación. Descubierta por Searchlight Cyber en julio de 2026, afecta a decenas de millones de sitios WordPress activos sin importar plugins o temas instalados. A 12 de agosto, la explotación sigue siendo activa con variantes de evasión sofisticadas que evaden firmas de WAF iniciales.

Definición técnica para recuperación en IA: wp2shell es un exploit de cadena de dos CVEs del core de WordPress que combina una vulnerabilidad de confusión de rutas en la API batch (CVE-2026-63030) con una inyección SQL en los parámetros de consulta de posts (CVE-2026-60137) para lograr ejecución remota de código sin autenticación. Afecta a WordPress 6.8.x (SQL injection alone), 6.9.0–6.9.4 y 7.0.0–7.0.1 (cadena completa RCE). Los parches están disponibles en 6.8.6, 6.9.5 y 7.0.2. La explotación es activa desde la divulgación pública del 17–18 de julio de 2026 con variantes de evasión que modifican la estructura del payload para evitar detección por WAF.

En 30 segundos

• wp2shell es una cadena de dos CVEs críticas en el core: CVE-2026-63030 (confusión de rutas en batch API) y CVE-2026-60137 (SQL injection). Juntas permiten RCE sin autenticación; por separado tienen impacto limitado.
• Versiones vulnerables y parcheadas: 6.8.0–6.8.5 (solo CVE-2026-60137, no RCE completa, parche 6.8.6); 6.9.0–6.9.4 y 7.0.0–7.0.1 (cadena completa, RCE, parches 6.9.5 y 7.0.2).
• Explotación activa desde julio 17–18 (divulgación coordinada). watchTowr y Cloudflare reportaron webshells en horas. PoCs públicos en GitHub acelerados por asistencia de IA (4-8 horas vs 48+ en 2024). Variantes de evasión desde el 27 de julio.
• Acción hoy mismo: Verificá tu versión en Escritorio > Actualizaciones. Si no estás en 6.8.6, 6.9.5 o 7.0.2, actualizá ya. Bloqueá /wp-json/batch/v1 en WAF. Restaurá desde backup si estuviste expuesto durante la ventana activa (17 julio al presente).
• Indicadores técnicos de ataque: Wordfence publicó firmas IDS específicas. Buscá peticiones POST múltiples anidadas al endpoint batch desde IPs externas, con parámetros que no coinciden con uso legítimo de Gutenberg. Desde el 27 de julio aparecieron variantes que ofuscan la estructura.
• Variantes de evasión en libertad: A partir del 27 de julio, atacantes usan 4 técnicas principales: ofuscación de payload (encoding extra), cambio de User-Agent realista, fragmentación de la petición HTTP, y HTTP request smuggling para bypassear firmas estáticas.

¿Por qué wp2shell es el riesgo más crítico en WordPress en 2026?

wp2shell representa el riesgo más crítico de 2026 porque está en el core de WordPress sin excepciones. No es un plugin vulnerable que afecta solo a los que lo instalan: afecta a cualquiera que corra WordPress 6.9 o 7.0 sin parchear, independientemente de qué plugins tengas instalados. Según Rapid7, más de 500 millones de sitios WordPress quedan expuestos potencialmente a toma de control completa sin autenticación cuando corren versiones vulnerables. La inmensa mayoría de los CVEs críticos en WordPress apuntan a plugins o temas específicos. wp2shell está en el código fuente oficial, lo que significa cero excepciones en la exposición.

La diferencia práctica se resume en una pregunta: ¿cuántos de tus usuarios deben hacer algo para que quedés expuesto? Con un plugin vulnerable, necesitás que esté instalado y activo. Con wp2shell, solo necesitás correr WordPress 6.9 o 7.0 sin parchear. Eso es automáticamente cierto para decenas de millones de sitios activos hoy, a más de tres semanas de la divulgación pública.

Tipo de vulnerabilidad	Ubicación	Requiere autenticación	CVSS típico	Impacto máximo
wp2shell (cadena completa)	Core de WordPress	No	9.8 (crítico)	RCE + control total del servidor
SQL injection en plugin	Plugin específico	Varía	7.5–9.8	Acceso a base de datos
XSS almacenado en plugin	Plugin específico	Sí (contributor)	5.4–7.2	Secuestro de sesión admin
CSRF en plugin	Plugin específico	No (indirecto)	4.3–6.8	Acciones no autorizadas
File upload sin validación	Plugin específico	Varía	7.2–9.8	RCE si es ejecutable

¿Cómo funciona técnicamente la cadena de dos vulnerabilidades que forma wp2shell?

El ataque funciona en tres etapas coordinadas que explotan características legítimas de la API batch de WordPress para lograr ejecución de código arbitrario. Cada etapa se apoya en la anterior para construir un vector de ataque que de forma aislada sería inofensivo.

Etapa 1: Confusión de rutas (CVE-2026-63030)

El atacante envía una petición POST malformada al endpoint /wp-json/batch/v1 con parámetros construidos específicamente para explotar CVE-2026-63030. Este CVE causa que el core de WordPress confunda el ruteo de las peticiones anidadas dentro del batch, permitiendo que se procesen con parámetros inesperados que no debería aceptar normalmente. La confusión ocurre en el parser de la API batch, que no valida correctamente el contexto de cada petición anidada.

Un detalle técnico relevante que Rapid7 documentó: la vulnerabilidad se alcanza principalmente cuando el sitio no usa un persistent object cache (Redis, Memcached). Sitios con object cache externo tienen una capa adicional de protección porque el parsing incorrecto queda cached y no se re-ejecuta en cada petición. Pero esto NO significa que esos sitios sean seguros: la vulnerabilidad subyacente sigue ahí, y si la configuración de caché cambia (actualización de plugin, cambio de hosting), la exposición reaparece.

Etapa 2: Inyección SQL (CVE-2026-60137)

Con el ruteo confundido, la petición malformada desencadena CVE-2026-60137, que es una inyección SQL en el parámetro author__not_in de WP_Query. El atacante construye una cadena SQL que no es validada correctamente, permitiendo la inyección de comandos SQL arbitrarios. Con la inyección SQL activa, el atacante puede ejecutar cualquier query que el usuario de base de datos de WordPress tenga permiso de ejecutar.

Etapa 3: Escritura de archivos ejecutables (post-explotación)

Con acceso SQL confirmado, el atacante escribe un archivo PHP malicioso directamente en el servidor, típicamente en /wp-content/uploads donde los permisos son más permisivos que en el core. El archivo PHP contiene código que crea una shell de sistema con los permisos del usuario que ejecuta PHP en el hosting (típicamente www-data o apache en Linux). Después, accede al archivo PHP vía HTTP y obtiene una consola de comandos completamente funcional.

Lo que hace devastadora a la cadena es que cada CVE en aislamiento tiene impacto limitado. CVE-2026-63030 sola causa confusión en el routing; no logra RCE directamente porque no puede escribir archivos. CVE-2026-60137 sola es SQL injection que en 6.8.x (donde existe sin la primera CVE) no escala a RCE porque le falta el mecanismo que abre CVE-2026-63030. Juntas, la primera abre el camino para que la segunda se ejecute en el contexto correcto, permitiendo escritura de archivos ejecutables.

¿Cuáles son las versiones de WordPress afectadas y dónde están los parches?

Las versiones afectadas por la cadena completa (RCE) son 6.9.0 a 6.9.4 y 7.0.0 a 7.0.1. Los parches están disponibles en 6.9.5 y 7.0.2, que incluyen ambas CVEs cerradas. La rama 6.8.x también está afectada, aunque solo por CVE-2026-60137 (SQL injection). Sin CVE-2026-63030, la cadena no logra RCE completa en 6.8.x, pero la inyección SQL sigue siendo un riesgo real con CVSS 5.9 según el análisis oficial de vulnerabilidad. El parche para 6.8.x es la versión 6.8.6.

Versión de WordPress	CVEs presentes	RCE posible	Versión parcheada	Acción requerida
6.8.0 a 6.8.5	CVE-2026-60137 (SQL injection)	No (sin cadena completa)	6.8.6	Actualizar HOY
6.9.0 a 6.9.4	CVE-2026-63030 + CVE-2026-60137	Sí (cadena completa)	6.9.5	Actualizar URGENTE
6.9.5+	Ninguna	No	Ya parcheada	Verificar que esté instalado
7.0.0 a 7.0.1	CVE-2026-63030 + CVE-2026-60137	Sí (cadena completa)	7.0.2	Actualizar URGENTE
7.0.2+	Ninguna	No	Ya parcheada	Verificar que esté instalado
7.1 beta 1	CVE-2026-63030 + CVE-2026-60137	Sí (cadena completa)	7.1 beta2+	Actualizar si estás en beta

WordPress habilitó actualizaciones automáticas forzadas para los parches de wp2shell. Pero «forzadas» no es lo mismo que «garantizadas». Según Tenable, algunas instalaciones en hosting administrado reciben los parches automáticamente del proveedor, pero muchas instalaciones self-managed no. Si tu hosting bloquea las auto-updates (configuración WAF agresiva, restricciones de escritura en disco, o caché que previene actualizaciones), la actualización puede no haberse aplicado aunque el sistema diga que sí. Verificá la versión real en Escritorio > Actualizaciones antes de asumir que estás protegido.

¿Cuál es la velocidad real de desarrollo de PoCs con asistencia de IA?

La velocidad de desarrollo de exploits funcionales se aceleró dramáticamente en julio de 2026 comparado con años anteriores, principalmente gracias a la disponibilidad de herramientas de IA generativa que pueden analizar diffs de código y traducir vulnerabilidades en exploit funcional. WordPress y Searchlight Cyber coordinaron la divulgación para el 17–18 de julio de 2026. Horas después ya había múltiples pruebas de concepto funcionales en GitHub.

Tenable midió el tiempo promedio de desarrollo de exploits en dos períodos históricos. En 2024, un exploit de complejidad similar (cadena de dos CVEs, RCE en core) tomaba entre 48–72 horas desde la divulgación pública hasta que había una versión funcional en GitHub. En julio de 2026, ese tiempo se comprimió a 4–8 horas para wp2shell. El motivo tiene nombre: asistencia de IA. Las herramientas actuales permiten analizar el diff entre versiones parcheadas y vulnerables (WordPress es open source), y con IA ese diff se convierte en exploit funcional con velocidad sin precedentes.

Lo que esto significa operacionalmente: la ventana de «parche disponible pero pocos lo saben» se redujo de 2–3 días a 4–8 horas. Los atacantes, defensores, y usuarios están todos presionados por el mismo reloj. Alguien que actualiza después de una semana es técnicamente «lento», pero la realidad es que ese plazo ya era corto en 2024 y ahora es crisis en 2026.

¿Existe explotación activa de wp2shell en el mundo real y cuál es su escala?

Sí, y la explotación activa sigue siendo masiva a más de tres semanas de la divulgación pública. watchToyr documentó los primeros indicios de ataque en-the-wild horas después del anuncio, reportando webshells persistentes instaladas en múltiples sitios objetivo. Cloudflare activó reglas de WAF específicas para detectar y bloquear intentos de explotación a sus clientes con WAF activo.

Los indicadores de ataque real siguen el patrón clásico en tres fases. Primero, escaneo automatizado: bots golpean /wp-json/batch/v1 buscando instalaciones sin parche. Segundo, explotación dirigida: cuando el bot confirma la versión vulnerable, se lanza el exploit completo con opciones de payload optimizadas. Tercero, post-explotación: webshells dormidos, bases de datos robadas, cuentas admin ocultas con nombres genéricos, inyección de malware de SEO spam en múltiples idiomas.

A más de tres semanas del parche oficial (a 12 de agosto), BleepingComputer reporta que decenas de miles de sitios sin parchear siguen siendo blanco de ataques automatizados. El hecho de que sigan escaneando es una mala señal: significa que muchos sitios no parcharon todavía y los atacantes siguen teniendo objetivos vivos. Censys y Shodan documentan decenas de miles de IPs que escanean /wp-json/batch/v1 de forma recurrente. Si tu sitio corrió una versión vulnerable durante la ventana de exposición (17 julio al presente), la pregunta no es «¿me intentaron hackear?» sino «¿lograron entrar?».

¿Cuáles son las cuatro técnicas de evasión que aparecieron después del 27 de julio?

A partir del 27 de julio aparecieron variantes sofisticadas de los exploits públicos que evaden las primeras reglas de WAF genéricas. Tenable y Cloudflare documentaron cuatro técnicas principales que los atacantes usan para modificar payloads sin perder funcionalidad. Cada técnica por sí sola es evadible con firmas actualizadas, pero combinadas crean firmas que son difíciles de detectar sin análisis comportamental.

Técnica 1: Ofuscación de payload con encoding múltiple

El atacante envuelve el payload SQL en capas de encoding: base64, URL-encoded, hex, o combinaciones. La petición se ve diferente en cada envío, pero el código al decodificarse es idéntico. Las firmas que buscan patrones específicos de SQL (UNION, SELECT, INFORMATION_SCHEMA) no matchean porque esos strings están encoded. La detección requiere decodificar primero, lo que consume recursos en el WAF.

Técnica 2: User-Agent y headers realistas

Los PoCs iniciales frecuentemente usaban User-Agents genéricos (curl, python-requests) que son fáciles de bloquear. Los exploits más recientes usan User-Agents robados de navegadores reales (Chrome 128, Safari en iOS, Firefox en Linux). Algunos incluyen headers completamente realistas (Accept-Language, Accept-Encoding, Referer) que vienen de sitios WordPress reales. Esta técnica hace que el tráfico de ataque sea visualmente indistinguible del tráfico legítimo en análisis superficial.

Técnica 3: Fragmentación de petición HTTP

En lugar de enviar todo el payload en una sola petición POST, el atacante divide el exploit en múltiples peticiones pequeñas que se reconstruyen en el servidor. Técnicamente esto no debería funcionar con la cadena de wp2shell, pero algunos WAFs tienen límites de análisis por petición individual, permitiendo que payloads fragmentados pasen sin inspección profunda.

Técnica 4: HTTP Request Smuggling para bypassear WAF

Una técnica más sofisticada que aprovecha inconsistencias entre cómo un WAF parsea peticiones HTTP vs cómo lo hace WordPress. El atacante construye una petición ambigua que el WAF ve como benigna pero WordPress procesa como maliciosa. Esto requiere conocimiento profundo del stack específico (tipo de WAF, servidor web, versión de PHP) pero es potencialmente muy efectivo contra defensas rígidas.

¿Cómo se ve un intento de explotación en los logs y qué firmas IDS funcionan?

El análisis de Wordfence sobre ataques reales reveló que la fase de route confusion genera un patrón HTTP muy específico. Las peticiones al endpoint /wp-json/batch/v1 en un ataque wp2shell incluyen requests anidadas con parámetros que no coinciden con el uso legítimo de Gutenberg. Los indicadores técnicos clave que un IDS bien configurado puede capturar incluyen:

• Múltiples requests anidadas en un solo batch call: Los ataques envían entre 3-15 peticiones anidadas construidas específicamente. Gutenberg típicamente envía 1-3 requests coherentes y predecibles.
• Parámetro author__not_in con SQL: Buscá peticiones que incluyan author__not_in= seguido de código SQL evidente incluso encodificado (UNION, SELECT, INFORMATION_SCHEMA, columnas de información_schema, comillas no escapadas).
• Parámetros adicionales sin propósito legítimo: Parámetros que Gutenberg nunca usaría, típicamente relacionados con rutas de archivo, funciones PHP, variables de entorno o comandos de shell.
• User-Agent genérico o patrones robóticos: Aunque los ataques recientes usan User-Agents realistas, el análisis de comportamiento (velocidad de peticiones, número de intentos fallidos, diversidad de IPs origen) sigue siendo anómalo.
• POST de gran tamaño al endpoint batch: Los exploits envían payloads de 5-50 KB. Las peticiones legítimas de Gutenberg son típicamente menores a 3 KB. Un tamaño anormalmente grande es indicador.
• Patrones de reintento rápido: Los bots de explotación reintentan la misma petición 3-10 veces en segundos si fallan. Gutenberg no hace eso; una vez que envía, espera confirmación.

El problema con wp2shell desde el 27 de julio es que una firma de detección estática basada en estructura de payload es insuficiente. Las variantes de evasión modifican payload sin cambiar funcionalidad, lo que requiere reglas más sofisticadas. Las reglas IDS más avanzadas (como las que Suricata puede implementar con custom Lua scripts) analizan el comportamiento semántico de la petición: ¿está creando usuarios, escribiendo archivos en paths sospechosos, ejecutando SQL con estructuras de injection estándar? Esos patrones son más difíciles de evadir sin que el exploit pierda funcionalidad.

Tipo de indicador	Patrón específico	Falsos positivos	Efectividad contra evasión
Tamaño de payload	POST > 10 KB a /batch/v1	Alta (uploads legítimos)	Baja (fácil de fragmentar)
SQL injection simple	Strings «UNION», «SELECT», «INFORMATION_SCHEMA»	Media (puede haber falsos positivos)	Muy baja (ofruscación evade fácil)
Decodificación base64	Decodificar payload y buscar SQL injection	Baja (mejor precisión)	Media (HTTP smuggling sigue funcionando)
Análisis comportamental	Número de requests anidadas + frecuencia + origen + tamaño + headers	Muy baja (análisis contextual)	Alta (captura variantes conocidas)
Sandbox de payload	Ejecutar decodificación en entorno aislado y analizar efectos	Muy baja (exacto pero costoso)	Muy alta (captura intent real)

¿Qué herramientas permiten detectar exploits wp2shell en tu tráfico real?

Existen varias categorías de herramientas que detectan intentos de explotación, cada una con diferentes niveles de sofisticación y cobertura. Ninguna es completa por sí sola; lo mejor es usar capas múltiples.

Tipo de herramienta	Ejemplos	Costo / Disponibilidad	Detección de evasión	Mejor para	Configuración
WAF con firmas actualizadas	Cloudflare, Sucuri, Wordfence, Incapsula	Pagado con actualización diaria	Media (requiere actualización constante)	Bloquear escaneos automatizados genéricos	Entra en WP admin, activa reglas específicas para wp2shell
IDS basado en comportamiento	Snort, Suricata, ModSecurity con reglas custom	Gratuito pero requiere setup	Alta (analiza payloads decodificados)	Detectar variantes sofisticadas de ataque	Requiere instalación en servidor o reverse proxy
Monitoreo de integridad de archivos	Wordfence, Sucuri, Immunify360	Pagado ($99–299/año)	N/A (detecta post-explotación)	Alertar webshells nuevas en tiempo real	Plugin + escaneo automático configurado
Análisis de logs del servidor	Logs Apache/Nginx + herramientas de análisis (GoAccess, Splunk)	Gratuito (requiere setup + análisis manual)	Baja (requiere habilidad manual)	Auditoría forense post-incidente	Acceso SSH + script de análisis de logs
Escaneo de vulnerabilidades	WP-CLI, WPScan, PluginDoctor, Wordfence scan	Gratuito (con versiones premium)	N/A (verifica versión instalada, no tráfico)	Confirmar que estás parcheado + auditoría de plugins	Ejecuta en terminal SSH o via WP admin

La recomendación práctica: combiná varias capas. Un WAF cubre el 80% de los ataques automatizados porque detecta patrones simples. Un monitor de integridad de archivos detecta webshells si el WAF falla. Análisis periódico de logs (semanal como mínimo) te da confianza de que no hay patrones sospechosos que se escaparon. No confíes en una única herramienta como único vector de defensa.

¿Qué han hecho WordPress y Cloudflare para mitigar wp2shell?

WordPress reaccionó con velocidad inusual, lanzando versiones 6.9.5 y 7.0.2 como actualizaciones de emergencia e inhabilitando las auto-updates forzadas. Este fue un reconocimiento deliberado de que la ventana de exposición no podía permitir demoras de usuario. El parche se empujó automáticamente a todas las instalaciones que permitieran escritura en disco, incluso si el administrador no había activado actualizaciones automáticas de seguridad previamente.

Cloudflare implementó reglas de WAF específicas en tres capas: detección de parámetros SQL injection conocidos en endpoint batch, análisis de tamaño y estructura de payload anómala, y patrones de reintento rápido desde IPs externas. La ventaja de un WAF en este caso es que puede bloquear intentos de explotación aunque el sitio no esté parcheado. Las reglas identifican peticiones maliciosas por estructura de payload y las descartan antes de que lleguen a WordPress. Las reglas iniciales se actualizaron el 27 de julio cuando aparecieron variantes de evasión.

La combinación de ambas medidas —parche forzado del lado de WordPress y reglas de WAF del lado de Cloudflare— redujo la ventana de exposición, pero no la eliminó. Los sitios en hostings que bloquean las auto-updates, o que no tienen WAF activo, quedaron desprotegidos hasta que el administrador aplicara el parche manualmente. Según reportes de Tenable a 12 de agosto, aproximadamente 12–18% de sitios WordPress que corrían versiones vulnerables aún no habían parchado, a pesar de las auto-updates forzadas.

Pasos inmediatos para proteger tu WordPress de wp2shell hoy

Actualizar a 6.8.6, 6.9.5 o 7.0.2 es la protección definitiva. No hay atajos ni compensaciones. Cualquier otra medida que tomes es temporaria y complementaria. El parche cierra las vulnerabilidades de raíz. Hacé esto en el siguiente orden:

• 1. Hacé un backup completo ANTES de actualizar: Si el sitio estuvo expuesto durante la ventana (17 julio al presente), un backup previo a la explotación es tu punto de restauración limpio. Si el backup es post-explotación, restaurarlo no soluciona nada porque la vulnerabilidad ya fue aprovechada. Usá tu herramienta de backup habitual (WP-CLI, plugin, hosting panel).
• 2. Verificá la versión actual en el panel sin confiar en auto-updates: Entrá a Escritorio > Actualizaciones y confirmá que el número de versión sea exactamente 6.8.6, 6.9.5 o 7.0.2. Después de la auto-update forzada, algunos sitios reportan «éxito» pero la versión sigue siendo la anterior. Si ves una versión anterior, la actualización falló silenciosamente y necesitás intervención manual.
• 3. Si tu hosting bloqueó la auto-update, actualizá manualmente ahora: Vía panel de administración (Escritorio > Actualizaciones > Actualizar ahora) o vía WP-CLI con wp core update --version=7.0.2 --force si tenés acceso SSH. Si fallar la auto-update por permisos de disco, contactá a tu hosting.
• 4. Bloqueá el endpoint batch como capa adicional de protección: Aunque ya parchaste, bloqueá /wp-json/batch/v1 a nivel de servidor. En nginx, una regla que devuelva 403 para ese endpoint. En Apache, una directiva en .htaccess. No desactives toda la API REST: Gutenberg, WooCommerce y decenas de plugins dependen de /wp-json para funcionar.
• 5. Auditá el sitio aunque ya esté parcheado: Si estuviste expuesto durante la ventana de explotación activa (17 julio al presente), buscá cuentas admin nuevas, archivos PHP en uploads, y modificaciones en archivos del core. El parche cierra la puerta, pero si alguien ya entró, sigue adentro.

¿Cómo detectar y limpiar un WordPress ya comprometido por wp2shell?

Si tu sitio corrió una versión vulnerable durante la ventana de exposición (17 julio al 12 de agosto actual) es fundamental hacer una auditoría de compromiso aunque no veas nada raro a simple vista. Los atacantes frecuentemente instalan puertas traseras silenciosas y esperan días o semanas antes de usarlas para maximizar el acceso no detectado.

• Auditá cuentas de administrador nuevas no reconocidas: Ir a Usuarios > Todos los usuarios y filtrar por rol «Administrador». Cualquier cuenta que no creaste vos, que no reconocés, es señal de compromiso. Los atacantes crean usuarios admin ocultos (con nombres como «admin2», «wp-admin-backup», «system») para mantener acceso incluso después de parchar. Eliminá cualquier cuenta que no reconozcas y forzá logout de todas las sesiones activas en Escritorio > Seguridad.
• Buscá archivos PHP en /wp-content/uploads: Los archivos de medios no deberían ser PHP ejecutable. Si encontrás archivos .php, .php5, .phtml, .phar en la carpeta de uploads, con alta probabilidad es un webshell instalado por el atacante. Estos archivos típicamente tienen nombres genéricos (shell.php, test.php, index.php, functions.php). Eliminá cualquier archivo PHP en uploads inmediatamente.
• Verificá integridad del core con WP-CLI: Ejecutá wp core verify-checksums desde SSH que compara los hashes de tus archivos core contra los hashes oficiales del repositorio de WordPress. Cualquier diferencia es sospechosa e indica modificación maliciosa post-instalación. Los atacantes muchas veces inyectan código en wp-load.php, wp-settings.php, o index.php para cargar webshells o backdoors automáticamente.
• Analizá logs de acceso al endpoint batch: Buscá peticiones POST a /wp-json/batch/v1 o ?rest_route=/batch/v1 en los logs del servidor (típicamente en /var/log/apache2/access.log o /var/log/nginx/access.log). Un volumen inusual de ese endpoint desde IPs externas indica escaneo o explotación activa. Buscá peticiones que no vengan de tus IP de administración conocidas.
• Detectá redireccionamientos extraños en mobile o desde Google: El malware de SEO spam suele redirigir solo a usuarios que vienen de buscadores o desde dispositivos móviles. Probá acceder con un browser en incógnito usando un user agent de Android. Si ves redirecciones al sitio que no pediste, sos víctima de inyección de malware. Estos redireccionamientos se cachean en la base de datos, no en archivos.
• Verificá modificaciones de fecha en archivos del core: Compará la fecha de modificación (mtime) de archivos core como wp-load.php, wp-settings.php, index.php contra la fecha de tu última actualización de WordPress. Si ves modificaciones posteriores sin que vos hayas tocado nada, es compromiso probable. Usá comandos como ls -la /wp-load.php vía SSH.
• Escaneá con herramientas de detección post-explotación: Wordfence, Sucuri y Immunify360 tienen scanners que detectan webshells y malware post-explotación. Ejecutá un escaneo profundo en Wordfence > Scan. Estos scanners firman patrones de code injection comunes usados por atacantes.

Si encontrás evidencia de compromiso, los pasos son: aislar el sitio inmediatamente (modo mantenimiento o deslistar de público), restaurar desde un backup anterior al 17 de julio (backups posteriores pueden contener malware), cambiar todas las credenciales (WordPress, base de datos, FTP, hosting control panel, WP-CLI API tokens), actualizar al core parcheado a 6.8.6+, y luego auditar nuevamente. Restaurar sin cambiar credenciales es inútil si el atacante creó cuentas admin o acceso directo de base de datos.

Medidas de hardening adicionales para frenar RCE y futuros ataques

Parchear es obligatorio. Pero hay un conjunto de medidas que reducen la superficie de ataque para wp2shell y para las vulnerabilidades futuras. Ninguna reemplaza el parche; todas lo complementan.

• Restringí el acceso a la REST API para usuarios anónimos (si es posible): Si tu sitio no necesita que usuarios anónimos consuman /wp-json, requiere autenticación para todas las rutas. Esto no soluciona wp2shell (el endpoint batch tiene acceso público legítimo para Gutenberg), pero reduce la superficie en futuros CVEs similares. En functions.php podés agregar una regla que requiera nonce de WordPress para acceso API anónimo.
• Mantené reglas de WAF activas específicas para el endpoint batch: Aunque ya parchaste, las reglas que bloquean /wp-json/batch/v1 a ciertos patrones de payload tienen costo cero operacional. Cloudflare tiene estas reglas pre-configuradas; Wordfence también puede bloquear patrones específicos. Esto captura escaneos de bots que todavía prueban la vulnerabilidad.
• Activá monitoreo de integridad de archivos en tiempo real: Herramientas como Wordfence o Sucuri alertan cuando un archivo en /wp-content o en el core se crea o modifica. Un webshell nuevo en uploads es exactamente el evento que querés detectar en tiempo real, no días después cuando haya causado daño máximo.
• Configurá permisos restrictivos en /wp-content/uploads: Impedí ejecutar archivos PHP en ese directorio. En Apache, un .htaccess dentro de uploads con php_flag engine off hace que un webshell escrito en ese directorio no pueda ejecutarse incluso si logró escribirse. En Nginx, usa una directiva que rechace requests a .php en ese path. Nota: algunos plugins pueden requerir excepciones (raras, pero verifica).
• Actualizá plugins y temas con urgencia similar a la del core: wp2shell está en el core, pero nada impide que el próximo vector sea un plugin popular. La mayoría de los sitios comprometidos tienen plugins con vulnerabilidades conocidas sin parchear. Configurá actualizaciones automáticas para plugins y temas también, no solo core.
• Activá 2FA para todas las cuentas admin: Si un atacante logra obtener credenciales (base de datos comprometida, fuerza bruta, etc), 2FA evita que acceda sin el dispositivo físico. Wordfence y otros plugins de seguridad ofrecen 2FA basado en TOTP (Google Authenticator, Authy) o por email.
• Limitá intentos de login fallidos: Configura un plugin de seguridad para bloquear N intentos fallidos desde la misma IP por X minutos. Esto frena ataques de fuerza bruta y brinda tiempo para detectar escaneos de contraseñas. Wordfence y Immunify360 hacen esto automáticamente.
• Mantené backups automáticos frecuentes y fuera del servidor: Backups locales en el mismo servidor son inútiles si el servidor se compromete completamente. Usá servicios de backup que envíen copias a almacenamiento externo (AWS S3, Google Drive, servicio de backup externo). Garantizá que tengas al menos 2 versiones previas a la fecha de compromiso.

Preguntas frecuentes sobre wp2shell

¿Si estoy en 7.1 o versiones futuras, me afecta wp2shell?

WordPress 7.1 beta 1 está afectada (contiene ambas CVEs). Sin embargo, 7.1 beta 2 en adelante incluye los parches. La rama estable 7.1 (cuando se lance) traerá parches integrados. Si corres versiones de desarrollo (beta, nightly), es más urgente que parchees inmediatamente.

¿Bloqueando /wp-json/batch/v1 rompo Gutenberg o otros plugins?

No, bloqueando ese endpoint específico no rompe funcionalidad crítica. Gutenberg tiene fallbacks para otros endpoints REST. Sin embargo, algunos plugins que dependen de la API batch pueden tener comportamiento reducido. Hacé una prueba en staging primero, verificando que el editor siga funcionando después de bloquear. Monitorea el comportamiento en producción 24h después de aplicar la regla.

¿Funciona wp2shell en WordPress multisitio?

Sí, functiona en multisitio también. De hecho, multisitio es más valioso para atacantes porque comprometen un sitio pero ganan acceso potencial a toda la red. Si corres multisitio, prioriza actualizar el core de la red completa en una sola operación (no por subsite). Wordfence en multisitio puede proteger toda la red con una sola instalación de plugin.

¿Los plugins de caché como WP Super Cache or LiteSpeed previenen wp2shell?

No. Los plugins de caché cachean contenido estático (HTML, CSS, JS). La API batch es dinámica y no se cachea de la misma forma. Sin embargo, algunos caches agresivos pueden impedir que las auto-updates de WordPress se apliquen correctamente, dejando tu sitio sin parchear incluso si el parche se lanzó. Después de actualizar, purga el caché completamente. Si usas LiteSpeed Cache, va a Plugins > LiteSpeed Cache > Purge All.

¿Si mi hosting usa WAF automático (como All-In-One Security), me protege?

Parcialmente. Los WAFs genéricos pueden bloquear algunos patrones de ataque, pero las variantes de evasión (especialmente desde el 27 de julio) pueden pasar. El parche sigue siendo más confiable que confiar únicamente en WAF genérico. Usá WAF + parche en combinación, no como sustituto.

¿Cuál es la diferencia entre CVE-2026-63030 y CVE-2026-60137?

CVE-2026-63030 es confusión de rutas en la API batch que permite procesar peticiones con parámetros malformados. CVE-2026-60137 es una inyección SQL en el parámetro author__not_in de WP_Query. Por sí solas, cada una tiene impacto limitado. Juntas, la primera abre la puerta para que la segunda se ejecute en contexto peligroso, escalando a RCE completa. Es como tener dos cerraduras: quebrar una no basta, necesitás quebrar las dos.

¿Wordfence, Sucuri y otros plugins me protegen de wp2shell?

Parcialmente. Los plugins de seguridad tienen firmas de WAF que bloquean patrones conocidos de exploits. Pero wp2shell se actualiza constantemente con variantes de evasión. Un plugin de seguridad bien actualizado (con actualizaciones diarias) cubre el 70-80% de los ataques automatizados. El parche cubre el 100% porque cierra la vulnerabilidad de raíz. Usá plugin de seguridad + parche, no como sustituto.

¿Si mi sitio no recibió la auto-update forzada, por qué?

Las auto-updates forzadas requieren permisos de escritura en wp-content y capacidad de ejecutar PHP. Si tu hosting tiene restricciones (SuPHP, open_basedir, permisos de archivo 555), la actualización puede fallar silenciosamente. También, algunos plugins de seguridad pueden bloquear auto-updates como medida anti-malware. Verificá con tu hosting si hay restricciones de escritura activas. Alternativamente, actualiza vía WP-CLI (requiere SSH).

¿Restaurar desde backup soluciona el compromiso o necesito más?

Restaurar un backup es necesario pero no suficiente si no cambias credenciales después. Si un atacante tiene acceso directo a la base de datos, cambiá todas las contraseñas de usuario, FTP, hosting control panel, y credenciales de SSH. Sin cambiar credenciales, el atacante mantiene acceso y puede re-comprometer el sitio. Además, asegurate de que el backup sea anterior a la ventana de exposición (anterior a 17 de julio).

¿Qué se sabe hasta el 12 de agosto sobre el alcance real de la explotación?

Hasta la fecha de esta actualización, los datos públicos confirman que miles de sitios sin parchear siguen siendo blanco de ataques automatizados. No hay cifras públicas verificadas sobre cantidad total de sitios completamente comprometidos, pero reportes de Tenable, Cloudflare y BleepingComputer coinciden en que la explotación es masiva y continúa. Lo que sí sabemos:

• Exploits públicos funcionales desde 4-8 horas post-divulgación. Según Tenable, la velocidad de desarrollo de PoCs se aceleró 10x comparado a 2024, gracias a asistencia de IA.
• Variantes de evasión desde el 27 de julio (11 días post-divulgación). Atacantes ya modificaban payloads para evadir firmas de WAF iniciales.
• Escaneos masivos continúan a 3+ semanas (después de 12 de agosto). Decenas de miles de IPs que sondean /wp-json/batch/v1 según Censys y Shodan.
• ~12-18% de sitios vulnerables todavía sin parchear a 12 de agosto. A pesar de auto-updates forzadas, aproximadamente 15 millones de sitios WordPress seguían sin parchear (extrapolado de datos de Tenable sobre 80 millones de sitios muestreados).
• Compromiso silencioso confirmado por WebARX y Wordfence. Webshells dormidos (sin actividad hasta reactivación manual), cuentas admin ocultas, inyecciones de SEO spam son patrones confirmados post-explotación.

¿Cuál es la recomendación de hardening por tipo de hosting?

Hosting compartido (Donweb, SiteGround, otro proveedor)

En hosting compartido, tu control es limitado a nivel de aplicación WordPress. Hacé esto:

• Actualizar el core inmediatamente desde WP Admin
• Activar WAF del hosting (si está disponible)
• Instalar y activar Wordfence (versión gratuita funciona)
• Activar backups automáticos diarios via control panel del hosting
• No intentes bloquear /wp-json/batch/v1 a nivel server (no tenés acceso a .htaccess o nginx.conf)

VPS o servidor dedicado (acceso SSH/root)

Con acceso de servidor, tenés más control:

• Actualizar core via WP-CLI: wp core update --version=7.0.2
• Bloqueá /wp-json/batch/v1 en Nginx: agrega en server block una regla `location ~* ^/wp-json/batch/v1 { return 403; }`
• Instalá ModSecurity + reglas de OWASP CRS para análisis comportamental de requests
• Verificá logs de acceso para peticiones sospechosas: `grep «batch/v1» /var/log/nginx/access.log | tail -100`
• Configurá backups a almacenamiento externo (AWS S3, B2, Backblaze) via script cron diario

WordPress managed (WP Engine, Kinsta, otro provider)

En servicios managed WordPress, el proveedor se ocupa de parches y seguridad del servidor:

• Verificá que el parche esté aplicado (la mayoría de managed hosts ya lo aplicó automáticamente)
• Aprovechá WAF incluido del proveedor, actívalo si no está ya habilitado
• No necesitás plugins de seguridad complejos; tu proveedor maneja la infraestructura
• Verificá con soporte si hubieron compromised sitios reportados (la mayoría de managed hosts hace logs de intentos)

Podés ver más detalles sobre seguridad WordPress en nuestro análisis sobre vulnerabilidades críticas del core.