PHP 8.5.12 y 8.4.27 corrigen dos fallas RCE críticas

PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 el 21 de octubre de 2026 para corregir dos fallas críticas. Ambas pueden permitir que un atacante ejecute código en un servidor web sin iniciar sesión. El aviso de seguridad de PHP.net pide a todos los usuarios de PHP que actualicen de inmediato. Añade que ningún cambio de configuración protege por completo un servidor. Por eso, instalar la nueva versión es la única opción segura.

PHP anunció esta versión fuera de calendario un día antes, después de que los detalles de los errores se filtraran antes de lo previsto. Cubrimos ese aviso previo esta mañana. La versión de hoy responde a las preguntas pendientes: qué versiones están corregidas, qué hacen los errores y quién está más expuesto.

Qué hacen las dos fallas de PHP

Ambos errores están en el código que prepara y limpia cada solicitud web. PHP califica cada uno con 9.2 en CVSS v4.0, la escala estándar de gravedad de 0 a 10. Además, dice que ambos “pueden permitir la ejecución remota de código sin autenticación”. Sin autenticación significa que el atacante no necesita cuenta ni contraseña.

CVE	Aviso de GitHub	Qué sale mal
CVE-2026-109618	GHSA-w8hw-w9fx-j79w	Quedarse sin memoria puede detener a PHP a mitad de la preparación de una solicitud. El código de limpieza puede entonces tratar los datos a medio construir como válidos.
CVE-2026-109619	GHSA-6wmf-4rv5-p3rp	Algunos datos de la solicitud pueden sobrevivir a la memoria que los respalda. La siguiente solicitud en el mismo proceso worker puede usar primero esos datos obsoletos.

Un proceso worker es una de las copias de PHP de larga duración que un servidor web mantiene activas para responder solicitudes. Reutilizar workers es normal y rápido. Por eso los datos sobrantes de una solicitud importan para la siguiente.

Quién está en riesgo

Según el aviso de PHP, toda instalación que atienda solicitudes web puede estar afectada. Eso incluye PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP considera que mod_php, el módulo que ejecuta PHP dentro del propio Apache, es el de mayor riesgo. Describe un “exploit demostrado” en el que una sola solicitud sin autenticación desencadena el ataque antes de que se ejecute cualquier código de la aplicación.

Ese detalle importa para quien dependa de defensas a nivel de aplicación. Una regla de firewall dentro de WordPress o de un framework nunca llega a ejecutarse.

El aviso de PHP no informa de ataques reales. Otros reportes son menos concluyentes. Según TechStartups, el director de tecnología de Cloudflare vio señales tempranas de ataques, aunque su escala no está clara. TechStartups también cita a Benjamin Harris, director ejecutivo de watchTowr, quien dijo a BleepingComputer que ambos errores son “CVSS10”. Eso es más alto que el 9.2 que les da el propio PHP. Gulf News, citando a Reuters, informa que sitios web gubernamentales de Europa y otros lugares quedaron fuera de línea el miércoles tras la divulgación. No dice si los ataques causaron esas caídas.

Amazon informó después de que sus honeypots MadPot registraron un intento de explotación el 17 de octubre, cuatro días antes de esta versión, como explica Amazon vio intentos de ataque a PHP2Shell cuatro días antes de su divulgación.

Qué versiones de PHP instalar

Rama	Versión corregida	Notas
PHP 8.5	8.5.12	Corregida
PHP 8.4	8.4.27	Corregida
PHP 8.3	8.3.36	Corregida
PHP 8.2	8.2.35	Corregida; la rama llega al fin de su vida útil el 31 de diciembre de 2026
PHP 8.1, 8.0, 7.4	Ninguna	Solo parches mínimos de código fuente, en ramas llamadas PHP-8.1-CVE-2026-109618-109619 y similares
Anteriores a 7.4	Ninguna	Sin corrección de PHP

Los parches de código fuente para 7.4, 8.0 y 8.1 no son versiones empaquetadas. Alguien tiene que compilarlos. Gulf News señala que algunos proveedores podrían hacer backport de las correcciones a versiones antiguas que todavía soportan.

PHP también enumera mitigaciones parciales, como desactivar session.upload_progress.enabled y endurecer los límites de tamaño de las solicitudes. El aviso es tajante: estas medidas “no hacen segura una instalación”. Solo acotan el ataque mientras se despliega una actualización real.

Qué significa esto para los desarrolladores

Parchea hoy, y parchea también los lugares que olvidas. El servidor obvio rara vez es la única copia de PHP que ejecuta una organización.

• Revisa cada entorno de ejecución, no solo el sitio principal. Ejecuta php -v en cada host. Después revisa las imágenes base de contenedores, los runners de CI, los equipos de staging y las herramientas internas. Una imagen de Docker fijada a una etiqueta antigua conserva el error hasta que alguien la reconstruye.
• Reinicia después de actualizar. PHP-FPM y Apache mantienen vivos los procesos worker. Un paquete nuevo en el disco no sirve de nada hasta que esos workers se reinician. Así que confirma después la versión en ejecución.
• Prioriza los hosts con mod_php. PHP la señala como la configuración de mayor riesgo, con un exploit que se activa antes de que se ejecute tu código. Si no puedes actualizar hoy un servidor con mod_php, considera desconectarlo hasta que puedas.
• Trata PHP 8.1 y anteriores como una actualización de emergencia. No habrá ninguna versión oficial. Los parches de código fuente dan tiempo, pero solo si alguien los compila y los mantiene. Pregunta a tu proveedor de hosting o a tu distribución de Linux si ofrece un backport.
• Planifica el fin de la vida útil de PHP 8.2. La rama 8.2 deja de recibir correcciones de seguridad el 31 de diciembre de 2026. Pasar ahora a 8.4 o 8.5 evita una segunda carrera contrarreloj a fin de año.
• Vigila los registros. Los reportes de ataques tempranos no están confirmados, pero los detalles ya son públicos. Los cierres inesperados o los errores de falta de memoria en los workers de PHP merecen una revisión más detenida.