PHP2Shell: la versión de emergencia de PHP de octubre corrige dos fallos de ejecución remota de código

PHP publicó ayer, 21 de octubre, una versión de seguridad fuera de calendario. PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos fallos críticos del propio PHP, CVE-2026-109618 y CVE-2026-109619, que los investigadores que los encontraron llaman PHP2Shell. Según php.net:

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Es decir: estas versiones corrigen dos vulnerabilidades críticas que pueden permitir ejecución remota de código sin autenticación, y PHP recomienda a todos sus usuarios actualizar de inmediato.

No son fallos de Magento, Laravel ni WordPress. Se alcanzan mientras PHP todavía está preparando la petición, antes de que se ejecute el código de su aplicación, así que da igual lo bien escrito que esté ese código. Si un servidor ejecuta PHP para la web, necesita la actualización.

Las dos CVE

Las dos tienen el vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Por la red, sin cuenta, sin que nadie tenga que hacer clic en nada y con impacto total. Lo que las deja por debajo de 10 es la complejidad de ataque alta y que existan "requisitos de ataque": el atacante primero tiene que llevar el servidor a un estado concreto, y lo fácil que sea eso depende de la configuración.

CVE-2026-109618 tiene que ver con quedarse sin memoria en el peor momento. Cuando PHP alcanza su límite de memoria, sale directamente de la petición. El aviso dice que en algunos puntos la memoria de la petición ya es accesible antes de estar inicializada del todo, de modo que la limpieza posterior lee datos a medio inicializar como si fueran válidos. Un atacante puede provocarlo a propósito con subidas de formularios multipart demasiado grandes o mal formadas, un tipo de petición que acepta cualquier sitio PHP.

CVE-2026-109619 tiene que ver con el estado que queda de una petición a otra. Un worker de PHP-FPM o de Apache atiende una petición tras otra, y parte del estado interno (errores, sesiones, extensiones) puede sobrevivir a la memoria a la que apunta. Una petición posterior en el mismo worker lee esa memoria ya liberada antes de que PHP la reinicie. El aviso nombra dos vías confirmadas: session upload progress, que viene activado por defecto y funciona aunque la aplicación nunca llame a session_start(), y los ajustes de PHP que generan un aviso mientras se aplican, antes de que empiece la petición. En PHP 8.5, el nuevo ajuste fatal_error_backtraces es una fuente confirmada de ese estado residual. Sansec dice que este fallo también puede devolver al atacante memoria liberada del worker dentro de una cookie PHPSESSID, que podría incluir contraseñas, tokens de sesión o claves de la petición de otra persona.

La corrección del primero cambia cómo gestiona PHP la falta de memoria: ahora se detiene en el siguiente punto seguro, o termina el proceso directamente si el consumo sigue subiendo. La del segundo reinicia correctamente el estado residual.

Qué servidores están afectados

PHP incluye PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Los avisos precisan hasta dónde se demostró cada caso:

• Apache con mod_php es el peor caso. PHP validó ejecución remota de código completa por HTTP con los límites de memoria y de entrada por defecto y una configuración prefork normal. Las líneas php_value de .htaccess son una de las vías de aviso temprano de CVE-2026-109619.
• PHP-FPM, que es lo que usan la mayoría de servidores con Magento y Laravel, es vulnerable a CVE-2026-109618 según el análisis del código fuente de PHP, aunque no se demostró un exploit completo contra él. En CVE-2026-109619, la vía de session upload progress se validó contra FPM además de contra mod_php. La vía de los ajustes tempranos solo afecta a FPM si el servidor web envía PHP_VALUE o PHP_ADMIN_VALUE; los ajustes del pool y .user.ini no la activan.
• FrankenPHP y LiteSpeed son probablemente vulnerables según los avisos, sin validar.

Nada de eso permite dejar FPM sin actualizar. El aviso dice textualmente que actualizar "is the only complete mitigation", la única mitigación completa.

Qué se sabe de la explotación

