Una cadena de dos fallos en el núcleo de WordPress, bautizada como wp2shell, permite a un atacante tomar el control de un servidor sin necesidad de usuario, contraseña ni ningún plugin instalado. El proyecto publicó los parches el 17 de julio y forzó actualizaciones automáticas a escala mundial, pero cinco días después ya circulaban exploits públicos y se confirmaban ataques reales contra sitios sin actualizar. El agujero afecta al gestor de contenidos que sostiene buena parte de la web comercial española.
La vulnerabilidad tiene dos identificadores. El primero, CVE-2026-63030, es un fallo de lógica en el procesador por lotes de la API REST, el componente que permite agrupar varias peticiones en una sola. El segundo, CVE-2026-60137, es una inyección SQL en un parámetro de consulta de contenidos. Por separado, ninguno de los dos habría bastado. Encadenados, permiten crear una cuenta de administrador y, con ella, instalar un plugin con código malicioso dentro.
Qué significa «sin autenticar»
La mayoría de las vulnerabilidades que se publican cada mes en el ecosistema WordPress exigen alguna condición previa: tener instalado un plugin concreto, disponer de una cuenta con ciertos permisos o convencer a un administrador de que haga clic en algo. wp2shell no pide nada de eso.
Basta con que el sitio esté publicado en internet y funcione con una versión afectada. Por eso los ataques observados son automatizados y masivos: un programa recorre listas de dominios, prueba la petición y, cuando encuentra una instalación sin parchear, actúa sola. No hay selección de víctima ni interés particular por una empresa concreta. La web de una clínica dental de provincias y la de una multinacional entran en la misma lista.
La firma de seguridad Rapid7, que publicó el análisis técnico más detallado del caso, describe el mecanismo con precisión: el procesador por lotes valida las peticiones en un bucle y las ejecuta en otro distinto, de modo que cuando una dirección no se puede interpretar los índices se desalinean y una petición acaba ejecutándose bajo el manejador de otra. Ese desajuste es lo que permite esquivar las comprobaciones que en condiciones normales habrían bloqueado la inyección.
Cinco días de margen
La cronología del incidente explica por qué tantos sitios acabaron comprometidos pese a existir una corrección desde el primer día.
El 17 de julio de 2026, WordPress publicó tres versiones de seguridad —6.8.6, 6.9.5 y 7.0.2— y activó el mecanismo de actualización automática forzada, reservado para casos graves. El 21 de julio, la agencia estadounidense de ciberseguridad CISA incorporó la vulnerabilidad a su catálogo de fallos explotados conocidos, una lista que obliga a las agencias federales a parchear en plazos tasados y que el resto del mundo utiliza como termómetro de gravedad. El 22 de julio se hicieron públicos los detalles técnicos y las primeras pruebas de concepto, y con ellos empezó la explotación a gran escala.
En España, el INCIBE-CERT recogió el caso en su bitácora de seguridad y señaló las tres consecuencias observadas en los sitios comprometidos: instalación de webshells, creación de cuentas administrativas no autorizadas y despliegue de complementos maliciosos para mantener el acceso aunque el propietario limpie lo evidente.
Las versiones afectadas
Están afectadas las ramas 6.8, 6.9 y 7.0 anteriores a las correcciones. En concreto, las versiones 6.8.0 a 6.8.5, las 6.9.0 a 6.9.4 y las 7.0.0 y 7.0.1. Quien tenga 6.8.6, 6.9.5, 7.0.2 o cualquier versión posterior está fuera de peligro por esta vía.
Comprobar la versión instalada es cuestión de segundos desde el panel de administración, en el apartado de actualizaciones. Para quien no tenga acceso al panel —una situación más común de lo que parece cuando la web la hizo un tercero hace años— existen herramientas que intentan deducirla desde fuera. La agencia malagueña LaudeMMedia ha publicado un analizador gratuito que comprueba si una web es vulnerable a wp2shell y revisa de paso otros seis puntos habituales de exposición, como la lista de usuarios accesible desde la API o los registros de depuración publicados por error.
Actualizar no expulsa a quien ya entró
Este es el matiz que más problemas está causando. Aplicar el parche cierra la puerta, pero no revierte lo que haya ocurrido antes. Si un atacante aprovechó la ventana de esos días para crear una cuenta de administrador o dejar un archivo con acceso remoto, esa cuenta y ese archivo siguen ahí después de actualizar.
Los indicios que conviene revisar son concretos. En los registros de acceso del servidor, peticiones inusuales a la ruta del procesador por lotes de la API. En el listado de usuarios, cuentas con permisos de administrador que nadie recuerda haber creado. En el directorio de subidas, archivos PHP donde solo debería haber imágenes y documentos. Y en las tareas programadas, entradas que no corresponden a ningún plugin conocido.
El error más frecuente entre quienes descubren que han sido atacados es reinstalar WordPress por encima o restaurar una copia de seguridad antigua sin más. Ninguna de las dos cosas resuelve el problema: el código malicioso rara vez se aloja en los archivos del núcleo, y si la vía de entrada continúa abierta la reinfección llega en cuestión de horas. Los especialistas en limpieza de WordPress hackeado coinciden en que alrededor de la mitad de los sitios que se limpian sin cerrar la puerta de acceso vuelven a caer en un plazo de treinta días.
Por qué las pymes son las más expuestas
WordPress se ha convertido en el estándar de facto para la web corporativa pequeña y mediana precisamente por lo que ahora se vuelve en su contra: es barato de poner en marcha y no exige conocimientos técnicos para el mantenimiento diario. El resultado es un parque enorme de sitios que funcionan sin que nadie los vigile.
El patrón se repite con variaciones menores. Una empresa encarga su web, la recibe funcionando y deja de pensar en ella. El proveedor que la hizo cerró, cambió de actividad o simplemente terminó el encargo. Las actualizaciones automáticas están desactivadas porque en su día una rompió algo, y desde entonces nadie ha vuelto a activarlas. Cuando llega un aviso como el de julio, no hay nadie a quien le llegue.
El coste de un incidente rara vez se limita a la reparación técnica. Google marca el sitio en sus resultados, el proveedor de alojamiento suspende la cuenta cuando detecta envío de correo masivo desde el servidor y el posicionamiento acumulado durante años se desploma en semanas. Recuperar la posición en buscadores suele llevar meses; limpiar la web, uno o dos días.
Entre las empresas del sector que han publicado material divulgativo sobre el caso está LaudeMMedia, agencia de marketing digital y desarrollo web con sede en Málaga y más de veinticinco años de actividad, que ha detallado la cadena de explotación y las medidas de contención. La recomendación que repiten todos los avisos oficiales, sin embargo, es la más sencilla y la que menos se cumple: mantener el gestor actualizado y activar las actualizaciones automáticas de seguridad.
Qué hacer esta semana
Para una empresa con una web en WordPress, la lista es corta. Comprobar la versión instalada y, si está entre las afectadas, actualizar de inmediato. Revisar el listado de usuarios administradores y eliminar los que no correspondan a nadie identificable. Activar las actualizaciones automáticas de seguridad si estaban desactivadas. Y, si aparece cualquiera de los indicios descritos, no tocar nada antes de guardar una copia del estado actual: es la única prueba que permitirá saber después cómo entraron.
El caso de wp2shell no es excepcional por su gravedad técnica —el ecosistema acumula vulnerabilidades críticas cada año—, sino por lo que revela sobre el mantenimiento real de la web empresarial española. Un fallo con parche disponible el mismo día del aviso seguía siendo explotable semanas después en miles de sitios cuya única característica común era que nadie los estaba mirando.
