PHP publicó hoy un parche crítico: qué pasó y cómo actualizar

En corto

Estás a salvo con estas versiones o más nuevas:

• PHP 8.5: 8.5.12
• PHP 8.4: 8.4.27
• PHP 8.3: 8.3.36
• PHP 8.2: 8.2.35

Si usas los paquetes de Ubuntu o Debian, el número de PHP no cambia; lo que cuenta es la versión del paquete (apt policy php8.3-fpm, con tu versión):

• Ubuntu 22.04: 8.1.2-1ubuntu2.28
• Ubuntu 24.04: 8.3.6-0ubuntu0.24.04.13
• Ubuntu 26.04: 8.5.4-0ubuntu1.5
• Debian 12: 8.2.35-1~deb12u1
• Debian 13: 8.4.27-1~deb13u1

PHP 8.1 o anterior no tiene versión oficial segura: usa el parche de tu proveedor o migra. En Docker, vuelve a descargar la imagen oficial php. Después de actualizar, reinicia PHP-FPM y los workers, y confirma con php -v. Ya hay exploits públicos: hazlo hoy.

Actualización del 22 de octubre

Lo que cambió en las primeras 24 horas:

• Ya hay paquetes casi en todos lados. La imagen oficial php de Docker tiene las cuatro ramas corregidas en amd64 y arm64 desde la tarde del 21. Ya no hace falta construirla a mano. El detalle por distribución está más abajo.
• Ya hay exploits públicos. Rapid7 revisó varias pruebas de concepto y concluyó que cada una funciona solo con una combinación específica de sistema operativo, versión de PHP y servidor web; ninguna parece confiable en general. Advierte que eso puede cambiar en cualquier momento. watchTowr reporta explotación real en sus honeypots desde el 21 de octubre; Rapid7 no la ha observado, pero sí intentos. Al 22 de octubre, CISA no ha agregado las fallas a su catálogo de vulnerabilidades explotadas.
• El parche no está incompleto. Circularon reportes de que 8.5.12 sigue siendo vulnerable. Se refieren a otra falla de memoria, distinta y más antigua, que todavía no tiene parche ni CVE. Quien la encontró dice que se puede disparar a distancia, pero que convertirla en ejecución de código es muy difícil. Actualizar sigue siendo lo correcto: las versiones del 21 corrigen las dos fallas que ya se están explotando.
• Hay detalles después de actualizar, ninguno es razón para quedarse en la versión vieja. Los explicamos abajo.

Qué pasó

El 21 de octubre el proyecto PHP publicó versiones nuevas de las cuatro ramas con soporte. Cada una corrige dos vulnerabilidades críticas, calificadas con 9.2 en CVSS v4.0. Las dos pueden llevar a ejecución remota de código sin autenticación:

• CVE-2026-109618: cuando PHP se queda sin memoria, puede interrumpirse mientras los datos de la petición están a medio inicializar, y la limpieza posterior los trata como válidos.
• CVE-2026-109619: cierto estado de una petición sobrevive después de liberar su memoria, y una petición posterior atendida por el mismo proceso puede usarlo.

A quién afecta

A cualquier PHP que atienda peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP considera mod_php el caso de mayor riesgo, porque demostró un ataque que se dispara antes de que corra una sola línea de tu aplicación. No importa qué tan bien escrito esté tu código: la falla está en el intérprete.

Las versiones corregidas son:

• PHP 8.5 → 8.5.12
• PHP 8.4 → 8.4.27
• PHP 8.3 → 8.3.36
• PHP 8.2 → 8.2.35 (esta rama deja de recibir soporte el 31 de diciembre de 2026)

PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto. El equipo de seguridad publicó parches mínimos en código fuente para 7.4, 8.0 y 8.1. Desde el 22 de octubre, packages.sury.org (amd64) y ppa:ondrej/php traen ese parche para PHP 5.6 a 8.1, y también lo ofrecen Ubuntu Pro, Freexian ELTS, Zend LTS, Red Hat, Remi y CloudLinux para algunas versiones. Fuera de eso, necesitas un proveedor de soporte extendido o migrar a una versión con soporte.