La cronología siguiente viene del artículo de Sansec, que cita a los investigadores. Calif informó del primer fallo a PHP el 11 de agosto y Wiz Research informó de las vulnerabilidades el 24 de agosto, así que el equipo de PHP tuvo unos dos meses. Después, el 20 de octubre, se filtraron los detalles. PHP publicó ese mismo día un aviso previo que fijaba la versión para el 21 de octubre a las 14:00 UTC y decía que se adelantaría si aparecía explotación.

A partir de ahí, los informes no coinciden:

• Cloudflare dice que sus reglas de WAF estaban activas por defecto en los planes gratuitos y de pago desde las 03:02 UTC del 21 de octubre, y que observó "attack traffic targeting our customers", tráfico de ataque contra sus clientes. No dice si alguno tuvo éxito.
• Huntress dijo que no había visto explotación real entre sus clientes a las 4:30 p. m. (hora del Este) del 21 de octubre.
• La actualización de Sansec del 22 de octubre rebaja su propia previsión de explotación masiva. En sus palabras, "The public exploits do not work against a default PHP installation": los exploits públicos no funcionan contra una instalación de PHP por defecto, y la mayoría de las pruebas de concepto públicas necesitan además un fallo de inclusión local de archivos en la aplicación.

Sansec también informa de que Calif demostró ataques funcionales contra versiones actuales de Magento, WordPress, Drupal, Joomla, Nextcloud, phpMyAdmin, Laravel y Symfony. Nosotros no hemos reproducido ninguno, y no podemos decirle lo difícil que es atacar hoy una tienda típica. Eso sí, los exploits de fallos así suelen mejorar una vez que los detalles son públicos, y estos llevan dos días siéndolo.

Cómo actualizar

Actualizar PHP a una versión de parche es actualizar un paquete y reiniciar. Las versiones de parche solo traen correcciones de errores y de seguridad, así que en la mayoría de servidores lo único que hay que planificar es el reinicio.

Si PHP viene de Ubuntu o Debian

Ubuntu y Debian aplican la corrección sobre la versión de PHP que ya distribuyen, así que php -v no cambia. Un servidor Ubuntu 24.04 ya parcheado sigue mostrando PHP 8.3.6. Compruebe la versión del paquete:

dpkg -l | grep -E '^ii +php[0-9.]+-(fpm|cli|common)'

y compárela con las versiones corregidas de la página de la CVE de Ubuntu y del tracker de Debian:

En esas distribuciones, apt update && apt upgrade instala la corrección.

Si PHP viene de otro sitio

Muchos servidores con Magento y Laravel usan PHP del repositorio de Ondřej Surý (ppa:ondrej/php) o de un panel de hosting, y las imágenes de Docker usan builds oficiales. Esos siguen la numeración de PHP, así que php -v debería mostrar 8.5.12, 8.4.27, 8.3.36 u 8.2.35 o posterior. No hemos comprobado cuándo publicó cada uno de esos canales las nuevas builds, así que compruébelo antes de dar nada por hecho:

apt-cache policy php8.3-fpm

En Docker, descargue la nueva imagen base y vuelva a construir. Un contenedor construido ayer por la mañana sigue teniendo el PHP antiguo.

Si un proveedor gestionado le administra PHP, incluido Adobe Commerce Cloud, pregúntele cuándo se actualizó en su entorno.

Reinicie todo lo que ejecuta PHP

Un binario nuevo en disco no hace nada hasta que desaparecen los procesos que ejecutan el antiguo. Después de actualizar:

• Reinicie PHP-FPM, todas las versiones instaladas, por ejemplo systemctl restart php8.3-fpm. Un reload basta para cargar código nuevo, pero tras actualizar PHP lo prudente es un reinicio completo.
• Reinicie Apache si PHP se ejecuta dentro de él como mod_php.
• Reinicie los procesos PHP de larga duración: los consumers de colas de Magento, Laravel Horizon o queue:work, Octane y todo lo que esté bajo Supervisor. No son la entrada web que describen los avisos, pero siguen ejecutando el binario antiguo.

