wp2shell: la RCE de WordPress que afecta tu hosting

En pocas palabras: wp2shell (CVE-2026-63030) es una RCE crítica en el núcleo de WordPress que afecta versiones 6.9.0 a 7.0.1: sin credenciales, cualquier atacante puede ejecutar código en tu servidor. El parche está disponible desde julio de 2026 en las versiones 6.9.5 y 7.0.2.

wp2shell (CVE-2026-63030) es una falla crítica de seguridad descubierta en 2026 en el núcleo de WordPress que afecta a toda instalación de las versiones 6.9.0 hasta 7.0.1, independientemente de los plugins instalados. Un atacante sin cuenta ni contraseña puede enviar peticiones especialmente construidas al endpoint REST API /wp-json/batch/v1 para encadenar una inyección SQL y conseguir ejecución de código en el servidor del hosting donde está alojado el sitio.

¿Qué es wp2shell y cómo explota una vulnerabilidad RCE en hosting?

wp2shell es el nombre que la comunidad de seguridad le dio a CVE-2026-63030, una falla de ejecución remota de código (RCE) en el core de WordPress que no requiere cuenta de usuario. Cualquier persona con acceso a internet puede intentar explotarla, sin importar si el sitio tiene habilitado el registro de usuarios o no.

La cadena de ataque tiene tres pasos. Primero, el atacante envía una petición maliciosa al endpoint /wp-json/batch/v1 (el sistema de procesamiento por lotes de la REST API), aprovechando una confusión en cómo WordPress parsea los parámetros del batch. Ese parsing defectuoso abre la puerta a una inyección SQL. Con esa inyección, el atacante puede escribir un archivo PHP arbitrario en el servidor, de ahí el nombre «wp2shell»: WordPress a shell, porque lo que termina consiguiendo es precisamente eso, una shell de sistema en el servidor del hosting. Y con un archivo PHP ejecutable en el servidor, tenés acceso completo de comandos.

Ponele que gestionás un sitio de e-commerce con WooCommerce. Un atacante explota wp2shell, escribe un webshell en tu directorio de uploads y en cuestión de minutos tiene acceso completo al servidor, a tu base de datos de clientes, a los datos de facturación y a todo el sistema de archivos. Sin haber ingresado ninguna contraseña (sí, en serio, ninguna). Cubrimos ese tema en nuestra guía sobre herramientas de scanning automático.

La diferencia entre una RCE y otras vulnerabilidades es de escala. Un XSS afecta a usuarios individuales. Un CSRF requiere que alguien haga clic en algo. Una RCE le da al atacante las llaves del servidor entero.

¿Cuáles son las versiones de WordPress vulnerables a wp2shell?

Las versiones afectadas son 6.9.0 a 6.9.4 y 7.0.0 a 7.0.1. Las versiones 6.9.5 y 7.0.2 incluyen el parche. Si tu instalación corre cualquier versión anterior a esas dos, es vulnerable hoy mismo.

Una aclaración que importa: WordPress habilitó actualizaciones automáticas forzadas para los parches de wp2shell. «Forzadas» no es lo mismo que «garantizadas». Si tu hosting bloquea las auto-updates, si tenés restricciones de escritura en disco, o si corrés WordPress detrás de ciertos sistemas de caché agresivos, la actualización puede no haberse aplicado aunque el sistema diga que sí. Verificá la versión en Escritorio > Actualizaciones antes de asumir que estás protegido.

¿Por qué una instalación WordPress estándar es vulnerable sin plugins extra?

El endpoint /wp-json/batch/v1 es parte del core de WordPress desde la versión 6.9. No necesitás ningún plugin de terceros para que esté activo: viene habilitado en toda instalación estándar. Eso es lo que hace a wp2shell particularmente seria: no hay un plugin culpable al que puedas señalar y desinstalar.

La API REST batch de WordPress se diseñó para que Gutenberg y otros clientes puedan enviar múltiples peticiones en una sola llamada HTTP. Es funcionalidad legítima y necesaria. El problema no es la idea sino la implementación: el parsing de esa petición batch tiene una falla que permite confundir al sistema sobre qué tipo de dato está procesando, y esa confusión deriva en SQL injection. Para más detalles técnicos, mirá nuestra guía sobre cómo proteger el acceso administrativo.

