⚠️ Grave fallo RCE en WordPress Core: ya hay casi 63.000 intentos de ataque

Tronlar

Tronlar

Beta
Verificación en dos pasos activada
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!

⚠️ WordPress bajo ataque: casi 63.000 intentos de explotar un fallo RCE del Core en 24 horas​


Buenas,

Por si alguno tiene webs en WordPress, ojo con esto porque es bastante reciente y esta vez no estamos hablando de un plugin vulnerable, sino de un fallo en el propio WordPress Core.

WordPress publicó el pasado 28 de octubre la versión 7.1.4 como actualización de seguridad. Entre los problemas corregidos hay una vulnerabilidad en el proceso de actualización del Core que puede llegar a permitir ejecución remota de código (RCE).

Lo preocupante es que los atacantes no han tardado mucho en empezar a probarla.

Según Wordfence, en las últimas 24 horas han bloqueado 62.969 intentos de ataque relacionados con esta vulnerabilidad.


🔴 ¿Qué versiones están afectadas?​


El fallo afecta a versiones de WordPress desde la 4.7 hasta la 7.1.3.

La corrección está incluida en:

WordPress 7.1.4

WordPress también está llevando las correcciones de seguridad a ramas antiguas que todavía pueden recibirlas, aunque desde WordPress.org recuerdan que solamente la versión más reciente está soportada activamente.

Así que lo primero que haría sería entrar en vuestro WordPress y comprobar la versión.

Insertar CODE, HTML o PHP: 
Escritorio → Actualizaciones

Si tenéis pendiente WordPress 7.1.4, yo actualizaría cuanto antes.

Si tenéis activadas las actualizaciones automáticas es posible que ya se haya instalado, pero tampoco cuesta nada comprobarlo.


🧨 ¿En qué consiste el fallo?​


La vulnerabilidad es bastante curiosa porque el ataque tiene que producirse justo mientras WordPress se está actualizando.

Cuando WordPress realiza una actualización completa del Core, descomprime temporalmente archivos de la nueva versión dentro de:

Insertar CODE, HTML o PHP: 
wp-content/upgrade/

El problema es que las versiones vulnerables podían utilizar una ruta temporal predecible y, en determinados servidores, esa ubicación podía ser accesible desde Internet.

Esa copia temporal incluye también archivos del instalador de WordPress.

Un atacante sin estar autenticado puede realizar peticiones continuamente intentando acceder al instalador justo durante los pocos segundos en los que WordPress está realizando la actualización.

Si consigue acertar esa pequeña ventana y se cumplen las condiciones necesarias en el servidor, puede interactuar con esa instalación temporal y llegar a ejecutar código PHP en el servidor.

Es lo que se conoce como una race condition.

La ventana normalmente dura solamente unos segundos, pero los atacantes están intentando solucionarlo a lo bruto: realizando peticiones una y otra vez durante horas esperando coincidir con una actualización.

De hecho, Wordfence ha observado algunas fuentes atacando pequeños grupos de webs durante unas 14,5 horas seguidas.


🔎 ¿Cómo puedo comprobar si han intentado explotarlo en mi web?​


Si tenéis acceso a los logs del servidor, podéis buscar peticiones hacia:

Insertar CODE, HTML o PHP: 
/wp-content/upgrade/

Especialmente peticiones a archivos PHP dentro de esa ruta.

Uno de los archivos que están intentando localizar los atacantes es:

Insertar CODE, HTML o PHP: 
setup-config.php

Si utilizáis cPanel, Plesk o algún panel de hosting que permita consultar los logs de acceso, podéis buscar por:

Insertar CODE, HTML o PHP: 
wp-content/upgrade

o:

Insertar CODE, HTML o PHP: 
setup-config.php

Importante: que aparezcan peticiones hacia esas rutas no significa automáticamente que vuestra web haya sido hackeada.

Ahora mismo hay bots realizando este tipo de peticiones masivamente. Una petición bloqueada, un 403 o un 404 puede ser simplemente un intento fallido.

