PHP 8.5.8 y 8.4.23: parches de seguridad y por qué toca actualizar (aunque no cunda el pánico)
PHP publica dos versiones de mantenimiento que cierran una corrupción de memoria en openssl_encrypt, un bypass de la protección del directorio .phar y un fallo de la caché de herencia en Opcache. Te contamos cuál importa de verdad, a quién le toca y cómo actualizar sin cortar el servicio.
Dos versiones de mantenimiento, con letra pequeña de seguridad
A principios de mes PHP sacó 8.5.8 y 8.4.23, dos releases de las que se llaman "de mantenimiento" pero que traen correcciones de seguridad que conviene mirar. No hay aquí un CVE de portada con nombre propio ni un exploit corriendo por internet, así que nada de pánico. Pero sí hay tres arreglos que, según lo que tengas montado, van de "a mí no me toca" a "actualiza esta semana".
Si gestionas servidores con PHP —tuyos o de clientes— esto es un repaso de cinco minutos para saber en qué grupo estás.
En una frase
Se cierran tres cosas: una corrupción de memoria en openssl_encrypt al usar el modo AES-WRAP-PAD, un bypass de la protección del directorio mágico .phar, y un fallo en la caché de herencia de Opcache que puede dejar estados inestables bajo carga. La primera es la más seria por naturaleza (corrupción de memoria), pero también la más rara de disparar; las otras dos afectan a más gente aunque con menos ruido.
La buena noticia: se arregla actualizando el paquete y recargando PHP-FPM. Sin reiniciar la máquina.
Los tres arreglos, ordenados por lo que deberías mirar primero
1. Corrupción de memoria en openssl_encrypt (AES-WRAP-PAD)
Es la que más respeto da por lo que es —corrupción del heap—, pero con una condición muy concreta: solo se dispara si ciframos con el modo AES-WRAP-PAD. Es un modo poco habitual (envoltura de claves, no cifrado de datos "del día a día"), así que la mayoría de aplicaciones no lo tocan jamás. Si no usas openssl_encrypt con ese algoritmo, no te afecta; si lo usas para envolver claves, es tu prioridad número uno. Corregida en 8.4.23.
2. Bypass de la protección del directorio .phar
PHP protege de forma especial el directorio "mágico" .phar para evitar accesos indebidos dentro de archivos Phar. Este parche cierra un bypass de esa protección: rutas que empiezan por /.phar se tratan ahora correctamente, sin dejar de respetar los directorios normales que casualmente empiecen por ese prefijo. Te importa si tu aplicación manipula archivos Phar o carga código empaquetado en .phar (algunos frameworks y herramientas de distribución lo hacen). Corregida en ambas versiones.
3. Caché de herencia de Opcache (inheritance cache replay)
El más silencioso pero probablemente el que toca a más gente. Opcache cachea la herencia de clases para no recalcularla en cada petición; bajo autoload reentrante en cargas pesadas, esa caché podía "reproducirse" de forma insegura y dejar estados inestables. No es una puerta de entrada para un atacante, es más bien un fallo de robustez que se nota en aplicaciones grandes con mucha jerarquía de clases y tráfico alto. Corregido en ambas versiones.
A quién afecta
- A todos, en algún grado: cualquier PHP en las ramas 8.5 y 8.4 anterior a estas versiones tiene los tres fallos.
- Prioridad alta: quien use
openssl_encryptconAES-WRAP-PAD(raro, pero si es tu caso, corre) y quien trabaje con archivos Phar. - El resto: te llevas sobre todo la mejora de robustez de Opcache. No es urgente-urgente, pero es una actualización limpia y sin excusa para posponerla meses.
Qué tienes que hacer hoy
Sin rodeos: comprueba versión y actualiza a la de tu rama.
1. Mira qué versión tienes
php -v
- Si vas por la rama 8.5, el objetivo es 8.5.8 o superior.
- Si vas por la rama 8.4, el objetivo es 8.4.23 o superior.
2. Actualiza y recarga PHP-FPM (sin downtime)
# Debian / Ubuntu (repositorio de Ondřej Surý)
sudo apt update && sudo apt install --only-upgrade php8.5 php8.5-fpm
sudo systemctl reload php8.5-fpm
# RHEL / AlmaLinux / Rocky (repositorio Remi)
sudo dnf update php php-fpm
sudo systemctl reload php-fpm
El reload de PHP-FPM aplica el binario nuevo sin cortar las peticiones en curso. Ajusta el número de versión (php8.5 / php8.4) al que tengas instalado.
3. Confirma que quedó aplicado
php -v
php-fpm8.5 -v # o php-fpm -v según tu distro
Como siempre con las distribuciones: a veces backportean el fix manteniendo un número de versión distinto. No te fíes solo del número, mira la fecha del paquete o el changelog de seguridad de tu distro. Es la misma lección de siempre: "está actualizado" se comprueba, no se recuerda.
Lo que hacemos nosotros
En cuanto salen releases de seguridad de PHP, pasamos por los servidores que gestionamos priorizando los que exponen aplicaciones de cara a internet y, dentro de esos, los que casan con el fallo concreto (aquí, cualquiera que toque Phar o cifrado con OpenSSL). Para el resto, entra en la ronda normal de actualizaciones. Lo importante no es correr con cada punto de versión, es tener el plan de parches al día para que una release así sea un trámite de diez minutos y no un pendiente que se arrastra medio año.
La rutina de siempre
php -vpara saber dónde estás.apt/dnf updatede PHP y PHP-FPM.systemctl reload php*-fpm.php -votra vez para confirmar.
Si tu PHP hace meses que no ve un parche, o no tienes claro si usas Phar o openssl_encrypt en algún rincón del código, es buen momento para revisarlo. Y si prefieres que lo llevemos nosotros, hablamos.
Referencias
¿Hablamos de tu caso?
Cuéntanos qué necesitas y te respondemos en menos de 24 horas con una propuesta clara.
Pedir presupuesto