Que una página abra correctamente no demuestra que su servidor esté protegido. Una tienda, un portal de clientes o una aplicación interna pueden continuar operando mientras mantienen pendiente una actualización crítica.
Ese es el motivo para atender los avisos recientes de PHP con una comprobación técnica, incluso cuando los usuarios no reportan fallas.
El hecho: dos vulnerabilidades críticas en PHP
El 21 de octubre, PHP publicó correcciones para CVE-2026-109618 y CVE-2026-109619, fallas que pueden permitir ejecutar código remotamente sin autenticación.
Las versiones correctivas anunciadas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El equipo de PHP incluye en el alcance instalaciones que atienden solicitudes web y señala un riesgo especialmente elevado para Apache con mod_php.
Los avisos describen problemas de manejo de memoria y estado interno entre solicitudes. Aviso sobre CVE-2026-109618 · Aviso sobre CVE-2026-109619.
Actualización del 23 de octubre: revisar también las sesiones
PHP recomienda desactivar temporalmente session.upload_progress.enabled hasta la siguiente versión de correcciones para cubrir una vía adicional de ejecución remota, identificada como CVE-2026-115560.
Este escenario requiere una combinación poco habitual de configuración y cambios del manejador de serialización durante la ejecución. Las aplicaciones que nunca realizan esos cambios pueden mantener la función habilitada, según el aviso. Consultar las advertencias oficiales de PHP del 21 y 23 de octubre.
¿Por dónde debe comenzar una empresa?
Recomendamos pedir al responsable del alojamiento o de infraestructura una respuesta verificable:
¿Qué versión y paquete de PHP atienden realmente cada aplicación, y qué evidencia confirma que incorporan las correcciones?
Conviene revisar sitios públicos, subdominios, aplicaciones internas y ambientes de pruebas accesibles. El inventario debe identificar también al responsable de cada servicio.
Cuando el proveedor utiliza paquetes con parches incorporados sin cambiar al número de versión original del proyecto, hay que solicitar su aviso de seguridad o identificación del paquete corregido.
Actualizar con control y comprobar el resultado
Desde G-BIZ proponemos organizar la respuesta en cinco pasos:
- Identificar aplicaciones, servidores y proveedores implicados.
- Preparar respaldo y recuperación antes del cambio.
- Aplicar la actualización y las medidas pertinentes del aviso oficial.
- Comprobar formularios, autenticación, cargas de archivos y procesos críticos.
- Registrar versión efectiva, reinicios requeridos y evidencia de validación.
La comprobación debe incluir el servicio web activo: una versión mostrada por otra herramienta del servidor puede corresponder a una instalación diferente.
Perspectiva G-BIZ
Cerrar una vulnerabilidad exige confirmar que el activo recibió la corrección y que el servicio sigue funcionando. Si aparecen indicios de compromiso, recomendamos atenderlos mediante un proceso de respuesta a incidentes; actualizar por sí solo no demuestra que el entorno esté limpio.
¿Tu proveedor ya confirmó la corrección o solamente informó que “el sitio funciona”? Habla con G-BIZ sobre la revisión de tu entorno.
Fuentes originales
Información verificada el 23 de octubre de 2026.