Además de los logs, Wordfence recomienda revisar si ha aparecido algo extraño en la instalación.

Yo comprobaría:
  • Usuarios administradores que no reconozcáis.
  • Plugins que no recordéis haber instalado.
  • Archivos PHP nuevos o modificados recientemente.
  • Archivos PHP sospechosos dentro de wp-content/upgrade/.
  • Cambios inesperados en archivos de WordPress.

Por ahora se están observando intentos activos de explotación, pero eso no significa que esas casi 63.000 peticiones correspondan a 63.000 webs hackeadas.

Son intentos de ataque, que es bastante diferente.


🛡️ ¿Qué hago si tengo WordPress?​


Lo principal es bastante sencillo:

Comprobar que WordPress está actualizado.

La versión 7.1.4 salió el 28 de octubre precisamente como actualización de seguridad y WordPress recomienda actualizar inmediatamente.

Además, 7.1.4 no corrige solamente este problema. La actualización incluye otras correcciones de seguridad relacionadas con XSS, divulgación de información, permisos y otros problemas del Core.

Si administráis varias webs WordPress, yo las revisaría todas porque siempre puede quedar alguna instalación antigua olvidada.

Y si alguna estuvo utilizando una versión vulnerable, echaría un vistazo a los logs buscando peticiones a wp-content/upgrade/ y revisaría administradores, plugins y archivos PHP por si hubiera algo que no debería estar ahí.


📚 Fuentes​


WordPress.org — WordPress 7.1.4

https://wordpress.org/news/2026/10/wordpress-7-1-4/

Documentación oficial de WordPress — Version 7.1.4

https://wordpress.org/documentation/wordpress-version/version-7-1-4/

WordPress España — Actualización de seguridad 7.1.4

https://es.wordpress.org/category/seguridad/

The Hacker News — WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours

https://thehackernews.com/2026/10/wordpress-rce-flaw-draws-nearly-63000.html


Esta vez no es el típico caso de un plugin abandonado o con pocas instalaciones, sino una vulnerabilidad del propio WordPress Core.

La buena noticia es que ya está corregida.

Así que si tenéis WordPress, comprobad la versión y, si todavía estáis en una versión vulnerable, actualizaría cuanto antes.

Si alguno mira sus logs y encuentra intentos contra wp-content/upgrade/ o setup-config.php, estaría interesante que comentara qué está viendo.


---------------------------------------------------------------------------------------------

⚠️ Actualización 31/10/2026: el problema sigue y ahora afecta al propio WordPress Core​


Actualizo el tema porque en los últimos días ha habido novedades importantes.

WordPress ha publicado la versión 7.1.4, una actualización de seguridad que corrige varios problemas.
Entre ellos hay uno especialmente serio en el propio proceso de actualización de WordPress que puede permitir ejecución remota de código (RCE) durante la ventana de actualización.

Es decir, esta vez no estamos hablando únicamente de un plugin vulnerable.

Además, después de publicarse el parche ya se está observando bastante actividad intentando explotar el fallo. Se han reportado decenas de miles de intentos de ataque en apenas 24 horas.

Importante: que existan miles de intentos no significa que todos esos sitios hayan sido comprometidos. Son intentos de explotación detectados/bloqueados.

¿Qué haría ahora mismo?​

  • Actualizar WordPress cuanto antes.
  • Comprobar manualmente que la actualización automática realmente se haya completado.
  • Actualizar también plugins y temas.
  • Revisar usuarios administradores que no reconozcamos.
  • Comprobar archivos modificados recientemente si tenemos sospechas de actividad extraña.
  • Tener una copia de seguridad reciente antes de realizar cambios importantes.

La versión actual publicada para la rama 7.1 es WordPress 7.1.4.

WordPress recomienda instalar esta actualización de seguridad inmediatamente.


Fuentes​

 
Última edición:
¿Te sirvió? Únete a la conversación

