Alerta de seguridad PHP: CVE-2026-109618 y CVE-2026-109619

Guía práctica para empresas que operan aplicaciones web en PHP

Publicado: 22 de octubre de 2026

Resumen rápido

El 21 de octubre de 2026 el equipo de PHP publicó versiones de seguridad que corrigen dos vulnerabilidades críticas, identificadas como CVE-2026-109618 y CVE-2026-109619. Ambas pueden permitir la ejecución remota de código sin autenticación: un atacante no necesita usuario ni contraseña, solo enviar una petición HTTP especialmente construida al servidor. Ambas están calificadas con severidad 9.2 (crítica).

Lo más importante para cualquier empresa: el problema está en PHP, no en su aplicación. Un sistema bien programado, con consultas preparadas, control de roles y protección CSRF, sigue siendo vulnerable si el PHP que lo ejecuta no está actualizado, porque el ataque ocurre antes de que el código de la aplicación se ejecute.

El equipo de PHP indica que no existe una mitigación completa: actualizar es la única opción realmente segura.

¿A quién afecta?

A cualquier empresa que ejecute aplicaciones PHP en servidores propios, VPS, hosting compartido, cPanel, contenedores Docker o plataformas en la nube, sin importar el framework (Laravel, Symfony, WordPress, desarrollos a la medida, ERP internos, etc.).

Las versiones corregidas son:

Qué deben validar, paso a paso

1. Identificar la versión real de PHP en producción

• Ejecutar php -v en el servidor. Ojo: la versión de línea de comandos puede ser distinta a la que atiende el sitio web.
• Confirmar con un phpinfo() temporal (y retirarlo de inmediato) o desde el panel del hosting qué versión usa realmente el servidor web (Apache con mod_php, PHP-FPM, FrankenPHP, etc.).
• Revisar todos los entornos: producción, pruebas, respaldos activos, sitios secundarios y subdominios. Es común olvidar servidores antiguos.

2. Actualizar PHP

• Servidor propio o VPS (Debian/Ubuntu): actualizar todos los paquetes de PHP juntos, por ejemplo sudo apt update && sudo apt install --only-upgrade 'php8.*', y reiniciar PHP-FPM o Apache.
• cPanel u hosting compartido: cambiar a una versión corregida desde el selector de versión de PHP, o exigirle al proveedor la actualización.
• Docker: si la imagen fija una versión completa (por ejemplo php:8.4.26-apache), cambiarla a la corregida y reconstruir la imagen sin caché. Las etiquetas móviles (por ejemplo php:8.4-apache) ya apuntan a imágenes corregidas, pero igual hay que reconstruir y redesplegar.
• Plataformas administradas (PaaS): redesplegar sin caché de compilación y verificar la versión resultante. Si el proyecto fija la versión de PHP (por ejemplo en composer.json), hay que cambiar esa fijación.
• PHP 8.1 o anterior: no hay parche. Planificar la migración a 8.2+ cuanto antes.

Después de actualizar, verificar de nuevo con php -v y confirmar que el servicio web fue reiniciado.

3. Si no pueden actualizar hoy: mitigación parcial

Algunos proveedores recomiendan, de forma temporal, estos ajustes en el php.ini o en la configuración de PHP-FPM:

session.upload_progress.enabled = 0
memory_limit = -1
fatal_error_backtraces = 0

Importante:

• Dificultan el ataque, pero no lo corrigen.
• memory_limit = -1 permite que una sola petición consuma toda la memoria del servidor; úsenlo solo como medida de emergencia y con monitoreo.
• Deben aplicarse en php.ini o en la configuración de PHP-FPM, no con ini_set() ni archivos .user.ini, y el código de la aplicación no debe volver a fijar memory_limit en un número.
• Retirarlos una vez actualizado PHP.

4. Buscar señales de compromiso

Los parches se publicaron hace pocas horas, pero si el servidor estuvo expuesto con una versión vulnerable conviene revisar:

• Archivos PHP que nadie de su equipo creó, especialmente en carpetas de cargas de usuario (uploads, comprobantes, adjuntos, imágenes).
• Archivos PHP modificados recientemente en el directorio de la aplicación. Ejemplo: find /ruta/app -name "*.php" -mtime -15 -ls.
• Accesos inusuales, peticiones POST extrañas o errores fatales repetidos en los logs del servidor web y de PHP.
• Procesos o tareas programadas (cron) que no reconozcan.

Si encuentran algo sospechoso: aislar el servidor, conservar evidencia (logs y copias de los archivos), eliminar los archivos maliciosos, rotar todas las credenciales que la aplicación pueda leer (base de datos, SMTP, llaves de API, variables de entorno) y restaurar desde un respaldo limpio si es necesario.

5. Endurecer las carpetas de carga de archivos

No reemplaza el parche, pero limita el daño si algo se cuela por un formulario de subida:

• Impedir la ejecución de PHP en carpetas donde los usuarios suben archivos (por ejemplo con una regla en .htaccess o location de Nginx que niegue archivos .php allí).
• Guardar los archivos subidos fuera del directorio público y entregarlos mediante un script controlado.
• Validar extensión y tipo real del archivo, y renombrarlo con un nombre generado por el sistema.
• Aplicar mínimo privilegio en la base de datos: el usuario de la aplicación no debe tener permisos administrativos ni acceso a otras bases.

6. Respaldos y verificación final

• Tener un respaldo reciente de base de datos y archivos, almacenado fuera del servidor afectado.
• Si usan un WAF o CDN con reglas de protección, activarlas como capa adicional mientras se aplica el parche.
• Documentar qué se hizo, cuándo y quién lo verificó.

Lista de verificación rápida

Preguntas frecuentes

Mi aplicación tiene login y roles. ¿Estoy protegido? No por eso. La vulnerabilidad no requiere autenticación y se explota antes de que el código de la aplicación decida qué hacer con la petición.

Uso un framework actualizado. ¿Eso basta? No. Actualizar el framework no cambia la versión de PHP que lo ejecuta. Hay que actualizar PHP en el servidor o en la imagen.

Mi proveedor de hosting dice que ya lo parchó. ¿Qué verifico? Pida confirmación de la versión exacta y compruébela usted mismo desde la aplicación. Algunas plataformas redesplegan automáticamente, pero no siempre incluyen aplicaciones detenidas o con versiones fijadas.

Tengo PHP 8.1 o anterior. No existe parche para esas ramas. Aplique las mitigaciones parciales como medida temporal y migre cuanto antes.

Referencias

• Anuncios de PHP 8.5.12 y 8.4.27 en el repositorio oficial php-src (GitHub)
• Avisos de seguridad GHSA-w8hw-w9fx-j79w (CVE-2026-109618) y GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Registro de vulnerabilidades NVD: CVE-2026-109618 y CVE-2026-109619
• Aviso de Sevalla sobre estos CVE, con pasos por tipo de despliegue