Tengo unos cuantas webs de Woocommerce y WordPress que no se puede actualizar a la ultima versión (por tema de php 7.4 o plugins abandonados pero obligatorios) pero existe otra ruta para cerrar la posibilidad de la vulnerabilidad wp2shell
Cuando tienes un sitio enganchado a plugins antiguos o temas muy personalizados como Printify, una actualización mayor de WordPress a la 6.9 o 7.0 te puede tirar la web abajo en tres segundos.
Vamos a solucionarlo sin actualizar todo el core. La vulnerabilidad wp2shell (CVE-2026-63030) aprovecha un fallo específico en el componente de procesamiento de lotes (Batch API) de la API REST de WordPress. Dado que estás en la versión 6.7.4, estás en una rama antigua que no recibe los parches automáticos de las ramas más modernas, por lo que estás expuesto a menos que tomemos medidas.
Tienes dos formas de solucionarlo manualmente sin romper nada de tu tema o tus plugins.
Opción 1: La solución más limpia (Desactivar la Batch API)
La vulnerabilidad se explota a través del endpoint /wp-json/batch/v1. La inmensa mayoría de los plugins antiguos y temas (incluyendo Printify) no utilizan este endpoint para nada, ya que fue introducido en versiones más recientes para agrupar peticiones API.
Puedes anular por completo este endpoint añadiendo un fragmento de código (snippet) al archivo functions.php de tu tema activo (o a través de un plugin de snippets como Code Snippets).
Copia y pega este código:
/**
* Mitigación manual contra wp2shell (CVE-2026-63030)
* Desactiva por completo el endpoint batch de la REST API
*/
add_filter('rest_pre_dispatch', function($result, $server, $request) {
$route = $request->get_route();
// Si la petición va dirigida al endpoint de procesamiento por lotes, la bloqueamos
if (strpos($route, '/batch/v1') !== false) {
return new WP_Error(
'rest_batch_disabled',
__('El procesamiento por lotes de la API está desactivado por motivos de seguridad.', 'text-domain'),
array('status' => 403)
);
}
return $result;
}, 10, 3);¿Por qué es seguro? Este código actúa como un escudo antes de que WordPress procese la petición maliciosa. Si alguien intenta explotar el fallo, el servidor le devolverá un error 403 Prohibido inmediatamente, impidiendo que el código vulnerable llegue a ejecutarse.
Opción 2: Bloqueo por servidor mediante .htaccess (Recomendado si usas Apache/LiteSpeed)
Si no quieres tocar archivos PHP de la web, puedes cortar el tráfico directamente desde la puerta de entrada del servidor. Si usas un servidor Apache o LiteSpeed, abre tu archivo .htaccess (ubicado en la raíz de tu WordPress) y añade estas líneas arriba del todo, antes de cualquier otra regla existente:
# BLOQUEO DE EMERGENCIA WP2SHELL
RewriteEngine On
RewriteCond %{REQUEST_URI} /wp-json/batch/v1 [NC]
RewriteRule .* - [F,L]Si tienes curiosidad como funciona el ataque wp2shell:
Básicamente, el ataque no ataca los datos de tu WooCommerce, sino que secuestra tu servidor para luego controlar la tienda desde dentro.
El proceso de infección funciona exactamente en estos 3 pasos rápidos:
- La Entrada: La API Batch de WordPress (/batch/v1) sirve para enviar varias peticiones en un solo paquete CSV o JSON. El atacante envía un paquete malformado a esa dirección.
- El Engaño (Exploit): Debido al fallo de código en WordPress, el servidor se confunde al procesar ese paquete y, en lugar de leer datos, ejecuta los comandos ocultos que el atacante metió ahí.
- El Control de la Tienda: Con esa ejecución, el atacante sube un archivo oculto (una shell o puerta trasera) a tu servidor. Desde ahí, entra como administrador supremo, pudiendo ver tus pedidos de WooCommerce, robar datos de clientes o modificar los precios a su antojo.
En resumen: Usan la tubería defectuosa de WordPress (/batch/v1) para colarse hasta la cocina del servidor y, una vez dentro de la casa, te abren la caja fuerte de WooCommerce. Al bloquear esa ruta, la tubería queda sellada por completo.