Con tu cuenta gratis puedes responder, escribirle al autor por mensaje privado y comprar con Saldo retenido: el pago se libera cuando recibes lo acordado.

Continuar con Google Crear cuenta con correo
Toma 30 segundos · vuelves a este tema al terminar
Gracias por el aviso. Además de actualizar a 7.1.4, yo haría una copia de seguridad antes de actualizar, comprobaría que las actualizaciones automáticas del Core estén activas y revisaría que no haya usuarios administradores o archivos raros que no reconozcas. Si usas un firewall como Wordfence, mantenlo actualizado también.
 
@JeffWuuu

Totalmente. 👍

Sobre todo revisaría usuarios administradores, archivos modificados recientemente y los logs si se tiene acceso a ellos, porque actualizar corrige la vulnerabilidad, pero no elimina una posible intrusión si ya se produjo antes de actualizar.

Y sí, copia de seguridad siempre recomendable, pero en un fallo de este tipo sin retrasar el parche.
 
Tronlar dijo:

⚠️ WordPress bajo ataque: casi 63.000 intentos de explotar un fallo RCE del Core en 24 horas​


Buenas,

Por si alguno tiene webs en WordPress, ojo con esto porque es bastante reciente y esta vez no estamos hablando de un plugin vulnerable, sino de un fallo en el propio WordPress Core.

WordPress publicó el pasado 28 de octubre la versión 7.1.4 como actualización de seguridad. Entre los problemas corregidos hay una vulnerabilidad en el proceso de actualización del Core que puede llegar a permitir ejecución remota de código (RCE).

Lo preocupante es que los atacantes no han tardado mucho en empezar a probarla.

Según Wordfence, en las últimas 24 horas han bloqueado 62.969 intentos de ataque relacionados con esta vulnerabilidad.


🔴 ¿Qué versiones están afectadas?​


El fallo afecta a versiones de WordPress desde la 4.7 hasta la 7.1.3.

La corrección está incluida en:

WordPress 7.1.4

WordPress también está llevando las correcciones de seguridad a ramas antiguas que todavía pueden recibirlas, aunque desde WordPress.org recuerdan que solamente la versión más reciente está soportada activamente.

Así que lo primero que haría sería entrar en vuestro WordPress y comprobar la versión.

Insertar CODE, HTML o PHP: 
Escritorio → Actualizaciones

Si tenéis pendiente WordPress 7.1.4, yo actualizaría cuanto antes.

Si tenéis activadas las actualizaciones automáticas es posible que ya se haya instalado, pero tampoco cuesta nada comprobarlo.


🧨 ¿En qué consiste el fallo?​


La vulnerabilidad es bastante curiosa porque el ataque tiene que producirse justo mientras WordPress se está actualizando.

Cuando WordPress realiza una actualización completa del Core, descomprime temporalmente archivos de la nueva versión dentro de:

Insertar CODE, HTML o PHP: 
wp-content/upgrade/

El problema es que las versiones vulnerables podían utilizar una ruta temporal predecible y, en determinados servidores, esa ubicación podía ser accesible desde Internet.

Esa copia temporal incluye también archivos del instalador de WordPress.

Un atacante sin estar autenticado puede realizar peticiones continuamente intentando acceder al instalador justo durante los pocos segundos en los que WordPress está realizando la actualización.

Si consigue acertar esa pequeña ventana y se cumplen las condiciones necesarias en el servidor, puede interactuar con esa instalación temporal y llegar a ejecutar código PHP en el servidor.

Es lo que se conoce como una race condition.

La ventana normalmente dura solamente unos segundos, pero los atacantes están intentando solucionarlo a lo bruto: realizando peticiones una y otra vez durante horas esperando coincidir con una actualización.

De hecho, Wordfence ha observado algunas fuentes atacando pequeños grupos de webs durante unas 14,5 horas seguidas.


🔎 ¿Cómo puedo comprobar si han intentado explotarlo en mi web?​


Si tenéis acceso a los logs del servidor, podéis buscar peticiones hacia:

Insertar CODE, HTML o PHP: 
/wp-content/upgrade/

Especialmente peticiones a archivos PHP dentro de esa ruta.

Uno de los archivos que están intentando localizar los atacantes es:

Insertar CODE, HTML o PHP: 
setup-config.php

Si utilizáis cPanel, Plesk o algún panel de hosting que permita consultar los logs de acceso, podéis buscar por:

Insertar CODE, HTML o PHP: 
wp-content/upgrade

o:

Insertar CODE, HTML o PHP: 
setup-config.php

Importante: que aparezcan peticiones hacia esas rutas no significa automáticamente que vuestra web haya sido hackeada.

Ahora mismo hay bots realizando este tipo de peticiones masivamente. Una petición bloqueada, un 403 o un 404 puede ser simplemente un intento fallido.

Además de los logs, Wordfence recomienda revisar si ha aparecido algo extraño en la instalación.

Yo comprobaría:
  • Usuarios administradores que no reconozcáis.
  • Plugins que no recordéis haber instalado.
  • Archivos PHP nuevos o modificados recientemente.
  • Archivos PHP sospechosos dentro de wp-content/upgrade/.
  • Cambios inesperados en archivos de WordPress.

Por ahora se están observando intentos activos de explotación, pero eso no significa que esas casi 63.000 peticiones correspondan a 63.000 webs hackeadas.

Son intentos de ataque, que es bastante diferente.


🛡️ ¿Qué hago si tengo WordPress?​


Lo principal es bastante sencillo:

Comprobar que WordPress está actualizado.

La versión 7.1.4 salió el 28 de octubre precisamente como actualización de seguridad y WordPress recomienda actualizar inmediatamente.

Además, 7.1.4 no corrige solamente este problema. La actualización incluye otras correcciones de seguridad relacionadas con XSS, divulgación de información, permisos y otros problemas del Core.

Si administráis varias webs WordPress, yo las revisaría todas porque siempre puede quedar alguna instalación antigua olvidada.

Y si alguna estuvo utilizando una versión vulnerable, echaría un vistazo a los logs buscando peticiones a wp-content/upgrade/ y revisaría administradores, plugins y archivos PHP por si hubiera algo que no debería estar ahí.


📚 Fuentes​


WordPress.org — WordPress 7.1.4

https://wordpress.org/news/2026/10/wordpress-7-1-4/

Documentación oficial de WordPress — Version 7.1.4

https://wordpress.org/documentation/wordpress-version/version-7-1-4/

WordPress España — Actualización de seguridad 7.1.4

https://es.wordpress.org/category/seguridad/

The Hacker News — WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours

https://thehackernews.com/2026/10/wordpress-rce-flaw-draws-nearly-63000.html


Esta vez no es el típico caso de un plugin abandonado o con pocas instalaciones, sino una vulnerabilidad del propio WordPress Core.

La buena noticia es que ya está corregida.

Así que si tenéis WordPress, comprobad la versión y, si todavía estáis en una versión vulnerable, actualizaría cuanto antes.

Si alguno mira sus logs y encuentra intentos contra wp-content/upgrade/ o setup-config.php, estaría interesante que comentara qué está viendo.
Hacer clic para expandir...
Dale mucho seguimiento, Tronlar a Wordpress te lo agradecería mucho, ya que muchos hoy en día se burlan de WordPress y más lo que usamos en WordPress. Yo que hice una comparativa para el SEO posicionamiento para ver qué CMS me duraba más en Google entre Node.js y WordPress. El ganador de esto fue WordPress y no me refiero a una web normal yo pruebo a fondo con full warez!!! Lo más difícil, a diferencia de esta gente ridícula que hace webs Node.js o WordPress u otro CMS, pero no prueban a fondo la máxima capacidad de verdad de durar en Google u otros buscadores.

