Dos vulnerabilidades críticas corregidas
El proyecto PHP publicó el 21 de octubre de 2026 las versiones de seguridad PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Corrigen CVE-2026-109618 y CVE-2026-109619, que el equipo de PHP describe como vulnerabilidades capaces de permitir ejecución remota de código sin autenticación. En términos sencillos, una solicitud de red podría hacer que un servidor ejecutara código sin necesitar una cuenta válida. PHP las califica como críticas y recomienda actualizar.
El aviso explica condiciones internas distintas para cada fallo. No reproducimos detalles de explotación. La consecuencia operativa es que el runtime PHP procesa solicitudes antes de que las protecciones de la aplicación puedan intervenir necesariamente. Un firewall de plugin o esconder errores no sustituye a un runtime corregido. PHP indica que no hay mitigaciones completas y que actualizar es la opción segura.
Comprueba el runtime que atiende la web
Una web con WordPress, WooCommerce o desarrollo propio no es automáticamente vulnerable solo por utilizar PHP. La exposición depende de la compilación, la interfaz del servidor, la configuración, los parches del proveedor y el estado del hosting. PHP incluye instalaciones web con PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed; señala mod_php como el caso de mayor riesgo. Distribuciones Linux y proveedores LTS pueden publicar parches retroportados con sus propios números de paquete.
Identifica la versión PHP que realmente utiliza la web de producción, no solo la versión de línea de comandos del ordenador de desarrollo. Los hostings WordPress gestionados suelen mostrarla en el panel o mediante soporte. Si usas hosting compartido, pregunta qué paquete está activo y si el proceso se reinició. Un proveedor puede haber aplicado un parche retroportado aunque el número upstream no haya cambiado.
Actualiza con pruebas concretas
En un entorno administrado por tu equipo, crea una copia de seguridad reciente y verifica que se puede restaurar. Instala el paquete corregido primero en staging si es posible y prueba los recorridos importantes: acceso, formularios, tareas programadas, medios, pagos, integraciones y administración. Revisa registros y procesos en segundo plano. Si hay extensiones personalizadas o dependencias antiguas, comprueba compatibilidad antes de cambiar producción.
El proveedor puede instalar la actualización de forma centralizada, pero el cliente debe confirmar que el runtime de producción está cubierto y que el sitio funciona después. No retrases durante mucho tiempo un parche por esperar un rediseño o migración. Si la compatibilidad impide actualizar, solicita al proveedor o desarrollador una solución concreta y con plazo; una medida en la aplicación no neutraliza necesariamente una vulnerabilidad del runtime.
Planifica más allá del parche inmediato
Según el proyecto PHP, PHP 8.2 llega al final de vida el 31 de diciembre de 2026. La versión 8.2.35 corrige el aviso actual, pero no amplía el soporte de esa rama. Quienes sigan en 8.2 deberían planificar pruebas de compatibilidad y pasar a una rama soportada antes de que terminen las actualizaciones de seguridad. PHP 8.1 y anteriores ya no reciben correcciones del proyecto; algunos proveedores LTS pueden ofrecer backports, algo que hay que confirmar.
Mantén un inventario sencillo de sitios, versiones PHP, responsables y vías de actualización. Así será más fácil responder al siguiente aviso. Ahora hay que confirmar el runtime y el estado de los parches con quien opera el hosting y probar la web. El aviso no demuestra que exista una intrusión, y usar WordPress no demuestra por sí solo que el sitio esté expuesto o protegido.
Fuentes y lecturas adicionales
¿Quieres señalar un error factual o sugerir una fuente? Contactar con la redacción.
