Actualización informativa: 21 de octubre de 2026, 14:30 horas de Santiago de Chile (UTC−3).
PHP publicó hoy actualizaciones de seguridad para cuatro ramas: 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Para las empresas que operan sitios, comercio electrónico o aplicaciones sobre esta tecnología, corresponde identificar los entornos utilizados y coordinar una actualización prioritaria. Anuncios oficiales de PHP.
La tarea requiere coordinación entre tecnología, seguridad, proveedores y responsables del negocio. Actualizar un componente sin confirmar dónde está funcionando puede dejar sistemas pendientes; cambiarlo sin pruebas puede afectar la operación. Esta guía propone un recorrido para pasar de la alerta a un cierre verificable.
Qué se informó
El aviso de CVE-2026-109618 describe corrupción de memoria asociada al agotamiento de memoria y posible ejecución remota de código sin autenticación. Está clasificado como crítico, con puntuación CVSS 4.0 de 9,2. La viabilidad de explotación depende del entorno. Aviso oficial de PHP.
CVE-2026-109619 afecta al manejo de estado entre solicitudes y también puede permitir ejecución remota de código. Su clasificación es crítica, con CVSS 4.0 de 9,2. El aviso pide aplicar la corrección completa y considerar conjuntamente ambos problemas. Segundo aviso oficial.
Estos hallazgos no prueban que una empresa determinada haya sido comprometida. La revisión de exposición y la búsqueda de incidentes requieren evidencia de sus propios sistemas.
Versiones corregidas por rama
| Rama PHP | Versión corregida publicada |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
La tabla recoge las versiones señaladas en los avisos de seguridad de PHP. No es una recomendación de migrar todas las aplicaciones a otra rama sin evaluar compatibilidad.
Si utilizas paquetes de una distribución o un servicio administrado, solicita el boletín del proveedor y la identificación del paquete corregido. Puede existir un parche incorporado por el distribuidor, conocido como backport, sin que el número visible coincida exactamente con la versión original de PHP. Esa condición debe quedar documentada, no asumirse.
Si tu empresa utiliza PHP 8.1 o anterior, la actualización requiere atención adicional: esas ramas están fuera del soporte normal del proyecto. Solicita evidencia de cualquier corrección del proveedor y define una migración a una rama soportada. Estado indicado por PHP.
Revisa más que WordPress
Una revisión limitada al panel de plugins resulta insuficiente para comprobar el estado de PHP. El inventario debería incluir el sitio principal, subdominios, aplicaciones internas, entornos de prueba accesibles, hosting administrado, servidores y contenedores.
Para cada servicio, registra quién lo administra, qué versión ejecuta, cómo recibe actualizaciones y qué proceso de negocio depende de él. Incluye las imágenes utilizadas en nuevos despliegues: corregir una instancia actual no debe permitir que el próximo despliegue vuelva a introducir una imagen pendiente de actualización.
La comprobación debe identificar el runtime que realmente atiende las solicitudes web. Consultar únicamente la versión disponible en una terminal no basta para acreditar qué proceso utiliza cada sitio. Evita publicar páginas de diagnóstico que expongan configuración; conserva la evidencia en los canales internos autorizados.
Checklist para el equipo y el proveedor de hosting
- Responsable de tecnología: consolidar el inventario y asignar un dueño por servicio. Identificar primero los sistemas expuestos y los procesos más sensibles para el negocio.
- Proveedor o administrador: confirmar el paquete que incorpora ambas correcciones, los entornos incluidos y la ventana de implementación. Pedir una respuesta específica por servicio, no solamente “plataforma actualizada”.
- Equipo de aplicaciones: comprobar compatibilidad y ejecutar pruebas de acceso, navegación, compra o transacciones, integraciones y tareas programadas que correspondan al sistema.
- Operaciones: disponer de respaldo comprobado y procedimiento de recuperación. Definir quién decide detener o revertir un cambio si aparecen errores.
- Seguridad: registrar las excepciones, su responsable y el siguiente paso. Cualquier medida temporal necesita evaluación técnica; no debe presentarse como equivalente al parche completo.
- Responsable del cambio: verificar el runtime activo después del despliegue, conservar evidencia y obtener la validación funcional del negocio.
Cuándo considerar cerrado el trabajo
El cierre debería reunir inventario actualizado, versión o paquete corregido por servicio, resultado de pruebas y confirmación de que las instancias que atienden tráfico quedaron renovadas. Revisa también errores y comportamiento de la aplicación después del cambio.
Si una recuperación obliga a regresar a una versión vulnerable, la exposición vuelve a quedar pendiente y necesita una decisión explícita. Un respaldo protege la capacidad de recuperación; por sí solo no corrige la vulnerabilidad ni confirma ausencia de compromiso.
Para coordinar la revisión de tu entorno y sus prioridades, conoce los servicios de seguridad de NOVVOR y consulta el alcance adecuado para tu empresa.
