Fallo crítico «php2shell»: estamos desplegando las actualizaciones de PHP

El proyecto PHP publicó este miércoles 21 de octubre de 2026, a las 14:00 UTC, unas versiones de seguridad que corrigen dos fallos críticos de ejecución remota de código: CVE-2026-109618 y CVE-2026-109619, ambos con una puntuación de 9,2 sobre 10 (CVSS v4.0). Los investigadores de watchTowr han bautizado a la pareja como «php2shell».

Nuestros equipos están desplegando en este momento las versiones corregidas en los servidores que administramos. Este artículo explica en qué consisten estos fallos, por qué se toman tan en serio y qué estamos haciendo por nuestra parte.

Dos fallos en el núcleo de PHP

Los fallos no afectan a WordPress, a PrestaShop ni a ninguna extensión concreta: están en el propio motor de PHP, en la forma en que prepara y luego limpia cada petición. Por eso pueden activarse sea cual sea el sitio o el CMS instalado.

CVE-2026-109618: corrupción de memoria tras quedarse sin memoria

Cuando una petición supera la memoria permitida, PHP la interrumpe. Si esa interrupción llega en mal momento, algunos datos internos de la petición solo están inicializados a medias. Aun así, la limpieza de fin de petición los trata como datos válidos, lo que corrompe la memoria y puede llevar a la ejecución de código elegido por el atacante.

Según el aviso del proyecto PHP, el riesgo es máximo con mod_php (PHP cargado directamente en Apache): un exploit demostrado permite que una petición sin autenticar lance el ataque antes incluso de que se ejecute el código del sitio.

CVE-2026-109619: reutilización de un estado global caducado

El segundo fallo afecta a un estado interno propio de cada petición, que puede sobrevivir a la liberación de la memoria que lo contenía. La siguiente petición atendida por el mismo proceso PHP (un «worker» de PHP-FPM, por ejemplo) puede entonces reutilizar ese estado caducado antes de que se reinicie. Las medidas provisionales publicadas por PHP muestran que está ligado al seguimiento del progreso de subida de archivos (session.upload_progress) y, en PHP 8.5, a las trazas de los errores fatales.

Por qué es grave

• No se necesita autenticación: basta con una simple petición HTTP a un sitio PHP, sin cuenta ni formulario concreto.
• Todos los sitios PHP están afectados: WordPress, PrestaShop, Joomla, Drupal, Laravel, Magento… Las estimaciones van de 1,3 a más de 1,9 millones de servidores expuestos en Internet.
• Los detalles se filtraron antes de la publicación, lo que llevó al proyecto PHP a anunciar el parche la víspera. Ya circula código de explotación sin verificar (y a veces con trampa: no lo ejecute).
• Cloudflare menciona primeros ataques, que por ahora no han confirmado ni el CERT-FR ni el catálogo de vulnerabilidades explotadas de la CISA.
• El precedente es elocuente: en 2024, el fallo CVE-2024-4577 se explotó menos de 24 horas después de su publicación.

Versiones afectadas y versiones corregidas

El CERT-EU considera que todas las versiones desde PHP 5 podrían estar afectadas. Algunos proveedores ofrecen parches adaptados a las ramas antiguas, pero la única solución duradera es pasar a una versión mantenida.

Lo que hacemos en HaiSoft

Seguíamos el anuncio desde la víspera y estábamos preparados: las actualizaciones se están desplegando en nuestros servidores.

• Alojamiento compartido: las versiones corregidas se están instalando para todas las versiones de PHP que ofrecemos. No tiene que hacer nada y la operación es transparente para sus sitios.
• Servidores dedicados y virtuales gestionados: actualizamos PHP en cada servidor; esta intervención está incluida en su contrato de gestión. Los paquetes corregidos del repositorio sury.org ya están disponibles y se están instalando.
• Servidores con Plesk o con los paquetes oficiales de Debian: Plesk y Debian todavía no han publicado sus paquetes corregidos. Seguimos sus publicaciones y aplicaremos las actualizaciones en cuanto salgan.
• Sitios que siguen en PHP 8.1 o anterior: estas versiones no recibirán parche. Contactaremos con los clientes afectados para planificar una migración a una versión mantenida.

¿Administra usted mismo su servidor?

1. Haga inventario de las versiones de PHP instaladas: php -v, los paquetes php8.* de Debian o plesk bin php_handler --list en Plesk.
2. Actualice a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 (o al paquete corregido de su distribución) y reinicie todos los servicios PHP-FPM, y Apache si utiliza mod_php.
3. Si la actualización tiene que esperar, aplique las medidas provisionales del proyecto PHP, que reducen el riesgo sin eliminarlo.
4. Aísle las aplicaciones en versiones sin mantenimiento (VPN, filtrado, desconexión), como recomienda el CERT-EU, hasta su migración.
5. Vigile cualquier shell, curl o wget lanzado por php-fpm, apache2 o httpd: es la señal típica de una explotación con éxito.

Las medidas provisionales recomendadas por el proyecto PHP deben colocarse en el php.ini o en la configuración del pool de PHP-FPM (no en un .user.ini ni mediante ini_set()), y después hay que reiniciar todos los workers:

; CVE-2026-109619
session.upload_progress.enabled = 0
; solo PHP 8.5
fatal_error_backtraces = 0
; CVE-2026-109618: limitar el tamaño de las peticiones
; (8M sin subida de archivos, 32M con ella)
post_max_size = 8M

Para CVE-2026-109618, el proyecto PHP también aconseja fijar memory_limit = -1 sin que la aplicación pueda modificarlo, y limitar el tamaño de las peticiones en el servidor web o en el proxy. Este ajuste elimina cualquier límite de memoria por script: resérvelo para los casos en que actualizar de inmediato sea realmente imposible.