En la misma semana de octubre de 2026 se han publicado parches para dos vulnerabilidades críticas en PHP y para un fallo crítico de autenticación en Laravel. Si tienes aplicaciones PHP en producción, conviene revisarlas cuanto antes.

En este artículo te resumo qué ha pasado, cómo saber si te afecta y qué tienes que actualizar.

Las vulnerabilidades de PHP (CVE-2026-109618 y CVE-2026-109619)

El 21 de octubre de 2026 el equipo de seguridad de PHP publicó nuevas versiones que corrigen dos vulnerabilidades críticas, ambas con una puntuación de 9.2 en CVSS v4.0. Las dos permiten la ejecución remota de código (RCE):

  • CVE-2026-109618: la gestión de errores por falta de memoria puede interrumpir PHP cuando los datos de una petición solo están inicializados en parte.
  • CVE-2026-109619: parte del estado de una petición puede sobrevivir después de liberarse su memoria y llegar a usarse en una petición posterior atendida por el mismo proceso.

Versiones afectadas y corregidas

Rama de PHP Versión corregida
8.5 8.5.12
8.4 8.4.27
8.3 8.3.36
8.2 8.2.35
8.1 y anteriores Sin parche oficial (fuera de soporte)

Según la documentación de Laravel Forge, ambas vulnerabilidades afectan a versiones de PHP muy antiguas, así que cualquier versión es vulnerable hasta que se actualiza. Si todavía tienes aplicaciones en PHP 8.1, 7.x o anteriores, no hay parche oficial: la solución es migrar a una versión con soporte. Algunas distribuciones pueden publicar sus propios parches para versiones antiguas, así que consulta también los avisos de la tuya.

Cómo comprobar tu versión

Conéctate por SSH y comprueba la versión de PHP de la consola y la de PHP-FPM, que es la que atiende las peticiones web:

php -v

# En Debian/Ubuntu, por versión (cambia 8.4 por la tuya)
php8.4 -v
php-fpm8.4 -v

# Ver todas las versiones instaladas (Debian/Ubuntu)
ls /etc/php

Si la versión que aparece es anterior a la de la tabla, tu servidor es vulnerable.

Cómo actualizar PHP

En Laravel Forge. Las actualizaciones de seguridad automáticas de Forge no actualizan PHP, porque PHP se instala desde un repositorio propio y no desde los repositorios de seguridad de Ubuntu. Tienes que hacerlo tú en cada servidor: en el panel del servidor, pestaña PHP, abre el menú de cada versión y pulsa Update PHP X.X. Repítelo con todas las versiones instaladas, incluidas las que no usen tus sitios.

En un servidor Ubuntu propio (con el repositorio de Ondřej Surý):

sudo apt-get update
apt-cache policy php8.4-fpm   # el "Candidate" debe ser la versión corregida

sudo apt-get install --only-upgrade -y \
  -o Dpkg::Options::="--force-confold" \
  $(dpkg -l 'php8.4*' | awk '/^ii/ {print $2}')

Si el Candidate todavía no es la versión corregida, el paquete aún no ha llegado al repositorio: espera un poco y vuelve a intentarlo.

En servidores con CentOS, Rocky o AlmaLinux (repositorio Remi o paquetes de la distribución), actualiza los paquetes de PHP con dnf y comprueba igualmente que la versión instalada es la corregida. Los repositorios de terceros pueden tardar algo más que los oficiales en publicar el parche.

En Laravel Cloud y Vapor, según los avisos de Laravel, las aplicaciones se han parcheado o redesplegado automáticamente. Si usas tus propias imágenes Docker, actualiza la imagen base y redespliega.

No olvides reiniciar los procesos largos

La actualización reinicia PHP-FPM, pero los procesos que se lanzan desde la consola siguen ejecutando la versión antigua hasta que se reinician: colas, Horizon, Octane, Reverb…

php artisan queue:restart
php artisan horizon:terminate
php artisan octane:reload

¿Y si no puedo actualizar ahora mismo?

Como medida temporal se ha recomendado desactivar en php.ini el seguimiento del progreso de subida de archivos:

session.upload_progress.enabled = Off

Esta medida reduce parte del ataque, pero no lo evita por completo. No sustituye a la actualización.

El fallo del token guard de Laravel

Laravel también ha publicado un aviso crítico (CVSS 9.2) que afecta al guard de autenticación de tipo token (Illuminate\Auth\TokenGuard).

Qué permite: en aplicaciones con MySQL o MariaDB, un atacante sin autenticar podía enviar una credencial que no es una cadena de texto, especialmente preparada, y la consulta a la base de datos acababa coincidiendo con un usuario existente. Es decir, podía iniciar sesión como otro usuario sin conocer su token.

A quién afecta:

  • Aplicaciones con un guard configurado con 'driver' => 'token' en config/auth.php.
  • Con base de datos MySQL o MariaDB.
  • Con Laravel anterior a 12.68.0 (rama 12) o anterior a 13.29.0 (rama 13).

Sanctum y Passport no están afectados, porque registran sus propios guards.

La corrección añade una comprobación is_string() antes de consultar la base de datos, de modo que los valores que no son texto se rechazan.

En las mismas versiones se ha corregido un segundo fallo, de gravedad media (CVSS 6.5), que podía provocar pérdida de datos en el soporte de JSON:API. Afecta a las versiones de la 12.45.0 a la anterior a 12.68.0 y a las anteriores a 13.27.0.

Cómo comprobarlo y actualizar

  1. Busca si usas el guard token:

    grep -n "'driver' => 'token'" config/auth.php

  2. Comprueba tu versión de Laravel:

    php artisan --version

  3. Actualiza el framework y revisa el resto de dependencias:

    composer update laravel/framework
composer audit

composer audit compara las dependencias instaladas con los avisos de seguridad publicados. Es una buena costumbre ejecutarlo de forma periódica, no solo cuando sale una noticia como esta.

Checklist rápida

  • PHP actualizado a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 (consola y PHP-FPM).
  • Procesos de colas, Horizon u Octane reiniciados.
  • Ninguna aplicación en PHP 8.1 o anterior expuesta a internet.
  • Laravel en 12.68.0 / 13.29.0 o superior.
  • composer audit sin avisos pendientes.

Si gestionas varios servidores o aplicaciones y quieres ayuda para revisarlos o actualizarlos, escríbeme y lo vemos.

Fuentes