PHP publicó versiones corregidas para las ramas soportadas. Los paquetes de distribuciones y hosting pueden incluir backports con una numeración distinta; confirmá el advisory del proveedor antes de concluir que una instalación sigue vulnerable.
Qué anunció PHP y cuál es el impacto
El 21 de octubre de 2026, el proyecto PHP publicó correcciones para CVE-2026-109618 y CVE-2026-109619, dos fallas críticas del runtime. Bajo determinadas condiciones pueden permitir ejecución remota de código sin autenticación en instalaciones PHP que atienden solicitudes web. PHP advierte que todas las instalaciones que sirven peticiones deben tratarse como expuestas hasta verificar su versión y el parche del proveedor.
CVE-2026-109618 se relaciona con corrupción de estado interno durante el manejo de falta de memoria. CVE-2026-109619 describe estado global que puede conservar referencias a memoria de una solicitud anterior. No hace falta reproducir ni probar el exploit para gestionar el parche: el objetivo de esta guía es actualizar de forma controlada y comprobar que la aplicación sigue funcionando.
El aviso oficial destaca un riesgo particular para Apache con mod_php. También menciona PHP-FPM, php-cgi, FrankenPHP y LiteSpeed. La exposición concreta depende del runtime, la configuración y las rutas de aplicación; no se debe extrapolar el mismo escenario de explotación a todos los despliegues.
Versiones afectadas y versiones corregidas
La tabla resume los releases upstream publicados por PHP el 21 de octubre de 2026. “Corregida desde” indica el primer release de esa rama que incorpora el fix oficial. Si usás paquetes del sistema operativo, una imagen mantenida por un proveedor o PHP gestionado por hosting, verificá también su aviso: el proveedor puede haber aplicado un backport sin cambiar la versión upstream que muestra el comando.
PHP 8.2 tiene fin de soporte de seguridad previsto para el 31 de diciembre de 2026. Actualizar a 8.2.35 resuelve estas CVE en esa rama según el release upstream, pero conviene planificar la migración a una rama que siga recibiendo soporte. PHP indica que 8.1 y anteriores ya no reciben releases regulares del proyecto; para 7.4, 8.0 y 8.1 publicó backports mínimos de código fuente, y algunas distribuciones/LTS también pueden mantener sus propios parches. Confirmá exactamente qué paquete recibís y seguí la recomendación del proveedor.
| Rama upstream | Vulnerable antes de | Corregida desde | Soporte de seguridad |
|---|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 | Soportada |
| 8.4 | < 8.4.27 | 8.4.27 | Soportada |
| 8.3 | < 8.3.36 | 8.3.36 | Soportada |
| 8.2 | < 8.2.35 | 8.2.35 | Hasta 31 dic 2026 |
| 8.1, 8.0 y 7.4 | Afectadas; ramas EOL | Backport fuente mínimo o paquete del proveedor | Confirmar disponibilidad y soporte con proveedor |
| 7.3 y anteriores | Afectadas; ramas EOL | Sin release upstream indicado en el aviso | Migrar; consultar proveedor y no asumir parche |
La lectura es por rama: las versiones anteriores al release indicado requieren verificar el parche. Los paquetes de distribución pueden usar backports y otra numeración.
Antes de actualizar: inventario y preparación
Buscá todas las formas en que PHP llega a producción: paquetes del host, contenedores, imágenes base, paneles de hosting, runtimes incluidos en productos, workers y entornos de staging. Un sitio puede usar varias versiones a la vez. Identificá qué servicio recibe tráfico y qué equipo controla cada actualización.
Registrá la versión y el origen del paquete, el sistema operativo, el servidor web, el runtime, la imagen si aplica, la aplicación, el ambiente, la persona responsable y el plan para volver a la versión anterior si algo falla. No publiques `phpinfo()`: puede mostrar datos sensibles. Usá el inventario interno, la consola del proveedor o comandos autorizados por quien administra el entorno.
Leé las notas del proveedor y las guías de migración si el cambio implica pasar de rama, no sólo instalar un parche de la misma rama. Prepará una ventana, respaldo recuperable, criterio de reversión y una persona responsable de decidir. En servicios administrados, solicitá confirmación escrita de la versión/parche y del reinicio o redeploy requerido.
Secuencia segura de actualización
- Priorizá primero los servicios expuestos a Internet y verificá si el proveedor ya publicó el paquete corregido.
- Actualizá en un entorno representativo siguiendo las instrucciones de la distribución, hosting o imagen oficial.
- Reconstruí y desplegá contenedores desde una imagen corregida; actualizar el host no cambia automáticamente el PHP empaquetado dentro de una imagen.
- Reiniciá o reemplazá los procesos PHP según el procedimiento del proveedor para asegurar que los workers carguen el runtime actualizado.
- Confirmá la versión y el paquete desde el entorno que realmente recibe las visitas, no sólo desde otra terminal.
- Hacé las pruebas básicas y la regresión priorizada.
- Durante la ventana acordada, revisá los errores de la aplicación, los registros y las métricas.
- Si falla algo crítico, frená el despliegue, guardá lo ocurrido y volvé a la versión anterior según el plan acordado. Un WAF o una regla temporal no reemplaza el parche: PHP indica que hay que actualizar.
- 01Inventariar runtimes
- 02Aplicar parche del proveedor
- 03Confirmar proceso activo
- 04Ejecutar regresión
- 05Revisar evidencia y riesgo
- 06Decidir despliegue
Cómo armar el plan de regresión
Una regresión posterior a un parche busca detectar efectos no deseados en el producto y sus integraciones. No confirma por sí sola que el runtime esté libre de vulnerabilidades ni reemplaza un escaneo de seguridad, un análisis de dependencias o una validación de configuración. Mantené esos objetivos como actividades separadas con sus herramientas y responsables.
Delimitá el cambio: runtime y versión anterior/nueva, servicios, configuración, extensiones, dependencias y ambientes. Trazá qué flujos pasan por PHP y qué componentes podrían compartir workers, sesiones, caché, archivos o colas. Priorizá por impacto al negocio, exposición y dificultad de recuperación. Si no conocés una dependencia, registrala como riesgo pendiente en vez de asumir que no existe.
Separá el trabajo en tres capas: smoke de disponibilidad y funciones esenciales; regresión focalizada de las rutas cambiadas o dependientes; y una suite ampliada para los componentes de mayor impacto. Los resultados deben conservar build/release, runtime, ambiente y datos usados para que una diferencia se pueda investigar y repetir.
Catálogo de casos de prueba sugeridos
Adaptá estos ejemplos a la arquitectura y reglas reales del sistema. No son un paquete universal: quitá lo que no aplique y agregá flujos propios, extensiones y contratos de integración. Usá cuentas y datos de prueba, nunca secretos o información personal real.
| Área | Ejemplo de caso | Qué comprobar | Evidencia útil |
|---|---|---|---|
| Disponibilidad | Arranque, health check y ruta principal | Proceso saludable; respuesta esperada y dependencias disponibles | Build, ambiente, hora, código HTTP y log redactado |
| Autenticación | Ingreso, cierre de sesión y expiración | Sesión válida, revocación y redirección esperada | Usuario ficticio, pasos y resultado; nunca contraseña/cookie |
| Autorización | Acceso permitido y denegado por rol | Permisos efectivos y respuesta ante acceso no autorizado | Rol, recurso, resultado esperado/real y request ID |
| Formularios y flujos | Alta/edición de entidad o flujo de negocio crítico | Validaciones, persistencia, mensajes y reglas de negocio | Datos sintéticos, pasos, captura redactada y registro relacionado |
| API e integraciones | Contrato de éxito, error y timeout | Status, esquema/campos, autenticación y manejo de fallos | Request/response saneados, versión y servicio dependiente |
| Archivos | Carga, lectura y descarga autorizadas | Tipo/tamaño permitido, almacenamiento y permisos | Archivo sintético, metadatos, resultado y logs sin contenido sensible |
| Procesos asíncronos | Cola, tarea programada y reintento | Ejecución única esperada, estado final y manejo de error | ID de tarea, timestamps, estado y salida redactada |
| Datos y sesión | Persistencia entre solicitudes y workers | Consistencia, aislamiento entre usuarios y continuidad de sesión | IDs ficticios, secuencia de solicitudes y estado antes/después |
Criterios para decidir si la regresión termina
Definí antes de ejecutar qué fallas bloquean el despliegue. Como mínimo, no promociones si falla autenticación, autorización, una operación crítica, integridad de datos o un contrato esencial; si el runtime corregido no se puede confirmar; o si hay errores nuevos sin explicación. Un caso bloqueado por ambiente o datos no cuenta como aprobado.
Para cerrar, revisá cobertura contra el alcance, resultados fallidos/bloqueados/pendientes, evidencia, defectos asociados, riesgo residual, decisión y responsable. Una suite toda verde sólo describe los casos que sí se ejecutaron: no demuestra que se cubrieron todos los componentes PHP ni que el parche está presente en todos los servidores.
Checklist de cierre
- El inventario incluye PHP embebido en hosts, contenedores y proveedores.
- La fuente del paquete y el advisory usado para verificar el parche quedaron registrados.
- Los procesos que atienden tráfico fueron reiniciados/redeployados según el proveedor.
- La build, ambiente, runtime y datos sintéticos constan en cada ejecución.
- Los fallos, bloqueos, pendientes y riesgos residuales tienen responsable.
- Capturas, logs y payloads se revisaron para quitar secretos y datos personales.
Cómo conservar la regresión como evidencia QA
En Treseko podés organizar casos, suites, builds, ejecuciones, resultados, bugs y adjuntos para consultar qué se revisó y qué riesgo quedó abierto. Un ejemplo de regresión debe configurarse y ejecutarse por el equipo en su entorno: Treseko no instala el parche, identifica automáticamente todas las instancias PHP ni certifica una corrección de CVE.
Fuentes y recursos oficiales
- Aviso oficial de seguridad de PHP
- Advisory CVE-2026-109618 (PHP/GitHub)
- Advisory CVE-2026-109619 (PHP/GitHub)
- Ramas soportadas de PHP
- Descargas oficiales de PHP
- Guía oficial de migración de PHP 8.5
Esta guía es material educativo de QA; no es asesoramiento de respuesta a incidentes ni reemplaza las instrucciones del proveedor de PHP, sistema operativo, contenedor o hosting. Última revisión: 21 de octubre de 2026.