WordPress, lo único malo es esto:

Lo atacan mucho, demasiado, hasta por el login, por todos los lados, comentarios, etc. Esto es un mensaje directo a los administradores o creadores de Wordpress traten de mejorar esto. Qué gran CMS facilita muchas cosas en el SEO. Yo antes criticaba a wordpress era como estos ignorantes, hasta que entendí que no es la programación o código loco si no el SEO y el tiempo que duras en Google u otros buscadores, y más si es contenido warez, lo más difícil que es lo que yo me dedico desde añales.

Por eso te digo, dale seguimiento a esto!! Ayudarás a muchos y más a este CMS que de verdad para mí es muy subestimado por parte de los sabiondos.
 
Leex dijo:
Dale mucho seguimiento, Tronlar a Wordpress te lo agradecería mucho, ya que muchos hoy en día se burlan de WordPress y más lo que usamos en WordPress. Yo que hice una comparativa para el SEO posicionamiento para ver qué CMS me duraba más en Google entre Node.js y WordPress. El ganador de esto fue WordPress y no me refiero a una web normal yo pruebo a fondo con full warez!!! Lo más difícil, a diferencia de esta gente ridícula que hace webs Node.js o WordPress u otro CMS, pero no prueban a fondo la máxima capacidad de verdad de durar en Google u otros buscadores.

WordPress, lo único malo es esto:

Lo atacan mucho, demasiado, hasta por el login, por todos los lados, comentarios, etc. Esto es un mensaje directo a los administradores o creadores de Wordpress traten de mejorar esto. Qué gran CMS facilita muchas cosas en el SEO. Yo antes criticaba a wordpress era como estos ignorantes, hasta que entendí que no es la programación o código loco si no el SEO y el tiempo que duras en Google u otros buscadores, y más si es contenido warez, lo más difícil que es lo que yo me dedico desde añales.

Por eso te digo, dale seguimiento a esto!! Ayudarás a muchos y más a este CMS que de verdad para mí es muy subestimado por parte de los sabiondos.
Hacer clic para expandir...
Actualizado con información de hoy
 
Tronlar dijo:
Totalmente. 👍

Sobre todo revisaría usuarios administradores, archivos modificados recientemente y los logs si se tiene acceso a ellos, porque actualizar corrige la vulnerabilidad, pero no elimina una posible intrusión si ya se produjo antes de actualizar.

Y sí, copia de seguridad siempre recomendable, pero en un fallo de este tipo sin retrasar el parche.

Actualizado con información de hoy
Hacer clic para expandir...
Exactamente, por ejemplo, uno de este tipo de vulnerabilidad es que usan la típica de usar un usuario root como admin, dándole pase a todos los privilegios... Saben hacerla sin que tú te des cuenta, jaja.
 
Leex dijo:
Exactamente, por ejemplo, uno de este tipo de vulnerabilidad es que usan la típica de usar un usuario root como admin, dándole pase a todos los privilegios... Saben hacerla sin que tú te des cuenta, jaja.
Hacer clic para expandir...
Si, aunque realmente el problema no es que el usuario se llame root, sino cómo han conseguido crearlo y darle privilegios de administrador.

Una vez consiguen explotar una vulnerabilidad, una de las formas de mantener el acceso puede ser crear un administrador nuevo.
Y si el atacante sabe lo que hace, puede intentar que ese usuario pase desapercibido o dejar alguna otra puerta trasera para volver a entrar aunque elimines la cuenta.

Por eso, cuando un WordPress ha sido comprometido, no basta simplemente con borrar al administrador sospechoso y cambiar la contraseña.
Hay que revisar el sitio completo, porque el usuario que ves puede ser solamente una parte del problema.
 
Tronlar dijo:
Si, aunque realmente el problema no es que el usuario se llame root, sino cómo han conseguido crearlo y darle privilegios de administrador.