¿Alguien verificó esto de forma independiente antes de que llegara el parche? Según los reportes publicados por SLC Cyber y Aikido Security, la vulnerabilidad fue reproducida en entornos de prueba controlados antes de la divulgación coordinada con el equipo de WordPress. La investigación técnica detalla la cadena de explotación paso a paso.

Esto la distingue claramente de las vulnerabilidades de plugins: en ese caso, desinstalás el plugin y el riesgo desaparece. Acá, el único fix real es actualizar el core.

¿Cuál es el impacto real de una explotación wp2shell en hosting compartido?

Un ataque exitoso de wp2shell le da al atacante acceso de shell al servidor. Desde ahí, puede hacer básicamente lo que quiera con tu sitio y, en hosting compartido, potencialmente con los sitios vecinos.

• Robo de base de datos completa. La base de datos de WordPress contiene emails, contraseñas hasheadas, datos de pedidos y, si usás WooCommerce con pago integrado, datos de facturación de cada cliente.
• Instalación de malware persistente. Webshells, backdoors y scripts de redirección a sitios de phishing pueden quedar instalados sin que lo notes. El atacante puede volver días después aunque cambies la contraseña de WordPress.
• Compromiso del hosting compartido. Si el proveedor no tiene aislamiento adecuado entre clientes, un atacante que compromete tu WordPress puede moverse lateralmente hacia otros sitios alojados en el mismo servidor, según señala el análisis de Rapid7 sobre el impacto de la vulnerabilidad.
• Penalización SEO. El malware post-explotación suele inyectar spam de SEO (enlaces a casinos, farmacias falsas) en el HTML del sitio, lo que lleva a penalizaciones de Google y eventual deindexación.
• Creación de cuentas admin ocultas. El atacante puede crear usuarios con rol de Administrador para mantener acceso aunque cierres la vulnerabilidad original.

En hosting compartido el riesgo se multiplica. Subís tu WordPress al servidor, el atacante ejecuta código en tu espacio, y si el proveedor no tiene sandboxing serio entre usuarios, eso se convierte en el problema de todos los vecinos que no saben nada de tu sitio.

¿Cómo actualizar a WordPress 7.0.2 o 6.9.5 de forma segura?

Antes de actualizar, hacé un backup completo: archivos y base de datos. Si tu hosting no lo hace automáticamente (y deberías estar con uno que sí lo haga, como donweb.com, que incluye backups automáticos diarios en sus planes de WordPress), usá un plugin de backup antes de tocar nada.

• Actualización desde el panel. Ir a Escritorio > Actualizaciones, verificar que aparece WordPress 6.9.5 o 7.0.2 y hacer clic en «Actualizar ahora».
• Actualización via WP-CLI. Si tenés acceso SSH, wp core update --version=7.0.2 --force aplica el parche directamente desde línea de comandos.
• Testing en staging primero. Si tenés un entorno de staging, aplicá la actualización ahí y verificá que el editor de bloques, los formularios y el checkout funcionen antes de pasar a producción.
• Validación post-actualización. Después de actualizar, chequeá en el panel que la versión dice 7.0.2 o 6.9.5. No des por sentado que dice lo correcto (spoiler: a veces una actualización parcial deja el número en estado inconsistente).

Algo que pasa más seguido de lo que debería: la actualización automática queda colgada si hay plugins con conflictos en modo de mantenimiento, o si el proceso de escritura en disco falla silenciosamente. Chequeá en /wp-content/debug.log (si tenés WP_DEBUG habilitado) si la actualización realmente se completó, no solo si WordPress muestra el cartel de éxito.

¿Qué medidas implementar mientras se completa la actualización?

