El viernes 17 de julio, WordPress publicó las versiones 6.9.5 y 7.0.2 para tapar wp2shell, un agujero que permite ejecutar código en un sitio sin usuario y sin contraseña. Esa misma tarde ya había quien lo estaba explotando. El domingo, VulnCheck contaba más de veinte exploits públicos distintos. Si tu empresa tiene una web WordPress —y con más de 500 millones de sitios en el mundo según Searchlight Cyber, las probabilidades son altas—, la pregunta de esta semana no es técnica: es ¿quién la actualizó? Y si la respuesta es «no lo sé», este post va de ti.
Qué es wp2shell y por qué no es «otro aviso más»
wp2shell no es un fallo, son dos encadenados, y los dos viven en el núcleo de WordPress, no en un plugin: CVE-2026-63030 (CVSS 9,8), una confusión de rutas en el endpoint batch de la REST API (/wp-json/batch/v1) introducida en la versión 6.9, y CVE-2026-60137, una inyección SQL en el parámetro author__not_in de WP_Query que se arrastraba desde la 6.8. Por separado son feos; encadenados permiten a un atacante anónimo pasar de una petición HTTP a ejecutar código en el servidor.
Lo que lo hace distinto: no necesita nada de ti. Ni un plugin vulnerable, ni un usuario descuidado, ni una configuración rara. Una instalación por defecto, recién salida de la caja, era explotable. La inmensa mayoría de los sustos de WordPress de los últimos años venían de plugins y temas; los fallos graves de core son raros. Este es de core, es pre-autenticación y es ejecución de código. La trilogía completa.
Las versiones, claras: la cadena completa (RCE) afecta a 6.9.0–6.9.4 y 7.0.0–7.0.1, corregida en 6.9.5 y 7.0.2. En la rama 6.8 existe la inyección SQL sola (sin cadena RCE): 6.8.0–6.8.5, corregida en 6.8.6. Si tu versión no es ninguna de las tres corregidas —o una posterior—, deja de leer y actualiza.
De parche a arma en una tarde
La cronología del fin de semana merece mirarse despacio, porque es la verdadera noticia. El viernes 17 a las 17:45 (hora del este de EE. UU.), Rapid7 publicaba que no había explotación confirmada. Antes de las 19:00 del mismo día, Patchstack ya reportaba explotación activa. Entre «no hay constancia» y «está pasando» no pasó ni hora y media. El domingo 19, VulnCheck había verificado más de dos docenas de exploits públicos únicos. Tenable atribuye parte de esa velocidad a herramientas de desarrollo de exploits asistidas por IA.
Ya lo dijimos a raíz del Patch Tuesday récord de julio: la capacidad de la industria de fabricar exploits ha escalado con la IA; la capacidad de las empresas de aplicar parches, no. «Parchearé en la ventana de cambios de fin de mes» era un plan razonable en 2016. En 2026, la distancia entre el parche y el arma se mide en horas, y la ventana de cambios de fin de mes es una eternidad.
La paradoja del fin de semana: se salvaron las webs «abandonadas»
Aquí viene la parte incómoda. WordPress forzó la actualización automática en las instalaciones que la tenían habilitada. Resultado: la web que nadie mira desde 2022 se parcheó sola durante el fin de semana. ¿Y quién se quedó expuesto todo el fin de semana? Las instalaciones que tenían las actualizaciones automáticas desactivadas a propósito: por control de cambios, por un tema muy personalizado que «se rompe si actualizas», por un pipeline de staging que valida antes de subir. Es decir: cuanto más «gestionada» parecía la web, más papeletas tenía de pasarse el fin de semana explotable, esperando a que alguien volviera el lunes.
La lección no es «activa las auto-updates y reza». Es que tener proceso no es lo mismo que tener mantenimiento. Mantenimiento es que exista alguien cuyo trabajo incluya enterarse un viernes por la tarde de que ha salido un parche crítico, evaluarlo y decidir aplicarlo ya —aunque sea viernes—. Si tu proceso de cambios convierte un parche de seguridad crítico en un ticket que espera al lunes, tu proceso está optimizado para un mundo que ya no existe.
¿Quién mantiene tu web? (en serio, ponle nombre)
El patrón que vemos una y otra vez en empresas: la web la hizo una agencia hace cuatro años. El proyecto se entregó, se pagó y se cerró. Desde entonces, la web es un mueble: se estrenó y se olvidó. Nadie renueva sus plugins, nadie lee sus logs, nadie sabe qué versión de PHP corre debajo. Hasta que una semana como esta, el mueble resulta ser lo que siempre fue: un servidor tuyo, expuesto a Internet las 24 horas, con tu marca en la puerta.
Y un WordPress comprometido casi nunca «se nota». No te borran la portada: te usan. Para alojar páginas de phishing, para spam SEO, para distribuir malware desde tu dominio. Lo descubres cuando tu dominio cae en listas negras, el correo corporativo deja de llegar y quien te lo dice es un cliente. El coste no es la web: es todo lo que tu marca arrastra detrás.
Qué hacer hoy, en este orden
- 1.Mira la versión. Escritorio → Actualizaciones, o
wp core versioncon WP-CLI. Si no estás en 7.0.2, 6.9.5 o 6.8.6 (o superior), actualiza ahora mismo, aunque estés leyendo esto en horario de comida. - 2.No des por hecho que la auto-update saltó: compruébalo. Instalaciones con las actualizaciones automáticas desactivadas, con el core versionado en git o en alojamientos peculiares se quedaron fuera de la actualización forzada. Searchlight Cyber, que destapó el fallo, publicó una herramienta de comprobación en wp2shell.com.
- 3.Si estuviste expuesto entre el día 17 y tu actualización, revisa. Peticiones POST a
/wp-json/batch/v1en los logs, administradores nuevos que nadie creó, ficheros PHP recientes enuploads/. Ante cualquier señal: rota contraseñas y salts, y trata el sitio como comprometido hasta demostrar lo contrario. - 4.Y lo de siempre: esta vez fue el core, pero la superficie de ataque real de un WordPress medio siguen siendo sus plugins. Menos plugins, más actualizados, y fuera los que llevan un año sin mantenimiento de su autor.
La solución estructural no es un plugin: es un dueño
Todo lo anterior es, literalmente, un parche. Lo estructural es que tu web —y el servidor donde vive— tenga un dueño. Dueño significa: parches de seguridad aplicados con criterio y con prisa cuando toca, backups que alguien ha probado a restaurar, monitorización que avisa cuando algo raro pasa, y una persona localizable un viernes a las siete de la tarde. Nada de esto es glamuroso. Tampoco lo es pagar la limpieza de un sitio comprometido y explicárselo a tus clientes.
En everyWAN no hacemos webs; a eso no nos dedicamos. Nos dedicamos a la parte de debajo: mantenimiento informático con parches, backups y monitorización como disciplina —sea un cluster de virtualización o el servidor donde vive tu web— y soporte 24/7 para que un aviso de viernes por la tarde no espere al lunes. Es la parte del IT que no luce en ninguna presentación. También es la que decidió, este fin de semana, qué webs amanecieron el lunes siendo suyas y cuáles no.
En corto
wp2shell se corrige con un clic. Lo que no se corrige con un clic es no saber quién tenía que darlo. Esta semana el clic era en WordPress; el mes que viene será en otro sitio. La pregunta sigue siendo la misma: cuando salga el próximo parche crítico un viernes por la tarde, ¿quién de tu lado se va a enterar?
Fuentes (verificadas): detalle técnico de la cadena, versiones afectadas y corregidas, y endpoint /wp-json/batch/v1 — Tenable y BleepingComputer; cronología parche (17-jul) → explotación esa tarde (Rapid7/Patchstack) → más de dos docenas de exploits verificados por VulnCheck el 19-jul — Servola; actualización forzada y aviso general — Help Net Security. La estimación de más de 500 millones de webs WordPress es de Searchlight Cyber (descubridores del fallo), citada por BleepingComputer.
¿Tu web (y el servidor de debajo) tienen dueño?
En everyWAN mantenemos infraestructura desde 1996: parches con criterio, backups probados y monitorización que avisa antes de que lo haga un cliente. Si el wp2shell te ha pillado sin saber a quién llamar, esa es la conversación pendiente.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN