PHP2Shell (CVE-2026-109618 / CVE-2026-109619): cómo Core-Admin contiene el fallo de PHP mientras llegan los parches

core-admin · 2026-10-21 11:39:51 UTC

Actualización (26 de octubre de 2026): CVE-2026-115560 también está cubierta. El 23 de octubre PHP publicó un aviso informativo sobre una nueva vulnerabilidad, CVE-2026-115560, que todavía no tiene parche (llegará con la próxima versión ordinaria de PHP). Su mitigación oficial es la misma que ya aplica Core-Admin desde el 21 de octubre: session.upload_progress.enabled desactivado, y en nuestro caso además bloqueado para que ninguna web pueda reactivarlo. No hace falta ninguna acción adicional. Como esta CVE no la corrigen las versiones de PHP del 21 de octubre, la mitigación pasa a ser imprescindible y no debe retirarse hasta que PHP publique la corrección. Los detalles están en el apartado “CVE-2026-115560 (aviso del 23 de octubre)”, dentro de “Qué ha confirmado PHP”.

Actualización (22 de octubre de 2026): PHP corregido en todos los servidores. Hemos desplegado en todos los servidores que gestionamos versiones de PHP con la corrección de las dos vulnerabilidades.

Para PHP 7.4 a 8.5 son las correcciones oficiales publicadas por PHP el 21 de octubre: las nuevas versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y los parches oficiales para 8.1, 8.0 y 7.4.

Para las versiones antiguas afectadas, de PHP 5.2 a 7.3, que no reciben corrección oficial, hemos adaptado los parches nosotros mismos y los hemos verificado con las pruebas del propio PHP antes de desplegarlos.

Ya no queda ninguna versión de PHP sin corrección en los motores de Core-Admin, de la 5.2 a la 8.5.

Además, el webmail y los sitios que usaban el PHP de la distribución (que no recibe la corrección) se han pasado a motores de Core-Admin corregidos. La mitigación que se describe más abajo se mantiene activa como capa adicional. Seguimos revisando y haciendo seguimiento del caso por si fuera necesario adoptar alguna acción adicional.

Historial del artículo. Publicado el 21 de octubre por la mañana como artículo preliminar, antes del aviso oficial de PHP. Actualizado el 21 por la tarde al conocerse los primeros ataques (se añadió session.use_strict_mode = 1) el 22 de octubre con el aviso oficial y los parches desplegados, y el 22 por la noche con los parches de PHP 5.3 y 5.2 y el paso a motores de Core-Admin de las webs que usaban el PHP de la distribución. Actualizado el 26 de octubre con CVE-2026-115560, cubierta por la misma mitigación.

Introducción

El 20 de octubre de 2026 el equipo de seguridad de PHP anunció una versión de seguridad urgente que corrige dos vulnerabilidades críticas, ambas con una puntuación CVSS v4.0 de 9.2: CVE-2026-109618 y CVE-2026-109619. Antes del aviso oficial se filtró además una herramienta de explotación, conocida como PHP2Shell, que asegura funcionar con todas las versiones desde PHP 5.4.0.

El fallo se dispara mientras PHP procesa la petición, antes de ejecutar el código de la aplicación. Por eso no se puede corregir desde WordPress, PrestaShop ni ninguna otra aplicación: hay que actuar sobre el propio PHP. Y como las ramas 7.3 y anteriores ya no tienen soporte, no han recibido parche oficial.

Core-Admin ha actuado en dos fases:

Mitigación inmediata (21 de octubre): antes del aviso oficial, desactivó y bloqueó en todo el parque la función de PHP señalada por los análisis publicados, en todas las versiones de PHP instaladas y en todas las formas en que se sirve PHP a la web (php-fpm, mod_php y php-cgi).
Corrección (21 y 22 de octubre): instalación de las versiones y parches oficiales de PHP y, para las ramas antiguas, de parches adaptados por nosotros. Un nuevo control del checker comprueba en cada servidor que todos los motores PHP que sirven webs llevan la corrección.

Este artículo explica qué ha confirmado PHP, qué versiones están corregidas y cómo, qué hace Core-Admin, qué impacto tiene en las webs y cómo comprobarlo a mano.

Qué ha confirmado PHP

El aviso oficial del 21 de octubre describe las dos vulnerabilidades:

CVE	Aviso	Qué ocurre	¿Lo cubre algún ajuste de configuración?
CVE-2026-109618	GHSA-w8hw-w9fx-j79w	Cuando PHP se queda sin memoria mientras procesa una petición (por ejemplo, un cuerpo `multipart/form-data` preparado a propósito), aborta dejando datos de la petición a medio inicializar, que después se usan al terminarla	No. Solo la versión corregida de PHP lo elimina
CVE-2026-109619	GHSA-6wmf-4rv5-p3rp	Datos de la petición que siguen en uso después de liberarse su memoria. Vías confirmadas: el progreso de subida de la sesión (`session.upload_progress`) y, solo en PHP 8.5, las trazas de errores fatales (`fatal_error_backtraces`)	En parte: la mitigación de Core-Admin cierra las dos vías confirmadas, pero no otras variantes

La conclusión del aviso es la misma que anticipaban las guías publicadas antes: las medidas de configuración son una mitigación parcial y solo un PHP corregido elimina las dos vulnerabilidades.

Las medidas provisionales que propone el aviso para CVE-2026-109618 (memory_limit = -1 o un post_max_size muy bajo) no se han aplicado en el parque: en un alojamiento compartido darían memoria ilimitada a cada web o romperían las subidas de ficheros. En su lugar, hemos priorizado desplegar el PHP corregido.

Antes del aviso oficial

Lo que se sabía el 21 de octubre por la mañana, y que motivó la mitigación:

Informes de terceros describían las dos vulnerabilidades como ejecución remota de código sin autenticación, en todas las versiones desde la 5.x.
Ya había ataques en marcha. El 21 de octubre, Patchstack recibió avisos de explotación activa de varios proveedores de alojamiento (07:34 UTC) y Cloudflare informó de los primeros ataques y del despliegue de reglas en su WAF (07:43 UTC).

Cuidado con las listas de “versiones corregidas” que circularon antes del aviso. Alguna fuente daba como corregidas las versiones 8.5.11, 8.4.26, 8.3.35 y 8.2.34. Son las del 24 de septiembre, anteriores al parche: tener esas versiones no protege. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

La vía de `session.upload_progress`

Dos análisis independientes (Syhunt y J4ck3LSyN) apuntaron antes del aviso a un error de memoria (use-after-free) en el seguimiento del progreso de subida de ficheros de la sesión (session.upload_progress), una función de PHP que guarda en $_SESSION cuánto lleva recibido un formulario multipart/form-data mientras se sube. El aviso oficial lo confirmó como una de las vías de CVE-2026-109619.

Contrastamos esa hipótesis con el código fuente de PHP 8.4.26:

La estructura de datos señalada existe tal como la describen.
Con session.upload_progress.enabled = Off, el código afectado termina antes de tocar ningún dato del progreso.
La opción viene activa por defecto y es de tipo PHP_INI_PERDIR: un .user.ini o un php_flag en .htaccess pueden volver a activarla, salvo que se bloquee como opción de administrador.

Además, la función apareció precisamente en PHP 5.4.0, la versión a partir de la cual dice funcionar la herramienta filtrada.

El análisis también mencionaba una posible segunda vía en el procesado general de peticiones multipart que esta opción no cerraría. El aviso oficial la confirmó como CVE-2026-109618, que solo se corrige con el PHP actualizado.

CVE-2026-115560 (aviso del 23 de octubre)

El 23 de octubre PHP publicó un aviso informativo (“Informational advisory: Session upload progress”) sobre una tercera vulnerabilidad en la misma función, CVE-2026-115560, con posible ejecución remota de código. Según el aviso, solo puede explotarse si se dan las tres condiciones a la vez:

La configuración fija session.serialize_handler a php_binary o php_serialize.
La aplicación lo cambia a php en tiempo de ejecución con ini_set() antes de llamar a session_start().
session.upload_progress.enabled sigue activo.

PHP la considera poco probable en la práctica y no ha publicado parche: la corregirá en la próxima versión ordinaria, junto con el aviso completo. Mientras tanto recomienda exactamente la medida que ya aplicamos, session.upload_progress.enabled=0, e indica que quien la aplicó con CVE-2026-109619 “keep it in place and no further action is needed”.

Qué supone para los servidores con Core-Admin:

Está cubierta por la mitigación ya desplegada. Falla la tercera condición: la opción está desactivada en todas las versiones de PHP 5.4 a 8.5 y bloqueada como valor de administrador en php-fpm y mod_php. Una aplicación no puede reactivarla con ini_set() (la opción es PHP_INI_PERDIR), y los intentos desde .user.ini con php-cgi se neutralizan como se explica en el punto 2.
PHP 5.2 y 5.3 no están afectadas: no tienen la función de progreso de subida.
Las versiones de PHP del 21 de octubre no la corrigen, ni las oficiales (8.2.35, 8.3.36, 8.4.27 y 8.5.12) ni los parches para las ramas antiguas. Por eso, hasta que PHP publique la corrección, la mitigación deja de ser una capa adicional y pasa a ser la protección frente a esta CVE: no debe retirarse aunque todos los motores estén corregidos (ver “Revertir la mitigación”).
Cuando salga la versión con la corrección, la incorporaremos a los paquetes de Core-Admin de la misma forma que con las dos anteriores.

Versiones corregidas y parches desplegados

Versión de PHP	Corrección	Cómo se ha corregido
8.2 – 8.5	Oficial	Nuevas versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12
7.4, 8.0, 8.1	Oficial	Parche oficial de PHP aplicado sobre 7.4.33, 8.0.30 y 8.1.34
5.2 – 7.3	Adaptada por ASPL	Parche oficial adaptado por nosotros a cada rama (7.3, 7.2, 7.1, 7.0, 5.6, 5.5, 5.4, 5.3 y 5.2)

En PHP 5.2 y 5.3 solo aplica CVE-2026-109618: esas versiones no tienen la función de progreso de subida, que es la vía de CVE-2026-109619.

Todas las versiones corregidas se distribuyen como actualización de los paquetes PHP de Core-Admin (core-admin-php-X.Y) y ya están desplegadas en todos los servidores que gestionamos.

Cómo hemos adaptado los parches a las ramas antiguas

PHP solo publicó parches para las ramas 7.4, 8.0 y 8.1. Para las ramas anteriores, que Core-Admin sigue manteniendo para webs antiguas, hemos adaptado el parche rama a rama, partiendo cada vez de la inmediatamente superior (7.4 → 7.3 → 7.2 → … → 5.4 → 5.3 → 5.2):

Se conserva la misma corrección en las mismas funciones que el parche oficial, ajustada a las estructuras internas de cada versión.
Cada parche se ha probado compilando PHP y pasando las baterías de pruebas del propio PHP (motor Zend, sesiones y pruebas básicas): los resultados coinciden con los de la versión sin parchear, salvo las pruebas del progreso de subida, que fallan a propósito porque esa función sigue desactivada.
Donde existe, el resultado se ha contrastado con los parches que publica el mantenedor de PHP para Debian (deb.sury.org) para las mismas ramas.
El instalador comprueba la huella (sha256) de cada parche antes de aplicarlo y no genera el paquete si el parche no aplica limpio.

El PHP de la distribución

Además de sus propios motores, Core-Admin puede servir webs con el PHP que trae la distribución (por ejemplo php-fpm7.4 en Debian bullseye, php5-fpm en jessie o el módulo de Apache mod_php). Esos paquetes no llevan la corrección en Debian. El checker los detecta (ver la comprobación 5 más abajo) y, cuando sirven alguna web, la solución es pasar esa web a la misma versión del motor PHP de Core-Admin, que sí está corregida. Así lo hemos hecho en todos los servidores:

Webmail (Roundcube): usa siempre un motor de Core-Admin (PHP 8.2; 8.3 en Ubuntu noble), también en las distribuciones recientes, donde antes usaba el PHP de la distribución.
phpMyAdmin: se pasa a un motor de Core-Admin compatible con su versión.
Alojamientos en la versión “default” (en el modo de trabajo itk, la del PHP de la distribución): se pasan a la versión de Core-Admin de la misma rama, por ejemplo de la 5.6 de Debian a la 5.6 de Core-Admin.
mod_php: cuando ya no lo necesita ninguna web, se desactiva. Antes se comprueba que cada sitio con .php tenga su propio motor y se prueba cada web antes y después; si alguna cambia, se deshace el cambio automáticamente. Desde ese momento, un alojamiento no puede volver a la versión “default” mientras mod_php esté desactivado.

Versiones cubiertas por la mitigación

Versión de PHP	¿Tiene `session.upload_progress`?	Mitigación
5.2, 5.3	No	Nada que mitigar por esta vía (el checker las lista como “no cubiertas”)
5.4 – 8.4	Sí	`session.upload_progress` desactivado y bloqueado
8.5	Sí	Lo anterior, más `fatal_error_backtraces = 0`

La mitigación se aplica tanto a los motores PHP de Core-Admin (/usr/core-admin/php/X.Y) como al PHP de la distribución (/etc/php/X.Y, /etc/php5).

Se ha validado en servidores reales con Debian wheezy, jessie, stretch, buster y bullseye y Ubuntu focal, en los dos modos de trabajo de Core-Admin (apache2-mpm-worker-php-fpm y apache2-mpm-itk) y con Apache 2.2 y 2.4.

