¿Qué afectaba la vulnerabilidad de PHP?

El 21 de octubre de 2026, el proyecto PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades críticas que permitían ejecutar código a distancia sin autenticación. Sushell actualizó FELvus y los sitios de sus clientes ese mismo día.

Qué ocurrió ​

Según el aviso de seguridad publicado en php.net, las dos fallas pueden permitir que un atacante ejecute código en el servidor sin necesidad de una cuenta ni de credenciales. El equipo de seguridad de PHP las calificó como críticas y recomendó a todos los usuarios actualizar de inmediato. Las distribuciones de Linux y los proveedores de soporte extendido recibieron los parches por adelantado, por lo que conviene revisar los paquetes actualizados de cada proveedor.

Las dos vulnerabilidades ​

La primera, corrupción por falta de memoria (CVE-2026-109618), se produce cuando PHP se queda sin memoria a mitad de una petición. El manejo de ese error puede interrumpir el proceso mientras ciertos datos internos están inicializados solo en parte, y la limpieza posterior los trata como si fueran válidos. Con peticiones preparadas para provocar esa situación, como formularios con un número desmedido de partes o encabezados, el resultado puede llegar a la ejecución remota de código.

La segunda, estado global obsoleto (CVE-2026-109619), afecta a los procesos que atienden muchas peticiones seguidas. Cierta información interna de una petición puede sobrevivir después de que su memoria ya fue liberada, y una petición posterior atendida por el mismo proceso puede usarla antes de que se reinicie. Ese uso de memoria liberada, combinado con una preparación cuidadosa, también permite ejecutar código a distancia.

Quiénes estaban en riesgo ​

El aviso señala como expuestas todas las instalaciones de PHP que atienden peticiones web, entre ellas:

• PHP-FPM, la configuración más común en servidores con Nginx.
• Apache con mod_php.
• php-cgi.
• FrankenPHP y LiteSpeed.

El equipo de PHP considera que el riesgo es mayor en mod_php, donde demostró un ataque en el que una sola petición sin autenticar desencadena la falla antes de que se ejecute cualquier código de la aplicación. Esto incluye sitios en WordPress, tiendas en línea, sistemas de facturación y paneles administrativos, sin importar si se alojan en hosting compartido o en un VPS.

Cómo se corrige ​

La única solución completa es actualizar PHP a una de las versiones corregidas:

PHP 8.1 y las versiones anteriores ya no reciben actualizaciones del proyecto. Dada la gravedad del caso, el equipo de seguridad publicó parches mínimos de código fuente para PHP 7.4, 8.0 y 8.1, pensados para quienes compilan PHP por su cuenta; algunas distribuciones y proveedores de soporte extendido también ofrecen correcciones. Aun así, la recomendación para esos sitios es migrar a una rama con soporte.

Qué hizo Sushell ​

Sushell actualizó FELvus y los sitios de sus clientes a versiones corregidas de PHP, entre ellas la 8.4.27 en el hosting de clientes, con lo que el 100% de los sistemas de clientes y los sistemas propios de Sushell quedó con el parche oficial. Las pausas temporales de ese día fueron una medida preventiva mientras se aplicaba la actualización; los datos y archivos permanecieron protegidos en todo momento.

Los sitios basados en WordPress ya funcionan sobre la versión corregida de PHP. Las actualizaciones adicionales de WordPress y de sus plugins se aplicarán a medida que estén disponibles. Los clientes con dudas sobre un sitio específico pueden comunicarse con el equipo de Sushell para revisarlo.

Si no es posible actualizar de inmediato ​

El aviso oficial describe medidas temporales que reducen la exposición a algunas rutas de ataque, aunque aclara que no hacen segura una instalación. Solo la actualización resuelve el problema.

• Contra la corrupción por falta de memoria: fijar memory_limit=-1 de forma que las aplicaciones no puedan cambiarlo, por ejemplo con php_admin_value en el pool de FPM o en la configuración de Apache; usar un post_max_size bajo, de 8M si la aplicación no recibe archivos o de 32M si los necesita; y limitar el uso de memoria con contenedores o cgroups, no con RLIMIT_AS ni RLIMIT_DATA, que pueden provocar justamente la falla.
• Contra el estado global obsoleto: desactivar session.upload_progress.enabled y reiniciar todos los procesos; en PHP 8.5, además, fijar fatal_error_backtraces=0. Estos ajustes deben ir en php.ini, en el pool de FPM o en la configuración del servidor, no en ini_set() ni en .user.ini.

Fuentes ​

• Aviso de seguridad del 21 de octubre de 2026 en php.net.
• GHSA-w8hw-w9fx-j79w: RCE via OOM corruption, CVE-2026-109618.
• GHSA-6wmf-4rv5-p3rp: RCE via stale global state, CVE-2026-109619.