Actualizado el 23 de octubre de 2026. Los administradores de servidores que ejecutan PHP tienen dos actuaciones diferentes esta semana. El 21 de octubre se publicaron versiones corregidas para CVE-2026-109618 y CVE-2026-109619, dos fallos críticos que pueden permitir ejecución remota de código. El día 23, PHP difundió un nuevo aviso informativo sobre CVE-2026-115560, un vector poco habitual relacionado con el progreso de subidas de archivos asociado a sesiones. A fecha del aviso todavía no existe una versión específica que lo corrija: PHP recomienda una mitigación temporal.
Qué vulnerabilidades están corregidas y cuál sigue pendiente
Para los dos fallos del día 21 las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y anteriores no reciben mantenimiento ordinario del proyecto. Algunos proveedores ofrecen parches retroportados; comprueba siempre su cobertura en las notas de seguridad. Las actualizaciones del 21 no deben presentarse como solución definitiva del CVE anunciado el 23.
El nuevo vector requiere una combinación inusual: la configuración define session.serialize_handler como php_binary o php_serialize, la aplicación lo cambia mediante ini_set() a php antes de iniciar sesión y el progreso de subida permanece activado. No significa que todos los sitios PHP sean explotables por este fallo. PHP espera publicar su solución en un ciclo ordinario posterior y recomienda desactivar temporalmente session.upload_progress.enabled.
Guía para servidores Ubuntu
Primero identifica las ramas instaladas y comprueba qué PHP utiliza de verdad cada web: el intérprete de terminal puede no coincidir con los pools de PHP-FPM.
php -v | head -1
dpkg -l | awk '/^ii +php[0-9.]+-(cli|fpm) /{print $2, $3}'
sudo apt update
apt-cache policy php8.3-fpmAdapta el ejemplo a la rama instalada. La última versión disponible en APT puede ir por detrás de php.net. Algunas distribuciones también retroportan correcciones sin cambiar el número de versión upstream. Lee el aviso y el changelog del mantenedor.
Antes de actualizar, prepara una copia recuperable y revisa la lista de paquetes. Para limitar la actuación a los componentes de PHP 8.3 ya instalados:
dpkg -l | awk '/^ii +php8\.3-/{print $2}'
# Tras revisar la lista:
dpkg -l | awk '/^ii +php8\.3-/{print $2}' | xargs -r sudo apt install --only-upgradeEvita comodines no revisados que puedan arrastrar dependencias imprevistas. Una vez instalado el paquete parcheado, comprueba la configuración y reinicia los trabajadores PHP:
sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm --no-pagerEn Apache con mod_php reinicia Apache. Las colas, servidores de aplicaciones u otros procesos PHP persistentes pueden requerir reinicios independientes. Verifica el funcionamiento de las webs y los registros.
Mitigación del 23 de octubre: qué significa exactamente
La directiva indicada por PHP es:
session.upload_progress.enabled = OffPuede establecerse en el archivo de configuración de la versión de PHP que sirve las peticiones, antes de que empiece su procesamiento. Haz copia, comprueba que no exista ya un ajuste equivalente, valida la sintaxis y reinicia PHP-FPM. Ejemplo para Ubuntu con PHP-FPM 8.3:
echo 'session.upload_progress.enabled = Off' | sudo tee /etc/php/8.3/fpm/conf.d/99-upload-progress.ini
sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
php-fpm8.3 -i | grep upload_progress.enabledEl resultado efectivo debe indicar Off. Comprueba la configuración del servidor y de sus pools: modificar el PHP de consola no basta para proteger una web. Si ya lo tenías desactivado por la alerta anterior, mantenlo así y evita cambios innecesarios.
¿Se rompen las subidas de imágenes y documentos?
No: esta opción no desactiva las subidas de archivos. Únicamente apaga un mecanismo antiguo de PHP que guarda en la sesión información sobre el progreso de una subida. Las peticiones de formulario, los archivos recibidos por PHP y las barras de progreso implementadas en JavaScript en el navegador siguen funcionando normalmente. Solo una aplicación que utilice expresamente las variables de progreso almacenadas en sesión podría perder esa barra de seguimiento, sin impedir que el archivo llegue al servidor.
Conviene distinguir esta directiva de file_uploads=Off, que sí desactivaría las subidas en PHP. No las confundas. Prueba específicamente los formularios cuya barra de progreso dependa de sesiones PHP, pero no presupongas que los CMS o WordPress dejarán de recibir imágenes.
Clientes de hosting, VPS y gestión de versiones
En MuseDock conviene diferenciar responsabilidades. En un servicio gestionado, consulta el estado de mantenimiento al proveedor. En un VPS propio, el administrador debe ocuparse de las actualizaciones, la configuración efectiva y los reinicios. Un panel puede facilitar el cambio de rama PHP por hosting, pero no sustituye comprobar paquetes y procesos en ejecución. Una actualización de seguridad dentro de una rama soportada normalmente no exige modificar el código del CMS; un salto de versión mayor sí puede romper plugins o aplicaciones antiguas y merece pruebas previas.
Si administras varias versiones PHP, repite la revisión por rama activa. No basta con que la versión predeterminada de consola sea reciente. Un proceso antiguo puede seguir sirviendo tráfico y debe identificarse.
Comprobar procesos antiguos y señales de intrusión
for p in /proc/[0-9]*; do exe=$(readlink "$p/exe" 2>/dev/null); case "$exe" in *php*deleted*) echo "$exe";; esac; doneEsta comprobación puede localizar ejecutables PHP antiguos mantenidos en memoria tras una actualización; si no devuelve nada, no demuestra por sí sola que todos los servicios estén protegidos. Revisa también archivos nuevos inexplicables, tareas programadas extrañas y actividad saliente anómala. Si sospechas compromiso, conserva pruebas.
¿Afecta a WordPress, a los CMS o a las barras de progreso?
En la mayoría de instalaciones, no. Hay dos tecnologías distintas que a veces utilizan nombres parecidos. session.upload_progress.enabled controla una función específica del servidor PHP: almacena temporalmente información del avance de una subida en la sesión para que otra petición la consulte. En cambio, las barras modernas suelen obtener el progreso directamente en el navegador, mediante eventos como XMLHttpRequest.upload.onprogress. Desactivar el mecanismo de sesión no desactiva el envío de ficheros ni esas barras de JavaScript.
WordPress y bibliotecas del navegador
WordPress suele recurrir a bibliotecas como Plupload y Moxie para gestionar subidas y mostrar progreso en el navegador. Esas barras no requieren el seguimiento de sesión de PHP. Sin embargo, no se puede garantizar el comportamiento de todos los plugins personalizados o antiguos: conviene probar los formularios de subida más importantes.
MuseDock CMS y MuseDock Panel
Las interfaces de subida documentadas de MuseDock CMS (repositorio público), como las de medios, imágenes y elementos de contenido, emplean eventos de carga del navegador. En estas interfaces, desactivar session.upload_progress.enabled no debe afectar ni al envío del archivo ni a su barra de progreso. En las partes revisadas de MuseDock Panel (repositorio público) no se identificó dependencia de esta función PHP. Esto no constituye una auditoría de todos los plugins externos ni de todas las instalaciones posibles.
¿Y las aplicaciones antiguas?
Algún software antiguo puede incluir identificadores como UPLOAD_IDENTIFIER o nombres relacionados con upload_progress. Encontrar esas palabras mediante una búsqueda de texto no demuestra uso efectivo de la función vulnerable: hay que comprobar si el código del servidor consulta realmente el estado almacenado en sesión. Si una aplicación depende de ese mecanismo, podría perder su indicador de avance, pero la subida suele completarse igualmente.
Para validar una instalación concreta, realiza una subida de prueba, comprueba que el archivo se guarda y observa si la interfaz sigue mostrando el progreso. Esta verificación funcional es más fiable que inferir incompatibilidades a partir de nombres de variables.
Preguntas frecuentes
¿Se siguen pudiendo subir fotos? Sí. Solo se desactiva la barra de progreso que utiliza el sistema de sesiones de PHP, no la transferencia.
¿Basta con instalar PHP 8.3.36? Esa versión corrige los CVE del 21; sigue la recomendación temporal del 23 para el tercero.
¿Y si no uso PHP en mi VPS? Estas medidas específicas no son necesarias, aunque debes mantener actualizado el resto del software.