Cómo lo mitiga y lo controla Core-Admin

La mitigación forma parte del checker security_and_mitigations, el mismo que ya gestiona CopyFail, Dirty Frag, pedit COW, Januscape y el resto de fallos críticos mientras llegan los parches oficiales. Para PHP2Shell añade cinco comprobaciones.

1. Desactivar y bloquear la función (`php2shell`)

a) Fichero de configuración en cada SAPI web. En el conf.d de cada versión de PHP 5.4 o superior se escribe zzz-core-admin-cve-2026-109618.ini:

session.upload_progress.enabled = Off
session.use_strict_mode = 1

En los motores PHP 8.5 se añade además fatal_error_backtraces = 0, que cierra la segunda vía confirmada de CVE-2026-109619 (solo existe en esa versión). Las webs no lo notan: solo afecta a la traza que PHP añade al registro de un error fatal.

El prefijo zzz- hace que se cargue después de php.ini y del resto de ficheros de conf.d, así que prevalece sobre ellos. Se escribe solo en los SAPI que reciben peticiones web (fpm, apache2, cgi); la línea de comandos no se toca.

session.use_strict_mode = 1 se añadió el 21 de octubre por la tarde, al conocerse los ataques. Hace que PHP rechace los identificadores de sesión que no ha creado él mismo: es un endurecimiento general que el propio PHP recomienda para cualquier sitio y que aparece en todas las guías publicadas sobre este fallo. Funciona desde PHP 5.5.2; en la 5.4 se ignora sin dar error. No afecta a las aplicaciones normales (WordPress, PrestaShop, Nextcloud…); solo cambiaría el comportamiento de una aplicación que fije a mano un identificador de sesión que PHP no haya creado, algo muy poco habitual.

b) Bloqueo según cómo se sirva PHP. Un fichero .ini no basta: un cliente podría volver a activar la opción desde su .user.ini o .htaccess. Por eso se bloquea en cada vía:

Cómo llega PHP a la web	Desde dónde podría reactivarse	Bloqueo que aplica Core-Admin
php-fpm (pools por alojamiento)	`.user.ini`	`php_admin_flag[session.upload_progress.enabled] = off` en cada pool. Un valor de administrador no se puede cambiar ni con `.user.ini` ni con `ini_set()`
mod_php (versión “default” en modo itk)	`.htaccess` (`php_flag`, `php_value`)	`php_admin_flag session.upload_progress.enabled off` a nivel de servidor Apache, en `/etc/apache2/conf-available/core-admin-cve-2026-109618.conf` (Apache 2.4) o `/etc/apache2/conf.d/` (Apache 2.2)
php-cgi (otras versiones en modo itk)	`.user.ini`	No existe bloqueo de administrador: se neutraliza el `.user.ini` (ver el punto 2)

c) Recarga segura.

php-fpm: antes y después de modificar los pools se ejecuta php-fpm -t. Si la modificación introduce un error, se restauran los pools originales. Solo se recargan los motores que están en marcha.
Apache: se ejecuta apache2ctl configtest antes y después. Si el bloqueo rompiera la configuración, se retira automáticamente, para que un reinicio posterior de Apache no falle.
Si una recarga falla, el checker lo deja marcado y la reintenta en la siguiente pasada.

d) Verificación desde los binarios web, no desde la línea de comandos. El valor efectivo se comprueba con php-fpm -i y php-cgi -i de cada versión, porque la configuración de la línea de comandos puede ser distinta de la que recibe la web. Para mod_php se comprueban el fichero de conf.d, el bloqueo de Apache y que la recarga haya ido bien.

Las copias de seguridad de los pools modificados quedan en /var/backups/core-admin-php-cve-2026-109618/.

Además, los pools nuevos o regenerados por webhosting_management ya incluyen la línea de bloqueo, así que editar o regenerar un sitio no la elimina.

2. Neutralizar `.user.ini` con php-cgi (`php2shell_overrides`)

Solo actúa en servidores en modo apache2-mpm-itk, donde las versiones no “default” se sirven con php-cgi:

Cada hora se listan en segundo plano, y a baja prioridad, todos los .user.ini de las webs.
Las líneas que activan la opción se comentan, con una marca encima indicando que lo ha hecho Core-Admin. El resto del fichero no se toca.
El original se guarda una sola vez en /var/backups/core-admin-php-cve-2026-109618/user-ini/.
php-cgi relee .user.ini en un máximo de 5 minutos (user_ini.cache_ttl), así que no hace falta recargar nada.

Como el checker trabaja con permisos de root sobre ficheros de clientes, solo modifica un .user.ini si es un fichero normal, dentro de la carpeta de webs, sin enlaces simbólicos en la ruta, con un único enlace duro y de 64 KB como máximo. Cualquier otro caso se marca como CRITICAL para revisarlo a mano, sin escribir nada.

3. Revisión de los alojamientos (`php2shell_dependencies`)

Una vez al día, en segundo plano y a baja prioridad, se buscan en las webs los ficheros que mencionan upload_progress, y se clasifican:

CRITICAL: un .user.ini o .htaccess que reactiva la opción y que todavía nada bloquea. Es el único caso que deja un hueco real.
OK con nota INFO:: el código que usa la función (su barra de progreso dejará de avanzar) y los intentos de reactivarla que ya están neutralizados. Se listan para que soporte lo sepa, sin subir el estado.
Ignorados: los ficheros que solo mencionan la opción sin usarla: clases CSS (gfield_fileupload_progress de Gravity Forms), listas de opciones válidas (Symfony NativeSessionStorage) o herramientas de análisis (PHP Compatibility, PHP_CodeSniffer).

Para contar como “uso” real, el código tiene que contener el campo del formulario (PHP_SESSION_UPLOAD_PROGRESS o session.upload_progress.name) o leer la clave de la sesión (session.upload_progress.prefix o el literal upload_progress_).

4. Vigilancia de caídas de PHP (`php2shell_crashes`)

Un fallo de memoria explotado “a ciegas” suele tumbar procesos de PHP antes de conseguir su objetivo. El checker lee los logs de php-fpm (y el de errores de Apache si hay mod_php) y cuenta, por pool, los procesos que han muerto por SIGSEGV, SIGBUS o SIGABRT en la última hora:

5 o más: WARNING.
50 o más: CRITICAL.

Esta vigilancia funciona aunque la mitigación esté aplicada: también serviría para detectar intentos contra una vía que la mitigación no cubra.

5. Motores PHP sin la corrección (`php2shell_engines`)

Añadida el 21 de octubre con el aviso oficial. Revisa cada motor PHP instalado, de Core-Admin y de la distribución, y decide si lleva la corrección:

Por versión: 8.2.35, 8.3.36, 8.4.27, 8.5.12 o posteriores.
Para el resto (las ramas con parche oficial o adaptado), por el propio binario: la corrección añade una función nueva al motor de PHP, y el checker busca su nombre en cada binario que sirve webs (php-fpm, php-cgi y el módulo de Apache de mod_php). Así se comprueba el binario instalado, no solo lo que dice el número de versión del paquete.

Después cruza cada motor sin corregir con los alojamientos: pools de php-fpm, wrappers de php-cgi y mod_php.

CRITICAL: un motor sin la corrección sirve algún alojamiento. El mensaje lista los alojamientos afectados.
OK con nota INFO:: el motor está instalado pero no lo usa ninguna web.

Esta comprobación no cambia nada por sí sola: solo informa, e indica qué hay que hacer. Debajo del motor afectado ofrece dos botones, que el operador pulsa cuando lo decide:

"Instalar PHP X.Y de core-admin y mover a él sus alojamientos": instala (o actualiza) el motor de Core-Admin de la misma rama, comprueba que lleva la corrección y mueve a él los alojamientos y phpMyAdmin, uno a uno.
"Desactivar mod_php": cuando mod_php ya no ejecuta ninguna web. Asocia cada sitio a su propio motor, revisa la configuración, prueba las webs antes y después de desactivarlo y lo deshace todo si alguna cambia.

El resultado de cada botón queda en el registro del sistema del servidor.

Impacto en las webs

session.upload_progress solo rellena $_SESSION["upload_progress_<nombre>"] mientras llega un formulario multipart. Las subidas siguen funcionando igual; lo único que se pierde es la barra de progreso de las aplicaciones que consultan ese dato. Hoy casi todas calculan el progreso en el navegador (XMLHttpRequest.upload.onprogress), sin pasar por PHP.

Lo hemos comprobado en el código fuente:

Aplicación	Versión revisada	¿Usa `session.upload_progress`?	Efecto
WordPress	última (octubre 2026)	No. El núcleo ni siquiera usa sesiones de PHP	Ninguno
PrestaShop	9.3.0 (develop)	No	Ninguno
Nextcloud	35.0.2	No (sus subidas usan WebDAV)	Ninguno

En el despliegue por el parque solo hemos encontrado dos usos reales, y en ambos la subida sigue funcionando:

phpMyAdmin antiguo (4.0.x): la barra de progreso de la importación de ficheros .sql.
Plugin WPvivid Backup: la barra de progreso al restaurar una copia de seguridad.

¿Siguen protegidas las webs que usan la función? Sí. El fallo ocurre al procesar la petición, antes de que se ejecute el código de la web, y ningún código de la aplicación puede reactivar la opción: un ini_set() llega tarde y además lo impide el bloqueo de administrador. Por eso estos casos se informan como INFO: y no como aviso.

Salida del checker

Primera pasada en un servidor afectado (se aplica la mitigación):

[WARNING] PHP2Shell (CVE-2026-109618 + CVE-2026-109619): vulnerable, mitigation applied and verified
          (session.upload_progress.enabled Off verified on: core-admin PHP 7.4 fpm, core-admin PHP 7.4 cgi, ...,
          distro PHP 7.4 fpm)

El WARNING de la primera pasada es intencionado: indica que Core-Admin ha cambiado la configuración de PHP de los alojamientos.

Pasadas siguientes, ya en estado estable (no se vuelve a escribir nada):

[OK] PHP2Shell (CVE-2026-109618 + CVE-2026-109619): system not vulnerable
     (session upload progress disabled and locked on core-admin PHP 7.4, core-admin PHP 8.3, distro PHP 7.4)
[OK] PHP2Shell .user.ini overrides (CVE-2026-109618 + CVE-2026-109619): system not vulnerable
     (php-fpm working mode: .user.ini cannot override the pool lock)
[OK] PHP2Shell hosting dependencies (CVE-2026-109618 + CVE-2026-109619): system not vulnerable
     (no hosting uses or re-enables session upload progress (scan of /var/webs from ...;
      16 file(s) only mention it, ignored (CSS classes, option lists, compatibility sniffers)))
[OK] PHP2Shell worker crashes (CVE-2026-109618 + CVE-2026-109619): system not vulnerable
     (0 PHP worker crash(es) in the last hour (threshold 5))
[OK] PHP2Shell unpatched engines (CVE-2026-109618 + CVE-2026-109619): system not vulnerable
     (fixed: core-admin PHP 7.3 (7.3.33 + backport), core-admin PHP 7.4 (7.4.33 + backport),
      core-admin PHP 8.3 (8.3.36); INFO: installed but not serving any hosting, without the fix:
      distro PHP 7.4 (7.4.33, fix missing in /usr/sbin/php-fpm7.4))

En un servidor itk con mod_php aparece además mod_php (.htaccess locked) en la lista de motores bloqueados.

Un servidor con una web que todavía usa un motor sin corregir da:

[CRITICAL] PHP2Shell unpatched engines (CVE-2026-109618 + CVE-2026-109619): PHP engine(s) serving
           hostings without the fix for CVE-2026-109618 + CVE-2026-109619 (...): distro PHP 7.4
           (7.4.33, fix missing in /usr/sbin/php-fpm7.4) used by pool ejemplo.com

Opciones de exclusión

Cada comprobación tiene su opción en la configuración del checker:

Opción	Efecto
`skip_php2shell_mitigation`	No aplica la mitigación; la detección sigue y se informa como OK con un aviso. Solo para servidores que ya tienen la versión corregida de PHP o cuyas webs no pueden funcionar sin el progreso de subida
`skip_php2shell_overrides_mitigation`	No comenta los `.user.ini` de los clientes (servidores itk)
`skip_php2shell_dependencies_alert`	Silencia el CRITICAL de un override todavía activo, una vez revisado
`skip_php2shell_crashes_alert`	Silencia la vigilancia de caídas en servidores con una causa conocida y ajena (por ejemplo, una extensión defectuosa)
`skip_php2shell_engines_alert`	Silencia el control de motores sin la corrección. No recomendado: un CRITICAL aquí indica una web realmente expuesta

Verificación manual

# 1. El fichero de configuración está en todas las versiones
ls -l /etc/core-admin/php/*/conf.d/zzz-core-admin-cve-2026-109618.ini /etc/php/*/*/conf.d/zzz-core-admin-cve-2026-109618.ini

# 2. Valor efectivo según cada binario web: todas las líneas deben terminar en Off
for b in /usr/core-admin/php/*/sbin/php-fpm /usr/core-admin/php/*/bin/php-cgi /usr/sbin/php-fpm* /usr/bin/php-cgi*; do [ -x "$b" ] && echo "$b: $($b -i 2>/dev/null | grep -oE 'session\.upload_progress\.enabled( => |</td><td class="v">)[^ <]*' | head -1)"; done