Después compruebe que el servicio en ejecución arrancó tras la actualización:

systemctl status php8.3-fpm

La hora de Active: active (running) since debe ser posterior a la actualización. La misma comprobación sirve para apache2.

Si no puede actualizar hoy

El aviso de PHP enumera ajustes provisionales y deja claro que reducen la exposición sin dejar el servidor seguro. Tienen que ir en php.ini, en el pool de FPM o en la configuración del servidor web, no en ini_set() ni en .user.ini, y después hay que reiniciar todos los workers:

; php.ini or FPM pool
session.upload_progress.enabled = 0
fatal_error_backtraces = 0      ; PHP 8.5 only
post_max_size = 8M              ; 32M if the site takes uploads
upload_max_filesize = 4M        ; must stay below post_max_size

El aviso recomienda dejar session.upload_progress.enabled desactivado incluso después de parchear si nada lo usa. La mayoría de aplicaciones Magento y Laravel no lo usan. Si grep -r PHP_SESSION_UPLOAD_PROGRESS en su código no encuentra nada, probablemente puede desactivarlo para siempre.

Hay dos medidas más que tienen un coste:

• memory_limit = -1 con un límite de memoria de contenedor o cgroup. PHP la incluye, pero advierte que es incompleta, y Sansec señala que sin límite de memoria en PHP una sola petición puede agotar la memoria de todo el servidor. No lo haga en un servidor compartido.
• Bloquear multipart/form-data en el servidor web. Sansec lo sugiere, y elimina la vía principal hacia CVE-2026-109618, pero rompe la subida de archivos, incluidas las imágenes de producto del admin de Magento, y posiblemente algunos formularios del carrito y del checkout.

Ocultar los errores no sirve. El aviso dice que bajar error_reporting, usar @ o desactivar display_errors no protege contra la vía de aviso temprano.

Un WAF es una capa adicional razonable. Las reglas de Cloudflare están activas por defecto, también en los planes gratuitos, y la propia Cloudflare dice que hay que parchear igualmente. Sansec dice que los fallos se ejecutan "before your store code and before Sansec Shield", antes del código de la tienda y antes de Shield, y pide a sus propios clientes que no esperen a una regla de Shield. Usamos Sansec en tiendas de clientes y hemos explicado por qué. No tenemos ninguna relación comercial con Sansec ni con Cloudflare.

PHP 8.1 y anteriores

PHP 8.1 y anteriores no reciben una nueva versión. Para este incidente concreto, el equipo de seguridad de PHP publicó parches mínimos de código fuente para 7.4, 8.0 y 8.1, que solo ayudan si usted compila PHP. Ubuntu corrigió sus propios paquetes hasta la 14.04, los más antiguos a través de Ubuntu Pro. Los proveedores comerciales de soporte extendido tienen sus propias builds. Sansec señala que las imágenes oficiales php de Docker no recibirán corrección para 8.1 o anteriores.

Si está en una de esas versiones sin un proveedor detrás, la única forma de obtener la corrección es pasar a un PHP con soporte. Es un trabajo mayor que un parche, porque la aplicación y sus extensiones tienen que ser compatibles con la nueva versión. Nuestros artículos sobre el soporte de versiones de Laravel y los requisitos de servidor para actualizar Laravel cubren la parte de Laravel, y para Magento lo hace el artículo sobre el fin de soporte de 2.4.6.

PHP 8.2 llega a su fin de soporte el 31 de diciembre de 2026, dentro de diez semanas. La 8.2.35 de hoy corrige estos dos fallos, pero no habrá muchas más. PHP 8.6 está prevista para el 19 de noviembre, y 8.6.0 RC4 ya incluye las correcciones. Nuestro artículo sobre PHP 8.6 explica qué cambia al subir de versión.

Si quiere ayuda para revisar o actualizar sus servidores, contáctenos. Nos ocupamos de servidores PHP para sitios con Magento, Laravel y WordPress.