Una vez consiguen explotar una vulnerabilidad, una de las formas de mantener el acceso puede ser crear un administrador nuevo.
Y si el atacante sabe lo que hace, puede intentar que ese usuario pase desapercibido o dejar alguna otra puerta trasera para volver a entrar aunque elimines la cuenta.

Por eso, cuando un WordPress ha sido comprometido, no basta simplemente con borrar al administrador sospechoso y cambiar la contraseña.
Hay que revisar el sitio completo, porque el usuario que ves puede ser solamente una parte del problema.
Hacer clic para expandir...
Por eso mismo creo que no me expliqué cómo consiguen crearlo y darle el administrador... Yo me he quedado loco jajaja.

Yo solo me reía cuando me hacían eso. Esta gente sí es insistente, pana, qué ladilla, son, jajajajajajajjaa no tienen más nada que hacer!!! seguro debe ser un gordo nerd pajuo!!! intentando tumbar paginitas webs o contratado....
 
Leex dijo:
Por eso mismo creo que no me expliqué cómo consiguen crearlo y darle el administrador... Yo me he quedado loco jajaja.

Yo solo me reía cuando me hacían eso. Esta gente sí es insistente, pana, qué ladilla, son, jajajajajajajjaa no tienen más nada que hacer!!! seguro debe ser un gordo nerd pajuo!!! intentando tumbar paginitas webs o contratado....
Hacer clic para expandir...
Ahora sí te entendido.

Y eso es lo peligroso, tú puedes estar entrando al panel con total normalidad y no notar nada raro, mientras por detrás ya han conseguido ejecutar código, tocar la base de datos o crear una cuenta con privilegios.

Y si encima te lo hacían repetidamente, ahí ya no bastaba con borrar el usuario que aparecía.
Si volvían a entrar, seguramente seguía existiendo el agujero por el que entraban o habían dejado algún otro método para recuperar el acceso.
 
Tronlar dijo:
Ahora sí te entendido.

Y eso es lo peligroso, tú puedes estar entrando al panel con total normalidad y no notar nada raro, mientras por detrás ya han conseguido ejecutar código, tocar la base de datos o crear una cuenta con privilegios.

Y si encima te lo hacían repetidamente, ahí ya no bastaba con borrar el usuario que aparecía.
Si volvían a entrar, seguramente seguía existiendo el agujero por el que entraban o habían dejado algún otro método para recuperar el acceso.
Hacer clic para expandir...
No, a mí me pasó por estar en un hosting de confianza y por contratar programadores sabandijas traidores pensando que eran panitas y vivían era sacando información... De paso que les pagaba, se vendían eso. Me pasó por flojo, por y que querer armar una revolución de programadores mientras yo les pago, mientras yo hacía mis diligencias.

Por webón, eso me pasó así esa es la palabra por confiado.
 
Leex dijo:
No, a mí me pasó por estar en un hosting de confianza y por contratar programadores sabandijas traidores pensando que eran panitas y vivían era sacando información... De paso que les pagaba, se vendían eso. Me pasó por flojo, por y que querer armar una revolución de programadores mientras yo les pago, mientras yo hacía mis diligencias.

Por webón, eso me pasó así esa es la palabra por confiado.
Hacer clic para expandir...
Jajajajaja, a mí me pasó algo parecido hace muchos años por confiar igual.

Le pasé el código de un proyecto a un programador para que me hiciera unas modificaciones porque yo no tenía tiempo, y tiempo después descubrí que había metido código malicioso por su cuenta para quedarse con información que no tenía absolutamente nada que ver con el trabajo que le había pedido.

Así que sí, entiendo perfectamente lo que dices.
Desde aquello aprendí que aunque conozcas a la persona y le estés pagando, cualquier modificación que te hagan hay que revisarla antes de ponerla en producción.

A veces estás buscando vulnerabilidades por todos lados y resulta que el agujero lo has contratado tú mismo.
 
Hay que estar conectado o registrado para responder aquí.
Atrás
Arriba