# 3. Pools bloqueados: cada directorio debe dar N/N
for d in /etc/core-admin/php/*/php-fpm.d /etc/php/*/fpm/pool.d; do [ -d "$d" ] && echo "$d: $(grep -l '^php_admin_flag\[session.upload_progress.enabled\] = off' $d/*.conf 2>/dev/null | wc -l)/$(ls $d/*.conf 2>/dev/null | wc -l) locked"; done

# 4. Con mod_php: el bloqueo de Apache está cargado
ls -l /etc/apache2/conf-enabled/core-admin-cve-2026-109618.conf /etc/apache2/conf.d/core-admin-cve-2026-109618.conf 2>/dev/null; apache2ctl -t

Un directorio de pools con uno menos (por ejemplo 4/5) suele ser el www.conf de la distribución con la sección [www] comentada: un fichero sin pools activos no necesita bloqueo.

Comprobar que el PHP está corregido

# Versión y corrección de cada motor web: cada binario debe dar "corregido"
for b in /usr/core-admin/php/*/sbin/php-fpm /usr/core-admin/php/*/bin/php-cgi /usr/sbin/php-fpm* /usr/sbin/php5-fpm; do [ -x "$b" ] && echo "$b: $($b -v 2>/dev/null | head -1 | cut -d' ' -f1-2) $(grep -q -a -E 'zend_new_array_singleton|_array_init_singleton' $b && echo corregido || echo SIN-CORREGIR)"; done

La búsqueda funciona tanto con las versiones oficiales nuevas (8.2.35 o posterior) como con las ramas parcheadas, porque todas añaden la misma función al motor de PHP. Tras actualizar los paquetes en un servidor propio, reinicia los servicios php-fpm (y Apache si usas mod_php) para que los procesos en marcha carguen el binario nuevo.

Prueba real por la web

Para confirmar que una web concreta no puede reactivar la opción, crea un directorio temporal en su docroot con un script de prueba y un .user.ini (con php-fpm o php-cgi) o un .htaccess (con mod_php) que intente activarla. Usa un nombre aleatorio y bórralo al terminar. Ejemplo para un alojamiento con php-fpm:

d=<docroot>/zz-test-$RANDOM; mkdir $d && echo '<?php echo (ini_get("session.upload_progress.enabled") ? "ON" : "OFF") . " " . PHP_VERSION . " " . php_sapi_name () . "\n";' > $d/t.php && echo 'session.upload_progress.enabled = On' > $d/.user.ini && chown -R <usuario>:<grupo> $d && wget --no-check-certificate -q -S -O - http://<dominio>/$(basename $d)/t.php 2>&1 | grep -E 'HTTP/|^(ON|OFF)'; rm -rf $d

La respuesta debe ser OFF, seguida de la versión y el SAPI (fpm-fcgi, apache2handler o cgi-fcgi), con HTTP/1.1 200. Con mod_php, cambia el .user.ini por un .htaccess con php_flag session.upload_progress.enabled on. En servidores antiguos, usa wget en lugar de curl: el curl de Debian jessie puede fallar en TLS sin mostrar ningún error con -s.

Aplicar la mitigación a mano (sin Core-Admin)

En un servidor sin el checker, el mínimo equivalente es:

