Por Canuto  

WordPress publicó el 28 de octubre la versión 7.1.4, que corrige 22 vulnerabilidades, y distribuyó actualizaciones para ramas anteriores del CMS. Wordfence reportó intentos de explotar una falla que podía permitir la ejecución de código durante una actualización. Los administradores deben actualizar sus sitios y revisar posibles señales de intrusión.

***

  • WordPress publicó la versión 7.1.4 el 28 de octubre; la actualización corrige 22 vulnerabilidades y hay parches retroportados para ramas anteriores del CMS.
  • Wordfence registró más de 18.500 solicitudes en las primeras 21 horas de una regla de firewall dirigida al fallo.
  • La vulnerabilidad afecta una ruta temporal predecible durante ciertas actualizaciones; se recomienda buscar archivos y cuentas inesperados.

 


Un fallo en el proceso de actualización del núcleo de WordPress podía permitir que atacantes sin autenticación inyectaran y ejecutaran código malicioso mientras una instalación se actualizaba. WordPress publicó el 28 de octubre la versión 7.1.4, que corrige 22 vulnerabilidades, y también preparó parches para ramas anteriores. Wordfence informó que sus sistemas registraban intentos de explotación contra esta falla.

La advertencia se dirige a quienes administran sitios y mantienen instancias de WordPress en sus redes: deben comprobar que sus instalaciones cuentan con las versiones corregidas y aplicar la actualización si todavía no lo hicieron. WordPress 7.1.4 es una actualización de seguridad; también se distribuyeron correcciones para numerosas ramas anteriores del sistema.

La vulnerabilidad más urgente surge de una ruta predecible que queda accesible desde internet durante ciertas actualizaciones del núcleo. Según la información divulgada, una persona atacante no necesita autenticarse para intentar aprovecharla, aunque debe actuar mientras el proceso de actualización está en curso y antes de que las rutinas de limpieza retiren los archivos temporales.

El riesgo depende de una carrera contra el procedimiento de instalación, por lo que la ventana disponible puede parecer breve. En pruebas de laboratorio, investigadores observaron que el directorio de preparación permanecía accesible apenas unos segundos; aun así, Wordfence señaló que la corta duración no impidió que aparecieran intentos activos contra sitios reales.

La falla no tenía un identificador CVE disponible cuando se difundió la alerta y recibió una puntuación CVSS de 8,1, clasificada como de riesgo alto. Esa evaluación describe la gravedad técnica reportada, pero no significa que todos los sitios de WordPress estén comprometidos: la condición relevante es que la instalación esté ejecutando una actualización vulnerable y que un atacante consiga actuar durante ese intervalo.

Wordfence informó que, durante las primeras 21 horas desde que incorporó una regla de firewall para detectar el problema, sus sistemas de telemetría contabilizaron más de 18.500 solicitudes dirigidas a rutas vulnerables de setup-config.php. La empresa, especializada en seguridad del ecosistema WordPress, describió ese volumen como evidencia de que distintos actores estaban buscando instalaciones susceptibles, no como confirmación de que cada solicitud hubiera logrado entrar.

Entre las fuentes más activas, dos consultaron repetidamente grupos pequeños de sitios de WordPress durante unas 14,5 horas. Otras fuentes cambiaron las rutas de preparación y los nombres de las versiones solicitadas, un comportamiento que muestra intentos variados de localizar el punto vulnerable, aunque la información publicada no atribuye esas solicitudes a actores identificados ni precisa cuántas tuvieron éxito.

El mecanismo de actualización automática ayuda a explicar por qué la ruta puede existir en instalaciones normales: WordPress comprueba si hay actualizaciones, las descarga y las instala automáticamente de forma predeterminada. Sin embargo, el fallo descrito solo afecta a una actualización que utilice el paquete completo del núcleo; durante ese proceso, WordPress descomprime el paquete en una ubicación predecible bajo wp-content/upgrade.

Ese detalle distingue la vulnerabilidad de un fallo que estuviera expuesto de manera permanente en cualquier página del sitio. El directorio temporal aparece como parte de una operación de actualización concreta y, según los investigadores citados, puede estar disponible por muy poco tiempo; aun así, la posibilidad de que un tercero intente aprovecharlo desde internet justifica instalar los parches sin demora.

La actualización principal es WordPress 7.1.4, publicada el 28 de octubre y descrita por Wordfence como una versión que corrige 22 vulnerabilidades. El arreglo también llegó a versiones anteriores mediante retroportaciones, es decir, correcciones incorporadas a ramas previas del software. La lista publicada incluye las versiones 4.7.39, 4.8.34, 4.9.35, 5.0.31, 5.1.28, 5.2.30, 5.3.27, 5.4.25, 5.5.24 y 5.6.23.

También aparecen las versiones 5.7.21, 5.8.19, 5.9.20, 6.0.18, 6.1.16, 6.2.15, 6.3.14, 6.4.14, 6.5.14 y 6.6.11. La lista continúa con 6.7.11, 6.8.12, 6.9.11, 7.0.8 y 7.1.4, por lo que los administradores deben identificar la rama de su instalación y verificar que haya recibido la versión correspondiente.

Actualizar es la primera medida recomendada, pero quienes todavía no habían instalado el parche también deberían investigar si hubo actividad sospechosa en sus sitios. Wordfence aconseja revisar los registros de acceso y buscar archivos PHP inesperados dentro de wp-content/upgrade, así como cuentas de administrador desconocidas o complementos y archivos PHP que el equipo encargado del sitio no haya instalado.

Esas señales, por sí solas, no demuestran que el fallo haya sido explotado, pero pueden ayudar a detectar cambios que requieren una revisión más profunda. La recomendación de inspeccionar los registros cobra especial importancia cuando una instalación permaneció sin actualizar durante el periodo en que se observaron solicitudes dirigidas a las rutas vulnerables.

El aviso recuerda otro episodio reciente: WordPress corrigió una vulnerabilidad de seguridad a finales de septiembre y, de acuerdo con la información reportada, también se registraron ataques en línea pocas horas después de la publicación de la solución. El antecedente no establece una relación entre ambos fallos, pero sí subraya la importancia de aplicar los parches y comprobar el estado de los sitios tras un aviso de seguridad.

La publicación de una actualización reduce la exposición conocida, pero no sustituye la verificación de que el software realmente se instaló ni la búsqueda de indicios de acceso no autorizado. Para los administradores, las acciones inmediatas son confirmar la versión, completar la actualización pendiente y revisar rutas, cuentas y archivos que no reconozcan.


Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público

Este artículo fue escrito por un redactor de contenido de IA




ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín