wp2shell: la vulnerabilidad que deja entrar en tu WordPress sin contraseña

El 17 de julio de 2026, WordPress publicó tres versiones de seguridad de golpe y activó actualizaciones automáticas forzadas. Cinco días después ya había ataques masivos en marcha. El motivo tiene nombre: wp2shell, una cadena de dos vulnerabilidades que permite a cualquiera ejecutar código en tu servidor sin usuario, sin contraseña y sin necesidad de que tengas ningún plugin instalado.

Si tu web va con WordPress, esto te interesa por dos motivos. El primero, obvio: puede que estés en una versión vulnerable. El segundo, menos evidente: muchos sitios que se actualizaron a tiempo ya habían sido comprometidos antes, y actualizar no expulsa a quien ya está dentro.

Debajo tienes un analizador gratuito para salir de dudas en unos segundos, y después la explicación completa: qué es wp2shell, cómo saber si ya han entrado, los tipos de infección que estamos viendo cada semana y las siete capas que de verdad protegen una instalación.

Qué es exactamente wp2shell

wp2shell es el nombre que se le ha dado a la combinación de dos fallos del núcleo de WordPress —no de un plugin, no de un tema— que por separado eran manejables y juntos abren la puerta de par en par:

• CVE-2026-63030: un fallo de lógica en el procesador por lotes de la API REST (/wp-json/batch/v1). Valida las peticiones en un bucle y las ejecuta en otro; cuando una URL no se puede analizar, los índices se desalinean y una petición acaba ejecutándose bajo el manejador de otra.
• CVE-2026-60137: una inyección SQL en el parámetro author__not_in de WP_Query cuando se envía como texto en lugar de como lista.

Encadenados, permiten crear una cuenta de administrador y, con ella, subir un plugin con una webshell dentro. A partir de ahí, el atacante hace lo que quiera: inyectar spam, robar datos de clientes, usar tu servidor para mandar correo basura o cifrarlo todo.

¿Qué versiones están afectadas?

Las ramas afectadas son la 6.8, la 6.9 y la 7.0. WordPress publicó las correcciones el mismo día del aviso:

Si tienes las actualizaciones automáticas activadas, es probable que ya estés parcheado: WordPress forzó la actualización a escala global. Pero conviene comprobarlo, porque muchos sitios las tienen desactivadas —a veces sin saberlo— por un plugin de mantenimiento o por decisión del hosting.

Cinco días entre el parche y los ataques

La cronología explica por qué tantos sitios cayeron pese a existir parche desde el primer día:

Cinco días es más de lo que parece y menos de lo que se necesita. Para una empresa con una web y mantenimiento contratado, actualizar es cuestión de minutos. Para una pyme cuya web hizo alguien hace tres años y nadie mira desde entonces, cinco días es tiempo de sobra para que un script automatizado llegue antes.

Cómo saber si ya han entrado

Actualizar cierra la puerta, pero no echa a quien ya está dentro. Estos son los rastros concretos que deja wp2shell y que puedes buscar tú mismo:

• Peticiones raras a /wp-json/batch/v1 en los registros de acceso del servidor. Es el indicador más directo: casi ninguna web legítima usa ese endpoint de forma habitual.
• Usuarios administradores que no reconoces. Míralo en Usuarios → Todos y filtra por rol. Ojo: algunos se ocultan del listado, así que conviene revisarlo también en la base de datos.
• Plugins que no has instalado, sobre todo con nombres genéricos y sin descripción ni autor.
• Archivos PHP con fecha de modificación reciente en wp-content/uploads/, donde no debería haber ni un solo archivo PHP.
• Tareas programadas extrañas en el cron de WordPress, que es como se garantizan volver a entrar aunque borres la puerta trasera.

Los hackeos que estamos viendo cada semana

wp2shell es la puerta; lo que entra por ella varía. Estos son los casos que más nos llegan, con su nombre técnico por si has llegado hasta aquí buscándolo:

Spam SEO japonés

Google muestra tu dominio con títulos en japonés vendiendo relojes o bolsos falsos. Usa cloaking: tú ves tu web perfectamente normal y Googlebot ve miles de páginas de spam. Es el más desconcertante, porque el dueño de la web tarda semanas en enterarse — normalmente cuando ya se ha desplomado el posicionamiento.

Pharma hack

La misma mecánica pero con contenido de farmacia. Especialmente dañino para la reputación del dominio, porque Google asocia el sitio a contenido de riesgo y cuesta meses recuperarse.

Robo de datos de tarjetas

En tiendas WooCommerce, un script inyectado en la pasarela copia los datos de pago de tus clientes mientras los teclean. Además del problema económico, es una brecha de datos personales que probablemente haya que notificar a la Agencia Española de Protección de Datos en 72 horas.

Phishing alojado en tu dominio

Cuelgan de tu servidor copias falsas de bancos. Es la causa más frecuente de suspensión inmediata por parte del hosting y de que los navegadores empiecen a bloquear tu web con una pantalla roja.

Tu servidor enviando spam

El síntoma que notas no es la web: es que tus correos normales empiezan a caer en la carpeta de spam de todo el mundo, porque tu dominio ha acabado en listas negras.

Las siete capas que de verdad protegen