Si no podés actualizar de inmediato, hay medidas temporales que reducen el riesgo: bloqueá el endpoint /wp-json/batch/v1 en el WAF o en la configuración del servidor. En nginx, una regla que devuelva 403 para peticiones a ese path. En Apache, una directiva en el .htaccess hace lo mismo. Muchos proveedores con WAF activo publicaron reglas específicas para wp2shell en las horas posteriores a la divulgación pública de la vulnerabilidad. Para profundizar sobre esto, mirá nuestra guía sobre cómo configurar verificación de dos factores.

Subís la regla de bloqueo al WAF, configurás rate limiting en /wp-json, activás alertas de log para peticiones POST a ese endpoint, revisás las cuentas admin existentes, y mientras tanto avanzás con la actualización en staging, porque todas esas medidas son parches temporales, no reemplazos del update real.

• No desactivar la API REST completa. Gutenberg, WooCommerce y decenas de plugins dependen de /wp-json. Desactivar todo el endpoint para protegerte de wp2shell rompe el editor de bloques, los formularios y las integraciones. Bloqueá el path batch específicamente: /wp-json/batch/v1.
• Rate limiting en la API REST. Limitá las peticiones por IP a /wp-json para dificultar la automatización del ataque.
• Monitoreo de logs de acceso. Buscá peticiones POST a /wp-json/batch/v1 con respuesta 200. Un pico de peticiones a ese endpoint desde una misma IP es señal de escaneo activo.
• Auditoría de cuentas admin. Si encontrás cuentas admin que no reconocés, el sitio puede ya estar comprometido. Eliminalas y cambiá todas las contraseñas de inmediato.

¿Cómo detectar si mi sitio WordPress fue comprometido por wp2shell?

Si tu sitio corrió una versión vulnerable durante la ventana de exposición, conviene hacer una auditoría de compromiso aunque no veas nada raro a simple vista. Los atacantes no siempre hacen ruido: a veces instalan una puerta trasera silenciosa y esperan días o semanas antes de usarla.

• Cuentas de administrador nuevas no reconocidas. Ir a Usuarios > Todos los usuarios y filtrar por rol «Administrador». Cualquier cuenta que no creaste vos es señal de compromiso.
• Archivos PHP en /wp-content/uploads. Los archivos de medios no deberían ser PHP. Si encontrás .php en la carpeta de uploads, con alta probabilidad es un webshell instalado por el atacante.
• Verificación de integridad del core. WP-CLI tiene wp core verify-checksums que compara los hashes de tus archivos core contra los hashes oficiales del repositorio de WordPress. Cualquier diferencia es sospechosa.
• 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 simulando un user agent de Android.

¿Qué debe garantizar un hosting WordPress seguro contra vulnerabilidades de core?

wp2shell dejó en evidencia algo que ya se sabía pero que ahora es difícil ignorar: el hosting no es solo un lugar donde guardar archivos PHP. La capacidad de respuesta ante una vulnerabilidad crítica de core es una característica de infraestructura que separa los proveedores serios del resto.

Una vulnerabilidad como wp2shell pone a prueba el WAF del hosting en tiempo real. Si tu proveedor tardó 48 horas en publicar reglas para CVE-2026-63030, eso vale considerarlo cuando renovés el plan. La «seguridad incluida» de muchos planes de hosting compartido es marketing más que infraestructura.

Errores comunes al gestionar esta vulnerabilidad

• Asumir que no tener plugins de terceros vulnerables significa estar protegido. wp2shell está en el core de WordPress. No hay plugin que desinstalar. Si corrés 6.9.0 a 7.0.1, sos vulnerable sin importar el resto de la configuración.
• Deshabilitar toda la API REST como medida de emergencia. Muchas funcionalidades críticas dependen de /wp-json. Desactivar todo rompe Gutenberg, WooCommerce, Contact Form 7 y decenas de integraciones. La solución correcta es bloquear el endpoint batch específico (/wp-json/batch/v1), no toda la API.
• Actualizar y no verificar la versión real. Las actualizaciones automáticas pueden fallar silenciosamente y WordPress puede mostrar un mensaje de éxito que no refleja la realidad. Chequeá la versión en el panel o con wp core version vía WP-CLI después de cualquier update.
• No auditar el sitio antes ni después de actualizar. El parche cierra la puerta de entrada. Pero si el atacante ya pasó y dejó un webshell (que nadie encontró porque nadie lo buscó), ese webshell sigue funcionando perfectamente después de que actualizás WordPress.

