El 21 de octubre de 2026 php.net publicó el parche de dos RCE sin autenticación, CVE-2026-109618 y CVE-2026-109619 (CVSS v4.0 9.2). En los contenedores Apache con mod_php de este homelab el cierre fue subir a PHP 8.4.27 el mismo día. En un WordPress de Amazon Lightsail creado con un blueprint de Bitnami el fallo es el mismo y el gesto habitual no sirve: apt upgrade deja el PHP de la web donde estaba.
Ese binario vive en /opt/bitnami/php. La consola puede dar la instancia por al día y /opt/bitnami/php/bin/php -v seguir en 8.2.28. Para cerrar el hueco en la máquina que ya tienes hay que poner al lado el PHP parcheado de la misma rama y decirle a Apache que hable con el socket nuevo.
AWS marca otra salida como la recomendada: mover el sitio a un blueprint empaquetado por Lightsail, donde el PHP sí entra en apt. Los blueprints de Bitnami dejan de ofrecerse el 19 de noviembre de 2026 (WordPress, WordPress Multisite, LAMP, Nginx y Node.js). La instancia ya creada sigue arrancando, y desde una instantánea se puede lanzar otra; lo que se acaba es elegir ese blueprint para una instancia nueva. Si además la rama es 8.2, el proyecto PHP deja de parchearla el 31 de diciembre de 2026. Lo de abajo cierra el aviso de hoy. La migración es otro trabajo.
En corto: instantánea, misma rama, PHP-FPM del repositorio Sury, socket de la base de Bitnami, los límites de subida del php.ini viejo, Apache apuntando a ww2.sock, y la versión comprobada por HTTP. Sury (packages.sury.org) es un tercero. No lo mantiene AWS.
Qué corrige el parche de PHP en Lightsail
El aviso del 21 de octubre documenta los dos fallos. El detalle de por qué duelen en mod_php está en el post del homelab; aquí basta el alcance:
| CVE | Qué pasa |
|---|---|
| CVE-2026-109618 | Si PHP se queda sin memoria a mitad de una petición, puede dejar datos internos de esa petición a medias y la limpieza posterior los trata como válidos |
| CVE-2026-109619 | Estado de una petición que sigue usable después de liberar su memoria, en un worker que atiende la petición siguiente |
Los dos permiten ejecutar código en el servidor sin autenticarse, en cualquier despliegue que sirva la web con PHP. PHP-FPM entra. No hace falta un usuario de WordPress.
Versiones que contienen el arreglo:
| Rama | Versión parcheada |
|---|---|
| 8.2 | 8.2.35 o posterior |
| 8.3 | 8.3.36 o posterior |
| 8.4 | 8.4.27 o posterior |
| 8.5 | 8.5.12 o posterior |
Quédate en la rama que ya corre el sitio. Un WordPress en 8.2 pasa a 8.2.35 o a un parche posterior de 8.2, no a 8.3 ni a 8.4. El salto de rama es un cambio de temas y plugins, y encaja mejor el día que muevas el sitio al blueprint nuevo.
El 23 de octubre PHP publicó un aviso aparte, CVE-2026-115560. 8.2.35, 8.3.36, 8.4.27 y 8.5.12 no lo corrigen. El arreglo va en el siguiente bugfix. La vía que describe el proyecto es estrecha: session.serialize_handler tiene que estar en php_binary o php_serialize, el código lo cambia a php con ini_set() antes de session_start(), y el progreso de subida por sesión sigue activo. Un WordPress que no toca el manejador de sesión en tiempo de ejecución no está en ese caso. Aun así, PHP pide session.upload_progress.enabled = 0 hasta esa release. Lo que se pierde es el progreso de subida vía $_SESSION. La biblioteca de medios no depende de eso. Esta guía lo deja en 0.
Amazon lo publica en Actualizar PHP en instancias de Lightsail. En esa página hay dos avisos suyos: el repositorio Sury no es de AWS ni lo mantiene, y las versiones de la tabla no corrigen CVE-2026-115560. El camino que marcan como recomendado es el blueprint de Lightsail. Si la instancia no se mueve, la alternativa que documentan es la de este post.
Por qué apt upgrade no toca el PHP de Bitnami
Hay dos familias de instancia y se parchean distinto. Mirar el nombre en la consola antes de pegar comandos:
| Quién empaquetó la imagen | Dónde está el PHP | Cómo se parchea |
|---|---|---|
| Lightsail (WordPress, LAMP, Nginx) | Paquetes del sistema | apt upgrade y reinicio del servicio |
| Bitnami | /opt/bitnami/php, copia propia |
El procedimiento de esta guía |
En la segunda, Debian puede quedar al día y el PHP que ejecuta WordPress seguir siendo el vulnerable. php -v a secas tampoco zanja la duda: Bitnami pone /opt/bitnami/php/bin delante en el PATH, así que la shell sigue enseñando el binario viejo después del cambio. La versión que importa es la que responde por HTTP.
Instalar desde Sury es un cambio de confianza, no un parche de AWS. La guía de Lightsail lo marca así: el repositorio es de un tercero. Los repos de Debian llevan una sola rama de PHP; Sury publica las demás. A partir de aquí, apt upgrade trae el PHP de ese repositorio.
Antes de tocar el PHP de WordPress
En la consola de Lightsail, pestaña Instantáneas, crea una instantánea y espera a que figure como disponible.
Entra por SSH con el usuario bitnami. Anota la rama, los módulos cargados y los cuatro límites que devuelve el PHP de Bitnami desde la terminal. Ese php -i es el de la CLI: puede coincidir con el FPM que atendía WordPress, pero el comando no lo demuestra. El php.ini nuevo trae los de Debian, cortos para subir medios (en el de producción: upload_max_filesize 2M, post_max_size 8M, memory_limit 128M).
/opt/bitnami/php/bin/php -v
/opt/bitnami/php/bin/php -m
/opt/bitnami/php/bin/php -i | grep -E '^(memory_limit|post_max_size|upload_max_filesize|max_execution_time) '
sudo /opt/bitnami/ctlscript.sh status
ls -l /opt/bitnami/mariadb/tmp/mysql.sock
En esta instalación php -m listaba imagick y memcached. Sin ellas en el PHP nuevo, las imágenes o la caché de objetos dejan de funcionar. El socket de MariaDB tiene que existir: el fichero solo está cuando la base está en marcha. En una instancia antigua con MySQL, la ruta es /opt/bitnami/mysql/tmp/mysql.sock.
Los comandos de abajo van en la misma sesión SSH. PHP_VERSION se calcula una vez (en un 8.2.28 queda 8.2) y el resto de pasos la reutilizan.
1. Instalar el PHP de la misma rama
PHP_VERSION=$(/opt/bitnami/php/bin/php -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;')
echo "Installing PHP ${PHP_VERSION}"
sudo apt update
sudo apt install -y ca-certificates curl gnupg lsb-release
curl -fsSL https://packages.sury.org/php/apt.gpg | sudo gpg --dearmor -o /usr/share/keyrings/sury-php.gpg
echo "deb [signed-by=/usr/share/keyrings/sury-php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list > /dev/null
sudo apt update
sudo apt install -y --no-install-recommends \
php${PHP_VERSION}-fpm php${PHP_VERSION}-cli php${PHP_VERSION}-mysql \
php${PHP_VERSION}-curl php${PHP_VERSION}-gd php${PHP_VERSION}-mbstring \
php${PHP_VERSION}-xml php${PHP_VERSION}-zip php${PHP_VERSION}-intl \
php${PHP_VERSION}-bcmath php${PHP_VERSION}-bz2 php${PHP_VERSION}-gmp \
php${PHP_VERSION}-ldap php${PHP_VERSION}-soap php${PHP_VERSION}-sqlite3 \
php${PHP_VERSION}-tidy php${PHP_VERSION}-opcache php${PHP_VERSION}-xsl \
php${PHP_VERSION}-imagick php${PHP_VERSION}-memcached
--no-install-recommends evita instalar paquetes recomendados que no hacen falta, y con eso baja el riesgo de meter otro Apache al lado del de Bitnami. No frena una dependencia obligatoria. opcache va en el conjunto base: sin él el sitio se arrastra. imagick y memcached iban en el mismo apt porque esta instalación las tenía cargadas.
Antes de tocar Apache, el binario nuevo tiene que ser ya el parcheado. php -v todavía puede mentir; pregunta al de /usr/bin:
/usr/bin/php${PHP_VERSION} -v
Tiene que ser 8.2.35, 8.3.36, 8.4.27, 8.5.12 o un parche posterior de esa misma rama. Si sale más viejo, para aquí: Sury aún no tiene el paquete, y cambiar el socket solo movería WordPress a otro PHP vulnerable.
2. Socket de la base, límites de subida y CVE-2026-115560
En esta instalación, el PHP nuevo necesitaba el socket de MariaDB de Bitnami para seguir conectando con la base de datos.
Los cuatro límites son los anotados del PHP que ya servía el sitio. En estas imágenes lo habitual es memory_limit 512M, post_max_size y upload_max_filesize 80M, max_execution_time 30. Si los tuyos son otros, sustitúyelos: manda lo que anotaste, no el ejemplo.
session.upload_progress.enabled = 0 es la mitigación de CVE-2026-115560 hasta el siguiente bugfix. Va en el php.ini, no en un ini_set() de WordPress: tiene que aplicarse antes de que PHP interprete la petición.
DB_SOCKET=/opt/bitnami/mariadb/tmp/mysql.sock
sudo sed -i -E \
"s|^;?\s*pdo_mysql.default_socket\s*=.*|pdo_mysql.default_socket = ${DB_SOCKET}|; \
s|^;?\s*mysqli.default_socket\s*=.*|mysqli.default_socket = ${DB_SOCKET}|; \
s|^;?\s*memory_limit\s*=.*|memory_limit = 512M|; \
s|^;?\s*post_max_size\s*=.*|post_max_size = 80M|; \
s|^;?\s*upload_max_filesize\s*=.*|upload_max_filesize = 80M|; \
s|^;?\s*max_execution_time\s*=.*|max_execution_time = 30|; \
s|^;?\s*session.upload_progress.enabled\s*=.*|session.upload_progress.enabled = 0|" \
/etc/php/${PHP_VERSION}/fpm/php.ini
grep -E '^(pdo_mysql|mysqli)\.default_socket|^memory_limit|^post_max_size|^upload_max_filesize|^max_execution_time|^session.upload_progress.enabled' \
/etc/php/${PHP_VERSION}/fpm/php.ini
El grep es la comprobación. Tiene que mostrar el socket de Bitnami, los cuatro límites y session.upload_progress.enabled = 0. Si falta una línea, ese sed no la ha escrito: no crea directivas que no estaban.
3. Un pool de PHP-FPM para el usuario de Bitnami
Apache de Bitnami habla con PHP por un socket de Unix y el worker corre como daemon. El pool nuevo escucha en ww2.sock para no pisar www.sock.
Se dejó pm.max_children = 5, el valor de la guía de AWS. Ese número no significa que cada proceso vaya a ocupar lo que marca memory_limit.
sudo tee /etc/php/${PHP_VERSION}/fpm/pool.d/bitnami.conf > /dev/null <<'EOF'
[bitnami]
listen = /opt/bitnami/php/var/run/ww2.sock
user = daemon
group = daemon
listen.owner = daemon
listen.group = daemon
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 5000
EOF
sudo systemctl enable php${PHP_VERSION}-fpm
sudo systemctl restart php${PHP_VERSION}-fpm
ls -l /opt/bitnami/php/var/run/ww2.sock
ww2.sock tiene que existir y pertenecer a daemon. Si el reinicio falla, el corte de Apache del paso siguiente dejaría la web sin PHP: no sigas.
4. Apuntar Apache de Bitnami al socket nuevo
/opt/bitnami/apache2 en estas imágenes es un enlace a /opt/bitnami/apache; la ruta de abajo es la configuración que está en uso. El bucle deja una copia .bak junto a cada fichero que reescribe.
for f in $(sudo grep -rl '/opt/bitnami/php/var/run/www.sock' /opt/bitnami/apache2/conf); do
sudo cp "$f" "$f.bak"
sudo sed -i 's|/opt/bitnami/php/var/run/www.sock|/opt/bitnami/php/var/run/ww2.sock|g' "$f"
done
sudo grep -n 'ww2.sock' /opt/bitnami/apache2/conf/bitnami/php-fpm.conf
sudo /opt/bitnami/ctlscript.sh restart apache
El grep tiene que mostrar ww2.sock y el reinicio tiene que acabar en Restarted apache. Si el grep no muestra ww2.sock, no continúes: no se ha confirmado el cambio de socket. El bucle en sí no imprime los ficheros que toca.
5. Comprobar el PHP de la web, no el de la terminal
DOCROOT=/opt/bitnami/wordpress
echo '<?php echo PHP_VERSION, " ", PHP_SAPI, " ", php_ini_loaded_file();' | sudo tee "$DOCROOT/v.php" > /dev/null
curl -s http://localhost/v.php; echo
sudo rm -f "$DOCROOT/v.php"
Una línea sana se parece a esto:
8.2.35 fpm-fcgi /etc/php/8.2/fpm/php.ini
Tiene que ser la versión parcheada de tu rama, el SAPI fpm-fcgi y un php.ini bajo /etc/php/. Si la ruta sigue siendo /opt/bitnami/php, Apache no ha cambiado de socket. Borra v.php siempre, también si la prueba falla.
Abre la portada y /wp-admin. En el escritorio: Herramientas → Salud del sitio → Información → Servidor. La versión de PHP tiene que coincidir y la API del servidor tiene que decir FPM/FastCGI.
Una versión correcta no demuestra que WordPress funcione. Después del corte conviene un login, una página que lea la base y subir un medio: es lo que rompe si los límites se quedaron en los de Debian o si faltaba imagick.
Para que la propia shell use el PHP nuevo. Ese echo añade la línea cada vez que lo lanzas:
echo 'export PATH="/usr/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
hash -r
php -v
A partir de aquí, sudo apt update y sudo apt upgrade traen los siguientes parches de esta rama. El binario de /opt/bitnami/php se queda instalado. La petición de prueba ya no lo usa; eso no dice que ningún otro proceso de la instancia siga llamándolo.
Qué no cierra este procedimiento
No mueve el sitio a un blueprint de Lightsail. Esa es la salida para que el próximo aviso sea un apt upgrade, y es un cambio aparte: instancia nueva, copia de ficheros y de la base, y pasar la IP estática. AWS lo describe en Migrating from Bitnami blueprints to Lightsail blueprints.
Tampoco alarga PHP 8.2 más allá del 31 de diciembre de 2026. Después de esa fecha la rama no recibe parches del proyecto PHP. Sury ha publicado arreglos de ramas ya fuera de soporte en otros avisos; no es un compromiso de que vaya a hacerlo con la 8.2.
Y no convierte el repositorio de Sury en infraestructura de AWS. El paquete que sirve WordPress, desde este cambio, lo firma y lo publica un tercero.
Cierre
El PHP que importa es el que responde en la portada, no el primero del PATH. Si esa respuesta muestra la versión corregida, fpm-fcgi y un php.ini bajo /etc/php/, esa petición ya utiliza el PHP parcheado.
Lo que sigue abierto es otro plazo. Bitnami ya no es el sitio donde van a caer los próximos parches con un apt upgrade, y la 8.2 tiene fecha. El blueprint de Lightsail es ese cambio. Este procedimiento evita llegar a él con el RCE todavía servido en la web que acabas de comprobar.
