El 4 de noviembre de 2026, Laravel publicó el post-mortem de su respuesta a las versiones de seguridad de PHP y Node.js lanzadas el 21 de octubre. PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos fallas de ejecución remota de código sin autenticación, CVE-2026-109618 y CVE-2026-109619, ambas con nota 9,2 en CVSS v4.0. El informe muestra que el mismo aviso exigió trabajos distintos en cada producto de Laravel, y quién hizo ese trabajo dependió del producto contratado.
Cloud aplicó la corrección; Forge y Vapor devolvieron la tarea al cliente
En Laravel Cloud, la empresa reemplazó el binario de PHP dentro de las aplicaciones en ejecución, sin un nuevo despliegue del cliente. La corrección llegó al 100% de las regiones a las 18:05 UTC del 21 de octubre. Los despliegues nuevos quedaron en pausa de 13:54 a 17:33 UTC. Según Laravel, los clientes de Cloud no tuvieron que hacer nada, y la empresa no encontró indicios de explotación en clientes.
En Forge, el cliente actualiza PHP en cada servidor. La base de conocimiento de Forge advierte que las actualizaciones automáticas de seguridad del producto no incluyen PHP: viene de un repositorio de paquetes propio, y las actualizaciones automáticas de Ubuntu solo aplican el repositorio de seguridad de Ubuntu. Ese día, el volumen de actualizaciones llegó a cerca de diez veces lo normal, la cola dejó los despliegues detenidos y unos 4.800 despliegues se cancelaron entre las 19:30 y las 21:27 UTC. Esos clientes tuvieron que desplegar de nuevo.
En Vapor, Laravel publicó runtimes nuevos, y cada cliente tuvo que volver a desplegar para recibirlos. La orientación cambió durante el incidente: primero la empresa dijo que haría el nuevo despliegue por los clientes, y a las 19:25 UTC pidió que cada cliente desplegara su propia aplicación. Envoyer estuvo fuera de servicio de 13:52 a 22:58 UTC mientras se actualizaban sus propios servidores.
Quién necesita revisar ahora
Quien usa Forge, Vapor o servidores propios con PHP y todavía no verificó la versión instalada. El propio post-mortem reconoce que Laravel no tenía un "registro confiable" de la versión de software de cada aplicación; si el proveedor no lo tenía, vale preguntar si tu equipo lo tiene.
Para los clientes de Cloud, Laravel ya aplicó la corrección de PHP. Para equipos que contratan una agencia o un proveedor, la pregunta útil es de quién es la responsabilidad de actualizar el runtime, y eso debería estar escrito en el contrato de mantenimiento. Es la parte del costo de una plataforma que suele aparecer solo durante un incidente, como comenté en El costo de una herramienta incluye el trabajo de reemplazarla.
Qué hacer y hasta cuándo
Las fallas son públicas desde el 21 de octubre, así que el plazo ya pasó. La secuencia que indica Forge sirve para cualquier servidor Ubuntu con PHP instalado desde esos paquetes:
- Actualizar todas las versiones de PHP instaladas en el servidor, incluso las que ningún sitio usa.
- Reiniciar los procesos de larga duración. Las colas, Horizon, Octane y Reverb siguen ejecutando el PHP anterior hasta reiniciarse, aunque PHP-FPM ya esté con la versión nueva.
- Comprobar con
php -vyphp-fpm -vque la versión corregida está activa.
Para PHP 8.1 o anterior, que ya no recibe versiones oficiales, el mantenedor de los paquetes publicó correcciones como nuevas revisiones. El número de versión no cambia, y solo la revisión del paquete (dpkg -l) muestra si la corrección está instalada. Es una solución provisional; Forge recomienda migrar a una versión con soporte.
En Vapor, volver a desplegar para usar el runtime nuevo y verificar si la aplicación todavía usa el runtime al2, que Laravel marcó como sin soporte y sobre el cual está contactando a los clientes. También entra en la planificación el fin del soporte de PHP 8.2 el 31 de diciembre de 2026, según php.net.
Si la actualización no puede salir hoy, el aviso de PHP enumera mitigaciones parciales, como session.upload_progress.enabled = 0 en la configuración del servidor, y aclara que ninguna deja la instalación segura.
Lo que sigue abierto
Laravel dice que está revisando su política de nuevo despliegue para tener una respuesta escrita sobre qué pasa cuando no puede corregir ni volver a desplegar automáticamente una aplicación. Esa política todavía no se publicó, como tampoco el texto prometido sobre convertir la respuesta en rutina. Del lado de PHP, un aviso del 23 de octubre recomienda desactivar el progreso de carga de sesión hasta la próxima versión de corrección, y el detalle de CVE-2026-115560 solo saldrá con esa versión.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
