WordPress
6 artículos con esta etiqueta
Fallo de WordPress 7.1.4 CVE-2026-119977: se corrige una condición de carrera en la actualización del núcleo que puede llevar a la ejecución remota de código; compruebe su versión y las actualizaciones automáticas
El 28 de octubre de 2026, el proyecto WordPress publicó la versión de seguridad 7.1.4, que corrige un fallo en el proceso de actualización del núcleo que puede llevar a la ejecución remota de código. Según el aviso de seguridad de WordPress en GitHub, durante una actualización del núcleo con un paquete completo, WordPress extraía los archivos nuevos en un directorio predecible dentro de la carpeta de actualización accesible desde la web, y un atacante sin autenticar que gane una carrera contra esa extracción podría lograr la ejecución remota de código (RCE). La corrección llega en 7.1.4 y se ha retroportado a todas las ramas hasta la 4.7 (7.0.8, 6.9.11, 6.8.12, etc.). Wordfence, como CNA, publicó CVE-2026-119977 el 31 de octubre, con una puntuación CVSS v3.1 de 8,1 (alta) y complejidad de ataque alta; el aviso de WordPress la califica como baja y no da puntuación. Según SecurityWeek, un proveedor de seguridad para WordPress vio la primera coincidencia de su nueva regla de firewall nueve minutos después de desplegarla y registró más de 18.500 peticiones dirigidas a ubicaciones temporales de actualización en las primeras 21 horas; el proveedor no ha informado de ningún compromiso exitoso. CISA añadió el CVE a su catálogo Known Exploited Vulnerabilities (KEV) el 3 de noviembre (la ficha de KEV da a las agencias federales de EE. UU. como fecha límite el 6 de noviembre, y CISA les exige, además de parchear, un triaje forense según BOD 26-04). Los sitios con actualizaciones automáticas en segundo plano deberían actualizarse solos; los que las tienen desactivadas deben actualizar manualmente desde la pantalla Actualizaciones. La conclusión de este sitio: trátelo como explotado, actualice hoy y, si su actualización fue tardía, compruebe si hay señales de compromiso (consejo de este sitio).
[Última hora] Los fallos de PHP CVE-2026-109618 y CVE-2026-109619 ya se están explotando y CISA los añade a su catálogo KEV: actualice ya a 8.5.12, 8.4.27, 8.3.36 u 8.2.35
El 21 de octubre de 2026, el equipo de seguridad de PHP publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos vulnerabilidades críticas que pueden permitir la ejecución remota de código (RCE) sin autenticación, e instó a todos los usuarios a actualizar de inmediato. CVE-2026-109618 se relaciona con la gestión de memoria agotada y CVE-2026-109619 con un estado interno obsoleto que sobrevive entre peticiones; ambas tienen una puntuación de 9,2 según CVSS v4.0. Todas las instalaciones de PHP que atienden peticiones web están en riesgo (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). El equipo considera que mod_php es el de mayor riesgo, citando un exploit demostrado en el que una petición sin autenticar activa el ataque antes de que se ejecute cualquier código de la aplicación. PHP 8.1 y versiones anteriores no reciben actualización oficial; el equipo proporcionó backports mínimos del código fuente para 7.4, 8.0 y 8.1. Las distribuciones Linux recibieron los parches con antelación. No existe una mitigación completa; actualizar es la única opción segura. El 22 de octubre, IPA y JPCERT/CC de Japón emitieron alertas y JVN publicó JVNVU#99905564. CISA, que no había observado explotación cuando publicó por primera vez su alerta, añadió ambos fallos a su catálogo Known Exploited Vulnerabilities (KEV) el 26 de octubre, con un plazo hasta el 29 de octubre para las agencias civiles federales de EE. UU. Según informes de medios, los honeypots de un investigador de seguridad con PHP 8.4.26 sin parchear bajo mod_php registraron una ejecución remota de código exitosa el 24 de octubre. Los honeypots de un importante proveedor de nube ya habían registrado intentos de explotación desde el 17 de octubre, cuatro días antes de la divulgación. Hasta donde este sitio ha podido comprobar, a fecha del 27 de octubre no se había hecho pública ninguna intrusión fuera de honeypots. La mayoría de los principales proveedores japoneses de hosting compartido han anunciado que la corrección está aplicada, pero algunos, como KAGOYA, no. El 23 de octubre, el equipo de PHP divulgó una tercera incidencia (CVE-2026-115560) que las versiones del 21 de octubre no corrigen. Solo puede llevar a la ejecución de código con una combinación específica de configuración y código de aplicación; el equipo la considera improbable en la práctica, incluirá la corrección y un aviso completo en la próxima versión regular y recomienda establecer session.upload_progress.enabled=0 hasta entonces. No se han publicado las versiones afectadas ni una puntuación CVSS, y no se ha informado de explotación. A fecha del 29 de octubre (comprobado en php.net) no había ninguna versión que corrigiera esta incidencia. El 28 de octubre, CISA añadió también a KEV el fallo del kernel de Linux CVE-2026-46300 (plazo el 31 de octubre para las agencias federales de EE. UU.) y dijo que puede encadenarse con estos dos fallos para implantar webshells de PHP y ejecutar comandos como root. La postura de este sitio: la explotación ya está confirmada, así que confirme si usted o su proveedor actualizan PHP en cada sitio y pase a la versión corregida hoy. Revise también los registros desde el 17 de octubre en adelante en busca de señales de intrusión. En hosting compartido, consulte el aviso de finalización de su proveedor en su sitio web oficial.
Rank Math PRO 3.0.123 con malware (octubre de 2026): quién está afectado y qué deben hacer los propietarios de sitios WordPress
El 16 de octubre de 2026 (UTC), Rank Math anunció que Rank Math PRO v3.0.123, la versión de pago de su plugin para WordPress, contenía malware para un número limitado de usuarios que lo descargaron entre las 20:02 UTC del 15 de octubre y las 07:12 UTC del 16 de octubre. El malware podía comprometer un sitio si el plugin se activaba, y podía recrear su puerta trasera oculta cada vez que se visitara el sitio. La empresa eliminó los archivos afectados y publicó una v3.0.124 limpia. La versión gratuita distribuida en WordPress.org no está afectada. No se ha revelado ni el número de usuarios afectados ni cómo llegó el malware a los archivos. Al 20 de octubre, la última modificación del aviso fue el 19 de octubre, cuando se añadió una nota indicando que la versión gratuita no está afectada. Conclusión de este sitio: considere comprometido cualquier sitio que haya activado una copia de la 3.0.123 obtenida durante el periodo afectado, y restaure desde una copia de seguridad anterior a ese periodo o elimine la carpeta completa del plugin y limpie siguiendo el orden que indica la empresa. En cualquier caso, cambie todas las credenciales que el sitio pudiera leer.
Acceso no autorizado a algunos servidores web de ConoHa WING (GMO Internet) (426 cuentas): datos en las áreas de servidor web de los clientes afectados y qué deben hacer hoy los propietarios de sitios
El 20 de septiembre de 2026, GMO Internet, Inc. anunció que, en algunos servidores de alojamiento (servidores web) de su servicio de alojamiento de pago ConoHa WING, un tercero obtuvo acceso no autorizado a las áreas de servidor web de algunos clientes e instaló un programa malicioso. Están afectadas 426 cuentas, y los datos concernidos son «datos almacenados en las áreas de servidor web de los clientes». El acceso y la instalación comenzaron el 3 de septiembre; la empresa lo detectó el 16 de septiembre y, el 18 de septiembre, identificó la causa y el alcance y eliminó los programas. Afirma haber identificado la causa, pero no la ha revelado. Según la empresa, los datos de miembros, contratos y pagos se gestionan en un entorno separado y no se filtraron. El aviso no indica si se extrajeron datos de las áreas de servidor web. Los clientes afectados fueron contactados individualmente en la dirección de correo electrónico registrada; los clientes que no fueron contactados no están afectados. No había un aviso de seguimiento a 15 de octubre. La opinión de este sitio: primero compruebe si recibió un correo individual y, en ese caso, siga sus instrucciones. Después, considere que las credenciales guardadas en su área de servidor web (la contraseña de la base de datos en wp-config.php, las claves de API en .env, etc.) pueden haber sido leídas y cámbielas, y busque archivos, administradores y tareas programadas añadidos desde el 3 de septiembre.
Cómo saber si han hackeado tu sitio web o tu servidor: comprobaciones paso a paso para hosting compartido, WordPress y un VPS, y qué hacer primero si encuentras algo
Revisar un sitio en busca de intrusiones significa mirar tanto las señales visibles desde fuera como los rastros que quedan dentro. Señales: el informe de problemas de seguridad de Search Console, una etiqueta 'This site may be hacked' en los resultados de búsqueda, un aviso de tu hosting, administradores desconocidos, redirecciones que solo ocurren en el móvil o al llegar desde el buscador. Rastros: usuarios administradores, archivos del núcleo modificados (wp core verify-checksums), historial de inicios de sesión, authorized_keys, cron, puertos a la escucha, archivos cambiados recientemente. La opinión de este sitio: no encontrar nada no demuestra que estés limpio. Si encuentras algo, conserva las pruebas antes de limpiar, cambia todas las credenciales desde un dispositivo limpio, restaura una copia anterior a la intrusión o reconstruye, cierra la vía de entrada y solo entonces solicita una revisión.
Seguridad de WordPress — una referencia de endurecimiento para producción
WordPress tiene la mayor cuota, así que es el mayor objetivo, pero las vías de entrada son predecibles (vulnerabilidades de complementos/temas, actualizaciones omitidas, administradores débiles, paneles de administración expuestos). Esta es una referencia de trabajo: (1) una lista de verificación de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — actualizaciones automáticas, minimizar complementos/temas, administrador fuerte + 2FA, reducir la exposición del panel (xmlrpc/enumeración REST/edición de archivos), wp-config y secretos, permisos de archivos, HTTPS/copias de seguridad, actualización de PHP/dependencias, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.