SERVER PLUS INSIGHTS
Alerta PHP2Shell: PHP anuncia correcciones CVSS 9.2; las empresas deben inventariar sus sistemas
Las empresas con sitios web, tiendas o sistemas internos basados en PHP deben identificar ya a los responsables y los procedimientos de actualización. PHP ha anunciado correcciones para dos vulnerabilidades críticas CVSS v4.0 9.2. Server Plus recomienda priorizar los activos expuestos y actualizar y verificar cuanto antes al confirmarse las versiones corregidas.
2026-10-21 · Server Plus
PHP prevé una actualización crítica el 21 de octubre de 2026 a las 22:00 de Taiwán. Server Plus resume PHP2Shell, CVE-2026-109618/109619 y los pasos de inventario, actualización, aislamiento y verificación.
Estado: publicación prevista para el 21 de octubre a las 22:00 de Taiwán
Esta alerta previa a la publicación refleja los anuncios disponibles hasta el mediodía del 21 de octubre de 2026 en Taiwán. Es una guía de preparación, no un procedimiento de reparación específico ya verificado. PHP ha anunciado dos correcciones críticas, ambas CVSS v4.0 9.2. La publicación podría adelantarse si se revelan detalles o aparecen pruebas de explotación activa.
- Hora prevista: 21 de octubre de 2026 a las 14:00 UTC, 22:00 en Taiwán.
- Identificadores relacionados: CVE-2026-109618 y CVE-2026-109619, recogidos por CERT-EU y Sansec.
- Confirmar al publicarse: versiones afectadas, condiciones de explotación y compilaciones corregidas en los avisos de PHP y del proveedor de paquetes.
Qué es PHP2Shell: separar las alertas de investigación de la confirmación oficial
Sansec informa de una filtración relacionada con una herramienta llamada PHP2Shell y vincula las vulnerabilidades con ejecución remota de código (RCE). Su informe sitúa el alcance desde PHP 5.4 y prevé ataques masivos en los 15 minutos posteriores a la publicación. Es una evaluación de riesgo del investigador, no un calendario confirmado de ataques ni una demostración de que toda instalación de PHP sea explotable.
Los equipos de Magento, Shopware, WooCommerce y otros sitios PHP deben inventariar también el entorno de ejecución, no solo el CMS o los complementos. Actualizar una aplicación no implica haber corregido PHP. El alcance definitivo debe contrastarse con el aviso oficial de seguridad.
Antes de la publicación: identificar los sistemas que requieren actualización
Server Plus recomienda que desarrollo, operaciones y alojamiento confirmen ahora lo siguiente, para no descubrir responsables ausentes o procesos de despliegue inservibles cuando lleguen las correcciones.
- Inventariar PHP en producción, pruebas, API, tareas programadas y contenedores. Registrar versiones, origen de instalación y responsables.
- Revisar por separado PHP de línea de comandos, PHP-FPM y Apache mod_php. php -v muestra el entorno CLI actual, que puede ser distinto del utilizado por el sitio.
- Preparar copias de datos, configuración y versiones desplegadas, y definir pruebas de acceso, pago, carga de archivos y tareas programadas.
- Consultar al proveedor de alojamiento, panel o distribución Linux sobre paquetes de seguridad, imágenes y plazos de despliegue. Vigilar los avisos antes de la hora prevista.
Después: comprobar que los servicios cargan realmente el entorno corregido
Esta es una lista de verificación operativa, no un comando universal de actualización. La ejecución depende del origen de los paquetes, la arquitectura y las indicaciones del proveedor.
- Confirmar que el aviso cubre ambos CVE e instalar la compilación corregida o el paquete con la corrección adaptada por el proveedor. No juzgar únicamente por el número de versión.
- Actualizar desde repositorios fiables o fuentes oficiales. En contenedores, actualizar imágenes y volver a desplegar; cambiar solo PHP en el anfitrión no basta.
- Recargar o reiniciar PHP-FPM, Apache con mod_php o los contenedores pertinentes, y comprobar que finalizaron los procesos PHP antiguos. Reiniciar Nginx solo si los cambios de configuración lo requieren.
- Verificar versión y estado de corrección en el entorno web real y probar las transacciones críticas. Restringir el acceso a diagnósticos; no publicar phpinfo() en Internet.
- Vigilar registros de errores, procesos anómalos, archivos web y accesos. Ante indicios de intrusión, preservar pruebas e iniciar respuesta a incidentes: aplicar un parche no elimina una intrusión existente.
Versiones antiguas o sin actualización inmediata: reducir la exposición y migrar
PHP mantiene actualmente las ramas 8.2, 8.3, 8.4 y 8.5; 8.1 y anteriores están fuera del soporte upstream. Quienes usen distribuciones Linux o mantenimiento comercial ampliado deben confirmar si el proveedor adaptará estas correcciones, sin depender solo de la versión principal. El soporte de seguridad de PHP 8.2 termina a finales de 2026, otro factor a considerar al migrar.
CERT-EU aconseja evaluar el aislamiento de aplicaciones públicas respecto de Internet cuando no sea posible corregir de inmediato. Server Plus recomienda desactivar entradas innecesarias o limitar el acceso mediante controles verificados según las necesidades del negocio.
- WAF, restricciones de IP de origen y aislamiento son controles por capas. Hasta conocer completamente las condiciones de explotación, no afirmar que reglas WAF genéricas bloquean íntegramente estas vulnerabilidades.
- No considerar disable_functions de php.ini ni la desactivación de funciones concretas como una corrección verificada. Seguir las mitigaciones oficiales y completar la respuesta con actualizaciones de eficacia confirmada.
Registrar inventario, corrección y nuevas pruebas de forma trazable
Registrar activos afectados, paquetes antes y después, fechas de despliegue, resultados de verificación y pendientes. El escaneo ayuda a gestionar la exposición externa, pero la ausencia de hallazgos no descarta una vulnerabilidad nueva. Comprobar cobertura de reglas y pruebas de corrección en el servidor.
Contacte con Server Plus para escaneo de sitios e IP externas, priorización de correcciones o planificación de infraestructura. REDMARK también puede apoyar la gestión continua. Este artículo no afirma que algún escáner ya disponga de detección específica de PHP2Shell.
FAQ
¿Basta con actualizar WordPress, WooCommerce o complementos?
No. Actualizar aplicaciones no siempre actualiza PHP. Operaciones o el proveedor deben verificar el entorno web real y su estado de corrección.
¿PHP 8.2 o posterior es automáticamente seguro?
No. Estar en una rama soportada no significa tener estas correcciones. Compruebe avisos oficiales, paquetes del proveedor y procesos en ejecución.
¿Puedo omitir la actualización si el escáner no detecta nada?
No. Las reglas para vulnerabilidades nuevas pueden no estar disponibles y un escaneo externo no siempre confirma todas las condiciones. Utilice los avisos oficiales y las pruebas de corrección del servidor.