Preguntas Frecuentes

¿Qué es wp2shell y por qué es diferente a otras vulnerabilidades de WordPress?

wp2shell (CVE-2026-63030) es una vulnerabilidad de ejecución remota de código en el core de WordPress descubierta en 2026, explotable sin autenticación. A diferencia de la gran mayoría de vulnerabilidades de WordPress, que están en plugins o themes, esta falla está en el núcleo mismo del CMS. Cualquier sitio con WordPress 6.9.0 a 7.0.1 es vulnerable sin excepciones, sin importar qué plugins tenga instalados. Ya lo cubrimos antes en nuestra guía sobre cómo fortalecer tu defensa integral.

¿Cómo sé si mi WordPress está corriendo una versión vulnerable?

En el panel de WordPress, ir a Escritorio > Actualizaciones o mirar el widget «En un vistazo». Si la versión está entre 6.9.0 y 6.9.4, o entre 7.0.0 y 7.0.1, el sitio es vulnerable. Las versiones 6.9.5 y 7.0.2 ya tienen el parche aplicado. También podés verificar via WP-CLI con el comando wp core version si tenés acceso SSH.

¿Qué puede hacer un atacante después de explotar wp2shell con éxito?

Con acceso de shell al servidor, el atacante puede crear cuentas de administrador ocultas, instalar webshells para acceso persistente, exportar la base de datos completa (usuarios, pedidos, datos de pago), inyectar malware en archivos de themes o plugins, y usar el servidor como base para atacar otros sistemas. En hosting compartido sin aislamiento adecuado, también puede intentar acceder a archivos de otros sitios en el mismo servidor.

¿Es suficiente con actualizar WordPress a 7.0.2 para estar completamente protegido?

Actualizar a 6.9.5 o 7.0.2 cierra la vulnerabilidad y evita nuevas explotaciones. Pero si el sitio estuvo expuesto durante la ventana de riesgo, conviene hacer una auditoría para descartar que ya haya un backdoor instalado. El parche evita que entren por esta puerta; no limpia lo que ya puede estar adentro.

¿Qué debe ofrecer un hosting WordPress seguro para proteger contra RCE como wp2shell?

Un hosting con seguridad activa publica reglas WAF específicas ante CVEs críticos en horas, aplica auto-updates de seguridad forzadas, ofrece monitoreo de integridad de archivos y tiene aislamiento de entornos para evitar movimiento lateral entre clientes. También debería notificar proactivamente ante vulnerabilidades críticas del CMS, sin esperar a que el cliente lo descubra por su cuenta.

Conclusión

wp2shell (CVE-2026-63030) es la peor clase de vulnerabilidad que puede tener un CMS: en el core, sin autenticación requerida, con acceso total al servidor como resultado. WordPress reaccionó con parches en 6.9.5 y 7.0.2 y habilitó auto-updates forzadas para distribuirlos, lo que mitiga el riesgo en instalaciones bien configuradas.

Lo que hacés ahora: verificar la versión de WordPress de cada sitio que gestionás, aplicar el parche si no se aplicó solo, y auditar buscando indicadores de compromiso (cuentas admin sospechosas, PHP en /wp-content/uploads, archivos core modificados). Si tenés acceso a un WAF, bloqueá /wp-json/batch/v1 como capa adicional aunque ya estés en la versión parcheada. Y si tu hosting no te notificó sobre wp2shell en las primeras horas de la divulgación pública, eso te dice exactamente qué tan activo es su equipo de seguridad.

Fuentes

• Rapid7 – ETR: CVE-2026-63030 wp2shell, RCE crítica en WordPress core
• SLC Cyber – wp2shell: RCE pre-autenticación en WordPress core (investigación técnica)
• Aikido Security – RCE sin autenticación en WordPress: análisis de wp2shell
• The Hacker News – Nueva falla en WordPress core permite ejecución de código (julio 2026)
• Cybersecurity News – Vulnerabilidad RCE wp2shell en WordPress