Aviso de seguridad: vulnerabilidades críticas de PHP CVE-2026-109618 y CVE-2026-109619

El 21 de octubre de 2026, el proyecto PHP publicó una versión de emergencia para dos vulnerabilidades críticas del núcleo de PHP: CVE-2026-109618 y CVE-2026-109619 (CVSS v4.0 de 9,2 cada una). Ambas permiten ejecución remota de código sin autenticación: un atacante que pueda enviar una petición HTTP a cualquier script PHP puede ejecutar código con los permisos del proceso PHP. El aviso oficial de PHP se titula «update now» (actualiza ya). Los detalles se filtraron antes de la publicación coordinada y ya se informa de los primeros ataques. Los proveedores de alojamiento están desplegando la corrección en sus plataformas gestionadas. Hetzner, por ejemplo, está actualizando sus productos de alojamiento gestionado. En tu propio VPS, actualizar te toca a ti.

A quién afecta

A toda instalación de PHP que responda peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El proyecto PHP considera mod_php el caso de mayor riesgo. Los fallos están en el análisis de la petición, antes de que se ejecute tu aplicación, así que las pantallas de inicio de sesión, los plugins de seguridad y los middlewares no te protegen.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): la gestión de la falta de memoria puede interrumpir PHP cuando los datos de la petición solo están inicializados en parte, y la limpieza trata después datos no válidos como válidos.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): el estado de una petición puede sobrevivir después de liberarse su memoria, y una petición posterior en el mismo worker puede usarlo. Se alcanza a través del progreso de subida y de los backtraces de errores fatales.

Los servidores con ShadowPanel están afectados a través de PHP, no a través de ShadowPanel. La API y el daemon del panel funcionan con Node.js. Pero cada sitio PHP alojado se ejecuta en el PHP-FPM del servidor, igual que phpMyAdmin y el webmail en el puerto de administración. La corrección llega con los paquetes PHP de tu distribución. No hace falta actualizar ShadowPanel para recibirla.

Las versiones corregidas

Ten en cuenta que PHP 8.2 llega también al fin de su vida el 31 de diciembre de 2026.

Paso 1: comprueba qué ejecuta tu servidor

ShadowPanel instala PHP desde el repositorio ondrej/php y puede ejecutar varias versiones a la vez. Comprueba cada una:

for v in /etc/php/*/; do v=$(basename "$v"); echo "$v: $(php$v -v 2>/dev/null | head -1)"; done

Cualquier versión inferior a las de la tabla es vulnerable.

Paso 2: instala los paquetes corregidos

apt update
apt list --upgradable 2>/dev/null | grep '^php'
apt upgrade
systemctl restart 'php*-fpm'

Usa restart y no reload, para que ningún worker siga ejecutando el binario antiguo. Después repite la comprobación del paso 1 y confirma los nuevos números de versión.

Los paquetes de las distribuciones pueden llegar unas horas después de la publicación oficial. Si apt list --upgradable todavía no muestra la versión corregida, aplica ahora el paso 3 y repite el paso 2 más tarde hoy mismo.

Paso 3: reduce el riesgo mientras llegan los paquetes

Los desarrolladores de PHP son claros: solo la actualización corrige estos fallos. Las medidas siguientes reducen el riesgo. No lo eliminan.

Desactiva el progreso de subida de sesión. Cierra la vía de explotación confirmada de CVE-2026-109619 y no cuesta nada en la mayoría de sitios:

for d in /etc/php/*/fpm/conf.d; do
  echo 'session.upload_progress.enabled = 0' > "$d/99-upload-progress-off.ini"
done
systemctl restart 'php*-fpm'

El archivo en conf.d se aplica a todos los pools de esa versión de PHP, incluidos los pools por sitio que crea ShadowPanel. Puedes dejarlo después de actualizar. En PHP 8.5, añade también fatal_error_backtraces = 0 en ese mismo archivo.

Limita el tamaño de las peticiones frente a CVE-2026-109618. El aviso de PHP recomienda memory_limit = -1 junto con post_max_size = 8M y upload_max_filesize = 8M (32M si el sitio necesita subidas). Quitar el límite de memoria solo es seguro si otra cosa detiene un worker descontrolado, por ejemplo un límite MemoryMax= en el servicio systemd de PHP-FPM. No uses RLIMIT_AS ni RLIMIT_DATA para ello.

Haz callar tu configuración de PHP. Los ajustes obsoletos o no válidos que muestran un aviso en cada petición, y los errores fatales o tiempos de espera que un atacante puede provocar, facilitan el ataque. Ocultarlos con error_reporting, display_errors o @ no sirve de nada.

Bloquea las peticiones multipart en los sitios que no necesitan subidas. Un sitio corporativo o un blog sin formularios públicos puede rechazar multipart/form-data en nginx, antes de que PHP vea la petición. No lo hagas en una tienda, un foro o un panel de WordPress que sube medios: bloquea todas las subidas de archivos.

Una regla de cortafuegos de aplicaciones (CDN o ModSecurity) puede detener las peticiones de explotación conocidas, pero aparecen variantes nuevas rápidamente. Considérala solo una medida provisional. Los ajustes hechos con ini_set() o .user.ini no te protegen: ponlos en la configuración de PHP-FPM y reinicia.

Paso 4: saca los sitios de las versiones de PHP sin soporte

PHP 7.4, 8.0 y 8.1 no tendrán una nueva versión. El proyecto PHP publicó retroportes mínimos del código fuente, pero compilarlos o no depende del mantenedor de tu repositorio de paquetes. Si un sitio sigue en una de ellas, es el momento de cambiarlo, preferiblemente a PHP 8.3 o superior, porque el soporte de 8.2 termina este año. En ShadowPanel la versión de PHP se configura por sitio, así que puedes cambiar un sitio cada vez sin tocar los demás. Prueba primero el sitio con la nueva versión, a ser posible en una copia de staging. Para entender cómo funcionan las versiones por sitio, consulta varias versiones de PHP por sitio.

Paso 5: busca señales de intrusión

Los fallos eran públicos antes del parche. Si tus sitios estaban accesibles mientras tanto, revisa:

• archivos PHP desconocidos en las carpetas de subidas y de caché, y archivos modificados recientemente en tus raíces web;
• errores de PHP-FPM en /var/log/php/ y peticiones POST inusuales en los registros de acceso de nginx;
• nuevos usuarios administradores, tareas cron o claves SSH que no hayas creado.

El escáner de malware de ShadowPanel (planes Pro y Agency) analiza un sitio completo con ClamAV.

Resumen

1. Comprueba cada versión de PHP instalada.
2. Instala los paquetes corregidos y reinicia PHP-FPM.
3. Mientras tanto, desactiva session.upload_progress, limita el tamaño de las peticiones y restringe las subidas donde puedas.
4. Pasa los sitios que siguen en PHP 7.4, 8.0 u 8.1 a 8.3 o superior.
5. Busca señales de intrusión en tus sitios.

Para los detalles oficiales, lee el aviso de seguridad de PHP en php.net. Si usas ShadowPanel y tienes dudas sobre tu servidor, abre un ticket de soporte desde tu cuenta.