Dónde ya hay paquetes

Al corte del 22 de octubre a las 14:49 UTC, según el seguimiento de paquetes de Mattias Geniar:

• Ya corregido: el código fuente en php.net, la imagen oficial php de Docker (amd64 y arm64), packages.sury.org en amd64, ppa:ondrej/php, Homebrew, Debian 12 y 13, los paquetes propios de Ubuntu 22.04, 24.04 y 26.04, Remi para RHEL 8, 9 y 10, Gentoo, las compilaciones para Windows, FrankenPHP 1.13.2 y Laravel Herd.
• Parcial: Alpine 3.24 y edge tienen 8.3, 8.4 y 8.5, pero no 8.2. Arch Linux tiene 8.3 y 8.5. En arm64, packages.sury.org todavía no termina las compilaciones de 8.2 a 8.5.
• Todavía no: Amazon Linux 2023 aparece como pendiente, y entornos de desarrollo que traen su propio PHP, como MAMP, XAMPP, Laragon y ServBay 2, siguen en versiones vulnerables.
• Cuidado con las imágenes de prueba: las etiquetas 8.5.12RC1 y 8.4.27RC1 de Docker no traen la corrección, aunque el número lo parezca.

Qué esperar después de actualizar

Las versiones nuevas agregan un límite duro de memoria: el doble de memory_limit cuando este es de 1G o menos (256M con el valor usual de 128M), y memory_limit más 1G cuando es mayor. Un proceso que lo rebasa termina con el código de salida 137. Hay tres problemas conocidos, todavía sin versión que los corrija:

• Cierres con zend_mm_heap corrupted en 8.4.27 y 8.5.12 cuando el recolector de basura limpia objetos de SimpleXML. No viene del parche de seguridad sino de otra corrección incluida en esas versiones; 8.3.36 y 8.2.35 no lo tienen. PHP ya lo corrigió en el código fuente, así que llegará en la siguiente versión.
• Algunos errores de memoria ahora cierran el proceso con el código 137 en lugar del mensaje de siempre ("Allowed memory size exhausted"). Pasa con funciones como sprintf(), pack(), bin2hex() y la extensión xml. Revisa el log de PHP-FPM buscando ese código.
• El progreso de carga puede borrar una sesión, en un caso raro con ciertos objetos guardados en la sesión, y el usuario pierde su inicio de sesión. Si tu aplicación no muestra barras de progreso de carga, puedes dejar session.upload_progress.enabled=0.

Lo que hicimos en nuestros servidores

Parchamos hoy. Dos cosas que nos encontramos y que probablemente te encuentres tú también:

• La imagen de Docker no estaba lista. Docker Hub ya listaba las etiquetas 8.3.36, pero sin la variante linux/amd64. El repositorio docker-library/php ya tenía la receta actualizada, así que construimos la imagen base desde ese Dockerfile (con la verificación de checksum y firma GPG que trae), la etiquetamos localmente, reconstruimos las imágenes de la aplicación sobre ella y las volvimos a desplegar.
• Un 502 después de recrear el contenedor. El nginx que resolvió la dirección de php-fpm al arrancar se quedó con la IP del contenedor viejo. Reiniciar nginx después de recrear la aplicación lo resolvió.
• Se nos escapó un entorno. El primer inventario salió de nuestra documentación, y dejó fuera un entorno de pruebas que también corría PHP. Lo encontramos y lo parchamos el mismo día. La lección: el inventario se hace contra lo que de verdad está corriendo (contenedores, servidores, procesos), no contra la lista que creemos tener.

Si hoy no puedes actualizar

Estas medidas reducen algunos caminos de ataque, pero no hacen seguro un servidor. Úsalas solo mientras el parche está bloqueado:

• memory_limit=-1 fijado con php_admin_value, para que la aplicación no pueda cambiarlo.
• post_max_size en 8M (32M si necesitas subir archivos), con upload_max_filesize por debajo.
• session.upload_progress.enabled=0.
• En PHP 8.5, fatal_error_backtraces=0.
• Límites de memoria por contenedor o cgroup, nunca RLIMIT_AS ni RLIMIT_DATA, que pueden provocar justo la falla vulnerable.
• Límites de tamaño, campos y encabezados de la petición en el proxy o servidor web.
• Reiniciar todos los procesos de PHP después de cualquier cambio de configuración.

Un prompt para tu agente

Si trabajas con un agente de código (Claude Code, Codex o similar), o se lo vas a pasar a quien administra tus servidores, este prompt cubre el inventario, el parche, la verificación y las precauciones.

Necesito parchar las vulnerabilidades críticas de PHP CVE-2026-109618 y CVE-2026-109619 (publicadas el 21 de octubre de 2026) en todos mis entornos. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Trabaja en este orden y reporta lo que observes en cada paso:

1. Inventario. Encuentra cada entorno que ejecuta PHP: servidores, contenedores, imágenes base y procesos auxiliares (workers de colas, schedulers, cron). Búscalos en lo que de verdad está corriendo, no solo en la documentación, e incluye entornos de prueba y de desarrollo. Para cada uno anota la versión exacta (php -v, php-fpm -v) y el SAPI (FPM, mod_php, CGI, FrankenPHP, LiteSpeed, CLI). Muéstrame la tabla antes de cambiar nada.

2. Diagnóstico. Compara cada versión contra las corregidas. Marca como vulnerable todo lo que esté por debajo. Marca aparte PHP 8.1 o anterior: no tiene versión oficial corregida y necesita el parche mínimo de su proveedor (packages.sury.org, ppa:ondrej/php, la distribución o un proveedor de soporte extendido), o una migración. Dime cuáles son esos casos en lugar de improvisar.

3. Respaldo. Antes de tocar cualquier entorno que guarde datos, confirma que hay un respaldo reciente y que se puede restaurar. Si no lo hay, detente y avísame.

4. Actualización. Usa el mecanismo normal de cada entorno: paquetes de la distribución, o reconstruir las imágenes sobre la imagen oficial php ya corregida (descárgala de nuevo; no uses las etiquetas 8.5.12RC1 ni 8.4.27RC1, que no traen la corrección). Si para tu arquitectura todavía no hay imagen corregida, construye la base desde la receta oficial (docker-library/php) verificando el checksum y la firma del código fuente, y nunca uses una imagen de origen desconocido. No cambies otras dependencias de paso.

5. Reinicio. Reinicia todos los procesos de PHP, no solo el servidor web: FPM, workers, schedulers. Si un proxy (nginx u otro) resolvió la dirección del contenedor al arrancar, reinícialo también después de recrear los contenedores, o servirá errores 502.

6. Verificación. Comprueba con observación directa, no por suposición: php -v o php-fpm -v dentro de cada contenedor o servidor debe mostrar la versión corregida, y cada sitio debe responder HTTP 200 en una petición de prueba. Después revisa los logs de PHP-FPM buscando procesos que terminaron con código 137 o errores "zend_mm_heap corrupted": las versiones nuevas agregan un límite duro de memoria y 8.4.27 y 8.5.12 tienen un problema conocido con SimpleXML. Muéstrame la evidencia.

7. Mitigaciones temporales. Solo si un entorno no se puede actualizar hoy, aplica las medidas parciales del aviso oficial (memory_limit=-1 con php_admin_value, post_max_size bajo, session.upload_progress.enabled=0, fatal_error_backtraces=0 en 8.5, límites por cgroup en lugar de RLIMIT_AS o RLIMIT_DATA) y deja claro que no son una solución completa.

Reglas: nunca imprimas ni copies secretos, contraseñas o archivos .env; no borres datos; si algo no está claro o un paso falla, detente y pregúntame. Al final dame un resumen por entorno: versión anterior, versión actual, evidencia de verificación y pendientes.