# 1. Desactivarla en cada SAPI web (ajusta las rutas a tus versiones)
for d in /etc/php/*/fpm/conf.d /etc/php/*/apache2/conf.d /etc/php/*/cgi/conf.d; do [ -d "$d" ] && printf 'session.upload_progress.enabled = Off\nsession.use_strict_mode = 1\n' > $d/zzz-cve-2026-109618.ini; done

# 2. Bloquearla en cada pool de php-fpm (añadir al final de cada sección de pool)
#    php_admin_flag[session.upload_progress.enabled] = off

# 3. Con mod_php, bloquearla en Apache (dentro de <IfModule php_module>, php7_module o php5_module)
#    php_admin_flag session.upload_progress.enabled off

# 4. Comprobar y recargar
php-fpm7.4 -t && systemctl reload php7.4-fpm
apache2ctl configtest && systemctl reload apache2

Revertir la mitigación

No la reviertas mientras CVE-2026-115560 no tenga corrección. Esa vulnerabilidad no la corrige ninguna versión de PHP publicada hasta ahora, y desactivar session.upload_progress es su única protección. El control php2shell_engines en OK no cubre este caso: solo comprueba la corrección de CVE-2026-109618 y CVE-2026-109619.

Recomendamos mantenerla aunque el PHP ya esté corregido: su único efecto visible es la barra de progreso de algunas aplicaciones antiguas. Cuando PHP publique la corrección de CVE-2026-115560 y esté desplegada, si quieres recuperar la barra de progreso en un servidor con todos sus motores PHP corregidos (el control php2shell_engines en OK):

Activa skip_php2shell_mitigation en el checker (si no, volverá a aplicarla).
Borra los ficheros zzz-core-admin-cve-2026-109618.ini de cada conf.d y core-admin-cve-2026-109618.conf de Apache (con su enlace en conf-enabled).
Quita la línea php_admin_flag[session.upload_progress.enabled] = off de los pools, o restaura las copias de /var/backups/core-admin-php-cve-2026-109618/.
Recarga php-fpm y Apache.

En un servidor con algún motor sin corregir, no la reviertas.

Preguntas frecuentes

P: ¿Las subidas de ficheros dejan de funcionar?

No. Las subidas funcionan exactamente igual. Solo deja de rellenarse el dato de progreso en la sesión, que casi ninguna aplicación actual utiliza.

P: ¿Tengo que hacer algo en mi web?

No. La corrección y la mitigación se aplican en el servidor y cubren todas las webs, uses la aplicación que uses. No hace falta actualizar plugins ni tocar el código por este fallo, aunque siempre conviene tener la aplicación actualizada.

P: ¿Puede una web volver a activar la opción?

No. Con php-fpm y mod_php la opción está bloqueada como valor de administrador, que no se puede cambiar desde .user.ini, .htaccess ni ini_set(). Con php-cgi, Core-Admin neutraliza automáticamente cualquier .user.ini que intente activarla.

P: ¿Estoy protegido del todo?

Si tu web usa un motor PHP de Core-Admin de la 5.2 a la 8.5, sí: tiene la corrección de las dos vulnerabilidades, que es lo único que las elimina por completo según el aviso oficial. Frente a CVE-2026-115560, que todavía no tiene parche, te protege la mitigación, que es la medida que recomienda el propio PHP. El checker vigila en cada servidor que la mitigación siga aplicada y que ninguna web quede en un motor sin corregir. Seguimos haciendo seguimiento del caso por si fuera necesaria alguna acción adicional, y actualizaremos este artículo si así fuera.

P: ¿Y la nueva CVE-2026-115560? ¿Tengo que hacer algo?

No. Su mitigación oficial (session.upload_progress.enabled desactivado) es la que Core-Admin aplica y bloquea desde el 21 de octubre en todas las versiones afectadas. Además, para explotarla la aplicación tendría que cambiar session.serialize_handler en tiempo de ejecución, algo muy poco habitual. Cuando PHP publique la corrección la incorporaremos a los paquetes de Core-Admin.

P: Uso PHP 5.x / 7.x / 8.0 / 8.1. ¿Qué hago?

Nada por este fallo: tu versión ya está corregida, con el parche oficial (7.4, 8.0 y 8.1) o con el parche adaptado por nosotros (5.2 a 7.3). Aun así, esas ramas ya no reciben soporte de PHP y los próximos fallos podrían no tener parche, así que recomendamos planificar la migración a una versión con soporte (8.2 o superior).

P: Mi web estaba en la versión “default” del servidor. ¿Ha cambiado algo?

Si el servidor usaba para ella el PHP de la distribución, que no recibe la corrección, la hemos pasado a la versión de Core-Admin de la misma rama (por ejemplo, de la 5.6 de Debian a la 5.6 de Core-Admin). Es la misma versión de PHP, ahora con la corrección. Si notas cualquier diferencia en tu web, avísanos.

P: ¿Cómo sé que mi web usa un PHP corregido?

En los servidores gestionados por Core-Admin lo comprueba el checker automáticamente (control php2shell_engines). Para verlo a mano, usa el comando del apartado “Comprobar que el PHP está corregido”.

P: ¿Se pierde la mitigación si regenero o edito un sitio?

No. Los pools que genera webhosting_management ya incluyen la línea de bloqueo. Y aunque un pool la perdiera por cualquier motivo, el checker la vuelve a añadir en su siguiente pasada.

P: ¿Necesito reiniciar algo?

No. El checker recarga php-fpm y Apache de forma controlada (con comprobación previa de la configuración) y php-cgi recoge el cambio por sí solo. En los servidores que gestionamos, el despliegue de las versiones corregidas también lo hemos hecho nosotros.

Seguimiento

Seguimos revisando y haciendo seguimiento del caso: nuevas variantes de CVE-2026-109619 que pudieran aparecer, la versión de PHP que corrija CVE-2026-115560, nuevos avisos de PHP y la actividad de ataques en el parque. Si fuera necesario adoptar alguna acción adicional, actualizaremos este artículo.