La seguridad perfecta no existe, pero la diferencia entre un sitio que aguanta y uno que cae casi nunca está en tener el plugin de seguridad de moda. Está en estas siete cosas, ordenadas por lo que más reducen el riesgo con menos esfuerzo:

1. Actualizar es aburrido y es lo que más funciona

La inmensa mayoría de los sitios comprometidos lo están por algo que tenía parche disponible. Activa al menos las actualizaciones automáticas de seguridad del núcleo. Si te da miedo que una actualización rompa algo —miedo razonable—, la solución no es dejar de actualizar, sino tener un entorno de pruebas y copias que funcionen.

2. Doble factor en todas las cuentas de administrador

Convierte en inútil cualquier contraseña robada, filtrada o adivinada. Es la medida con mejor relación entre lo que cuesta activarla y lo que evita.

3. Menos administradores

Cada cuenta de administrador es una llave maestra. La agencia que te hizo la web hace cuatro años probablemente sigue teniendo una. Revisa la lista cada trimestre y baja de rol a quien no necesite serlo.

4. Copias de seguridad fuera del servidor

Si la copia vive en el mismo servidor que la web, el atacante la borra o la cifra junto con todo lo demás. Y una copia que nunca has restaurado no es una copia: es una suposición. Puedes profundizar en nuestra guía de copias de seguridad en WordPress.

5. Un cortafuegos de aplicación delante

Un WAF no sustituye al parche, pero compra tiempo: bloquea la explotación masiva durante esas horas o días que tardas en actualizar. Con wp2shell, quien tenía un WAF decente pasó el susto sin consecuencias.

6. Cerrar lo que no usas

xmlrpc.php si no lo necesitas, el editor de archivos del panel, la enumeración de usuarios por la API y el listado de directorios. Son puertas que casi nadie usa y que todos los escáneres automáticos prueban. El analizador de arriba te dice cuáles tienes abiertas.

7. Vigilancia de cambios en archivos

Es lo que marca la diferencia entre enterarte el día que aparece la webshell o tres meses después, cuando te lo dice Google con una penalización. Tienes más medidas en nuestra guía completa de seguridad en WordPress y en el checklist de ciberseguridad para pymes.

Preguntas frecuentes

¿Cómo sé qué versión de WordPress tengo?

Entra en el panel y mira en Escritorio → Actualizaciones, o abajo del todo en el escritorio: aparece el número de versión. Si no tienes acceso al panel, el analizador de este artículo intenta averiguarlo desde fuera, aunque muchos sitios bien configurados ocultan ese dato a propósito.

Ya he actualizado. ¿Estoy a salvo?

Estás a salvo de que te entren por ahí a partir de ahora. Pero si te comprometieron antes de actualizar, el atacante sigue dentro: la puerta trasera que dejó no se elimina al actualizar el núcleo. Por eso conviene revisar los indicadores que explicamos más arriba.

¿El analizador entra en mi web o necesita mis contraseñas?

No. Solo consulta páginas públicas de tu sitio, exactamente las mismas que vería cualquier visitante escribiendo esas direcciones en el navegador. No prueba ninguna vulnerabilidad, no envía nada malicioso y no necesita ningún acceso. Tampoco guardamos el resultado.

El analizador no ha podido determinar mi versión. ¿Eso es malo?

Al contrario, suele ser buena señal: significa que tu web no publica la versión, que es una de las recomendaciones básicas de configuración. Compruébala desde tu panel.

Mi hosting dice que se encarga de la seguridad. ¿Es suficiente?

Depende de lo que incluya. Un buen hosting protege el servidor y a veces aplica reglas de WAF, pero casi ninguno se responsabiliza de tus plugins, de tus usuarios ni de limpiar tu web si entran. Pregunta en concreto: ¿actualizáis el núcleo? ¿Y los plugins? ¿Limpiáis si hay infección o solo suspendéis la cuenta?

¿Cuánto cuesta limpiar un WordPress hackeado?

En LaudeMMedia, desde 390 € + IVA con presupuesto cerrado antes de empezar, y el diagnóstico previo es gratuito. Lo importante no es solo el precio: es que la limpieza incluya cerrar la vía de entrada. Una limpieza que no lo hace se paga dos veces.

¿Puedo limpiarlo yo mismo?

Si tienes acceso al servidor, sabes leer registros y te manejas con la base de datos, sí. La parte difícil no es borrar el malware que se ve: es encontrar todas las puertas traseras y averiguar cómo entraron. Si te falta alguna, vuelven.

En resumen

• wp2shell permite ejecutar código en tu servidor sin usuario ni contraseña, y afecta al núcleo de WordPress, no a un plugin.
• Las versiones corregidas son 6.8.6, 6.9.5 y 7.0.2. Comprueba la tuya hoy.
• Actualizar cierra la puerta, pero no expulsa a quien ya entró: revisa los indicadores de compromiso.
• Si tu web ya está infectada, lo urgente es limpiarla y cerrar la vía de entrada; si solo se limpia, cerca de la mitad de los sitios se reinfectan en 30 días.

Fuentes consultadas: el aviso de seguridad de WordPress, el análisis técnico de Rapid7, la bitácora de INCIBE-CERT y el catálogo de vulnerabilidades explotadas conocidas de CISA.