El 17 de julio de 2026, millones de webs WordPress amanecieron con la puerta abierta. Y la mayoría de sus dueños no se enteró.
Yo sí me enteré, porque me tocó de lleno. Gestiono webs propias y de clientes, y aquella mañana dejé de hacer todo lo demás.
Te cuento qué pasó, cómo puedes comprobar si te afectó y qué deberías hacer ahora. Sin humo y sin tecnicismos vacíos: solo lo que necesitas saber.
Ese día se publicó un aviso de seguridad que cambió las reglas del juego. Los investigadores de Searchlight Cyber habían encontrado una forma de tomar el control completo de una web WordPress sin contraseña, sin usuario y sin que nadie hiciera clic en nada.
La bautizaron wp2shell. Y lo importante no es el nombre, es esto: no hacía falta tener un plugin pirata, ni un tema raro, ni una contraseña débil. Bastaba con tener WordPress instalado y actualizado a una versión de los últimos meses (incluso las más recientes).
Cuatro días después, el 21 de julio, las agencias de ciberseguridad ya confirmaban que se estaba explotando de forma masiva en todo el mundo.
Cada semana sale alguna vulnerabilidad de algún plugin de WordPress. La mayoría afectan a un plugin concreto que quizá ni tienes instalado, y se arreglan solas con una actualización.
Esta no. Esta estaba en el propio núcleo de WordPress. En el código que tenemos todos.
wp2shell no es un fallo: son dos, encadenados. Y ahí está lo elegante (y lo peligroso) del asunto.
Ninguno de los dos, por separado, permitía gran cosa. Juntos permitían crearse un usuario administrador, entrar en el escritorio y subir un plugin con código malicioso. Control total, en segundos, desde cualquier parte del mundo.
Los atacantes dejaron desde puertas traseras de tres líneas hasta un plugin falso de 150 KB con interfaz gráfica, gestor de archivos y acceso a la base de datos. Un panel de control completo, dentro de tu web.
| Rama | Versiones afectadas | Versión corregida |
|---|---|---|
| Anterior a 6.8 | No afectada | — |
| 6.8 | 6.8.0 – 6.8.5 (solo la inyección SQL) | 6.8.6 |
| 6.9 | 6.9.0 – 6.9.4 | 6.9.5 |
| 7.0 | 7.0.0 – 7.0.1 | 7.0.2 |
Si no sabes qué versión tienes: entra en tu escritorio de WordPress y mira abajo a la derecha. Lo pone ahí.
Y si el número que ves está en la columna del medio, deja de leer y actualiza ahora. Vuelve luego. 👇
¿Prefieres comprobarlo desde fuera? Los investigadores que descubrieron el fallo publicaron un comprobador gratuito en wp2shell.com: le das tu dominio y te dice si la puerta sigue abierta. Está en inglés, y es el mismo comprobador que recomienda el INCIBE en sus avisos oficiales, así que puedes fiarte de él.
Pero ojo con cómo lees el resultado, porque es justo lo que voy a explicarte a continuación: te dice si eres vulnerable hoy, no si alguien entró ayer. Un «no vulnerable» no es un certificado de que estás limpio.
¿Y si no puedes actualizar ahora mismo? Hay negocios con desarrollos a medida que no pueden tocar la versión de un día para otro.
Las dos medidas que recomienda el propio INCIBE para aguantar mientras tanto son bloquear el acceso anónimo a la API REST de WordPress, o configurar un firewall (WAF) que corte las peticiones a la ruta /wp-json/batch/v1 y al parámetro rest_route=/batch/v1. Son parches de urgencia, no una solución: la solución es actualizar.
Esto es lo que más cuesta digerir, y lo entiendo perfectamente.
La mayoría de la gente asume que si su web tiene un problema de seguridad es porque alguien la ha descuidado. Contraseñas flojas, plugins piratas, versiones de hace tres años. Y muchas veces es así.
Aquí no. Una instalación limpia, recién hecha, sin un solo plugin, con una contraseña de treinta caracteres, era igual de vulnerable que la peor web abandonada de internet.
Los datos de la firma de seguridad Wiz lo dejan claro: el 60 % de las organizaciones que usaban WordPress tenían al menos una instalación vulnerable el día que se publicó el fallo. No hablamos de negligentes: hablamos de casi todo el mundo.
Si te ha pasado, no es culpa tuya. Lo que sí depende de ti es lo que viene después.
Aquel jueves revisé una por una todas las webs que llevo. Y salieron dos grupos muy claros.
El 30 de julio a las 22:37 me entró este correo. Lo enviaba el INCIBE-CERT, el equipo de respuesta a incidentes del Instituto Nacional de Ciberseguridad, y avisaba de que una de las webs que gestiono parecía vulnerable:
Fíjate en lo que dice: CVSS 9.8 sobre 10 y «está siendo activamente explotada». Eso no es una alerta rutinaria. Es la máxima categoría, con el organismo público de ciberseguridad del país llamando a tu puerta a las once menos cuarto de la noche.
No voy a venderte que lo tenía todo blindado de antemano. Te cuento lo que pasó de verdad: a la mañana siguiente, a primera hora, la web estaba actualizada, revisada y verificada. Y cinco días después el propio INCIBE cerró la incidencia:
Aviso el jueves por la noche, resuelto el viernes por la mañana, cerrado y confirmado por el CERT nacional. Doce horas.
No fue mérito de un plugin mágico ni de un antivirus carísimo. Fue que alguien leyó ese correo y supo qué hacer con él.
Aquí es donde se entiende de verdad para qué sirve el mantenimiento preventivo.
En una web sin nadie detrás, el aviso del 17 de julio no llega a ninguna parte. No hay quien lea los boletines de seguridad. No hay quien compruebe la versión. No hay quien mire los logs. La web sigue ahí, funcionando de maravilla de cara al público, con la puerta abierta durante días o semanas.
Y esa es la parte fea: una web comprometida no se rompe. No sale un aviso rojo. Sigue cargando igual de rápido y con el mismo aspecto de siempre. Por eso hay quien todavía hoy no sabe que le entraron en julio.
Un mantenimiento no evita que aparezcan vulnerabilidades. Evita que te pillen desprevenido cuando aparecen. Que no es lo mismo, pero es lo único que se puede hacer.
Actualizaciones vigiladas, copias fuera del servidor y alguien que se entera antes que tú. Sin permanencias.
Esta es la más importante de todo el artículo.
Actualizar a 6.9.5 o 7.0.2 cierra la puerta. Pero si alguien ya había entrado antes de que la cerraras, ese alguien sigue dentro. Se ha creado su propio usuario, ha dejado su propio archivo, se ha hecho su propia copia de la llave.
Actualizar y quedarse tranquilo es el error más caro que puedes cometer ahora mismo.
Si tu web estuvo en una versión vulnerable expuesta a internet aunque fuera unos días, la pregunta correcta no es «¿ya estoy actualizado?». Es «¿estoy seguro de que no hay nadie dentro?». Y esa se responde revisando, no confiando.
Cuando la revisión saca algo, ya no estamos hablando de una actualización: estamos hablando de un rescate de WordPress, que es otra historia y corre mucha más prisa.
No necesitas ser técnico para hacer esta ronda.
Ve a Usuarios → Todos los usuarios y filtra por Administrador. Deberías reconocer a cada uno de ellos, uno por uno.
Es la señal número uno, porque el ataque terminaba precisamente ahí: creándose un administrador. Ojo, que a veces se camuflan con nombres creíbles: admin, support, wpuser, backup.
Ve a Plugins → Plugins instalados y revisa la lista entera, también los desactivados. Cualquier plugin que no sepas explicar qué hace ahí es sospechoso.
Se han visto plugins falsos con nombres que suenan a herramienta de seguridad legítima. Precisamente para que no te fijes.
Entra por FTP o por el gestor de archivos de tu hosting y mira dentro de wp-content/uploads. Esa carpeta es la de las imágenes y los PDF: ahí no pinta nada un archivo .php. Si lo hay, es una puerta trasera hasta que se demuestre lo contrario.
Esta requiere entrar en los registros de acceso de tu hosting (casi todos los paneles los tienen). Busca peticiones a /wp-json/batch/v1 o a ?rest_route=/batch/v1.
Si aparecen y encima respondieron con un código 207, mal asunto: es el indicador más fiable de que el ataque funcionó. Otra pista clara: peticiones con el texto wp2shell en el identificador del navegador.
Ábrela desde el móvil, con los datos, sin estar conectado a tu wifi y sin haber iniciado sesión. Muchos ataques solo redirigen a los visitantes de fuera, precisamente para que el dueño no lo note.
Búscate también en Google con site:tudominio.com y mira si aparecen páginas que tú no has publicado.
Un correo de Google Search Console, un aviso de tu hosting, un cliente que te dice que le sale una alerta al entrar, el navegador marcando tu web en rojo.
Y hay uno que casi nadie espera: el INCIBE-CERT te escribe. El Instituto Nacional de Ciberseguridad rastrea webs españolas vulnerables y avisa por correo, gratis y sin que se lo pidas, desde [email protected]. Es exactamente el correo que me llegó a mí.
Búscalo en tu bandeja, y mira también en spam. Mucha gente lo borra pensando que es phishing — precisamente porque no se cree que un organismo público le vaya a escribir de noche por su web. Si lo tienes ahí sin abrir, ábrelo.
Si ha llegado algo de esto, no es un falso positivo. Es tarde, pero aún se arregla.
Cada hora cuenta, y un movimiento en falso borra el rastro de por dónde entraron. La mayoría de casos se resuelven en 24-48 h.
Aquí es donde mucha gente se equivoca por ir rápido.
Sin esa fecha vas a ciegas. Si restauras una copia posterior a la intrusión, restauras también la puerta trasera y encima pierdes lo que hayas publicado desde entonces. La pista está en los logs de acceso y en la fecha de modificación de los archivos raros que hayas encontrado.
A partir de ahí, todo depende de una sola pregunta: ¿tienes una copia de seguridad anterior a esa fecha?
Es el escenario bueno. Rápido, barato y con garantías. Pero el orden no es negociable:
wp-config.php. Este detalle se lo salta casi todo el mundo: al restaurar vuelven también las claves antiguas, y con ellas las sesiones que el atacante dejara abiertas siguen siendo válidas.
Y este caso es más habitual de lo que parece. No hay copias. Las que hay están en el mismo servidor infectado. O sí las hay, pero desde entonces han entrado treinta pedidos y quinientos formularios, y volver atrás dos semanas cuesta más que el propio ataque.
Aquí restaurar no es una opción, y toca lo otro: limpieza quirúrgica. Encontrar y quitar exactamente lo que dejaron, sin romper la web y sin perder nada por el camino. Es más lento, requiere saber qué se está mirando y no se improvisa un domingo por la noche — pero se hace, y en la mayoría de casos sin tocar el diseño ni el contenido.
Si estás en este camino, es literalmente en lo que consiste un rescate de WordPress.
WordPress hizo su trabajo. El fallo se publicó de forma responsable, el parche salió el mismo día y se forzaron actualizaciones automáticas. Difícilmente se puede pedir más.
El problema fue otro: entre que sale el parche y llega a tu web hay un hueco. Y el tamaño de ese hueco no lo decide WordPress. Lo decides tú, según quién esté mirando.
En las webs que reviso cada semana, ese hueco fueron horas. En una web que nadie toca desde que se publicó, ese hueco puede ser eterno.
Habrá otro wp2shell. No sé cuándo ni cómo se llamará, pero lo habrá — el software funciona así. Lo único que puedes decidir de antemano es en qué grupo quieres estar cuando llegue.
Voy a ser claro, que es como me gusta: no te cuento esto para meterte miedo. Te lo cuento porque me pasé un jueves de julio arreglando webs, y la diferencia entre las que costaron veinte minutos y las que costaron dos días no fue la suerte. Fue que alguien estaba mirando.
Si has llegado hasta aquí, ya sabes más sobre wp2shell que el 95 % de la gente que tiene un WordPress. Ahora toca decidir en qué grupo quieres estar la próxima vez.
⚡ Sin compromiso. Respuesta en menos de 48h.
Si las actualizaciones automáticas estaban activas, es muy probable que ya estés parcheado. Pero compruébalo igualmente: mira la versión en tu escritorio. Y recuerda que estar parcheado hoy no significa que no entraran antes de que se aplicara el parche.
No, y esta es la trampa. Una web comprometida sigue funcionando con normalidad — al atacante le interesa precisamente eso, que no te des cuenta. Que la web cargue bien no dice absolutamente nada sobre si hay alguien dentro.
Ayuda, pero no es una vacuna. El fallo estaba en el núcleo de WordPress, no en algo que un firewall detecte fácilmente. Algunos plugins bloquearon parte de los intentos; ninguno lo cerraba del todo. Lo único que cerraba el agujero era actualizar.
Desde que actualizaste a una versión afectada (finales de 2025 en adelante) hasta que aplicaste el parche. La explotación masiva empezó alrededor del 20 de julio de 2026, así que la ventana de riesgo real va desde esa fecha hasta el momento en que actualizaste.
Casi nunca. En la mayoría de casos se limpia, se verifica y se refuerza sin tocar el diseño ni el contenido. Rehacerla desde cero suele ser la salida de quien no sabe encontrar la puerta trasera.
La ronda de las 6 señales, sí, y deberías hacerla. Si encuentras algo raro, ahí es donde conviene parar y llamar a alguien: cada hora cuenta y un movimiento en falso puede borrar el rastro.
