El 21 de octubre de 2026 se ha convertido en una fecha importante para los administradores de sistemas que trabajan con PHP. Dos nuevas vulnerabilidades críticas, identificadas como CVE-2026-109618 y CVE-2026-109619, han puesto en alerta a la comunidad de ciberseguridad por su potencial para permitir la ejecución remota de código (RCE).
Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619
Ambas vulnerabilidades afectan al núcleo de PHP y han recibido una puntuación de 9,2 sobre 10 en CVSS v4.0.
«The report describes it as affecting every PHP version from PHP 5 onward, though no official vendor advisory has confirmed the scope, the technical cause, or a fixed version.
Según las alertas publicadas, podrían permitir la ejecución remota de código sin autenticación previa, lo que supone un riesgo especialmente importante para aplicaciones accesibles desde Internet.
Entre las posibles consecuencias se encuentran:
- Ejecución de código malicioso en el servidor.
- Acceso no autorizado a información sensible.
- Compromiso de aplicaciones y servicios.
- Posible escalada del impacto hacia otros recursos de la infraestructura.
La alerta afecta potencialmente a un gran número de aplicaciones desarrolladas con PHP, incluyendo plataformas como WordPress, Drupal y otros CMS.
El equipo oficial de PHP anunció una publicación extraordinaria de seguridad para el 21 de octubre de 2026, a las 14:00 UTC. En el momento de redactar este artículo, todavía estaba pendiente la confirmación técnica definitiva sobre las versiones afectadas y corregidas.
AWS Elastic Beanstalk
AWS publicó el 8 de octubre de 2026 una actualización de sus plataformas Elastic Beanstalk basadas en Amazon Linux 2023.
Entre las mejoras de la versión 4.13.10 encontramos:
- Actualización de la AMI base de Amazon Linux 2023.
- Incorporación de parches de seguridad publicados hasta el 30 de septiembre.
- Actualización de Nginx a la versión
1.30.5. - Actualización de CloudWatch Agent.
- Actualizaciones de diversos runtimes y componentes.
Sin embargo, si analizamos específicamente la plataforma PHP 8.3, encontramos un detalle importante:
| Componente | Beanstalk 4.13.6 | Beanstalk 4.13.10 |
|---|---|---|
| Amazon Linux | AL2023 | AL2023 |
| AMI | 2023.12.20260803 | 2023.12.20260930 |
| PHP | 8.3.33 | 8.3.33 |
| Nginx | 1.30.4 | 1.30.5 |
La versión de PHP permanece exactamente igual.
Por tanto, aunque actualizar a 4.13.10 resulta recomendable para incorporar otras correcciones, esta actualización no contiene los parches específicos anunciados para las nuevas vulnerabilidades de PHP.
La razón es sencilla: AWS publicó esta plataforma antes de que estuvieran disponibles esas correcciones.
¿Qué ocurre con las instancias EC2 gestionadas por Elastic Beanstalk?
Aquí aparece una de las particularidades más importantes de la arquitectura de Elastic Beanstalk.
Aunque trabajemos con un servicio administrado, nuestras aplicaciones continúan ejecutándose sobre recursos de infraestructura, entre ellos instancias Amazon EC2.
En una plataforma tradicional de PHP sobre Amazon Linux 2023, la arquitectura simplificada sería:
Internet
|
CloudFront
(opcional)
|
Elastic Beanstalk
|
Amazon EC2
|
Amazon Linux
|
Nginx
|
PHP-FPM
|
WordPressElastic Beanstalk administra buena parte del ciclo de vida de estos recursos, pero eso no significa que AWS aplique inmediatamente cualquier parche publicado por los desarrolladores de PHP.
¿Cómo se actualizan estas EC2 en AWS Beanstalk?
Cuando AWS publica una nueva versión de plataforma, normalmente proporciona una AMI y un conjunto actualizado de componentes.
Dependiendo de la política de actualización configurada, Elastic Beanstalk puede reemplazar las instancias EC2 existentes por otras que utilizan la nueva plataforma.
En las actualizaciones administradas de plataforma, AWS utiliza un proceso immutable, creando nuevas instancias antes de retirar las anteriores.
Pero hay dos aspectos fundamentales:
1. Actualizar Amazon Linux no significa actualizar automáticamente PHP a una versión corregida.
Podemos tener todos los parches disponibles del sistema operativo y, sin embargo, mantener una versión de PHP vulnerable si la plataforma todavía no incorpora su corrección.
2. Modificar directamente una EC2 no es una solución de mantenimiento permanente.
Aunque técnicamente podamos conectarnos a una instancia e instalar paquetes manualmente, esos cambios pueden desaparecer cuando Elastic Beanstalk sustituya la máquina.
Por este motivo, cualquier personalización persistente debe formar parte de un mecanismo reproducible de despliegue.
¿Qué podemos hacer mientras esperamos el parche?
Hasta disponer de una versión corregida y confirmada oficialmente, las medidas deben centrarse en reducir la superficie de exposición.
En casos donde no pueda aplicarse una corrección y el riesgo de exposición sea elevado, CERT-EU recomienda considerar el aislamiento temporal de las aplicaciones accesibles desde Internet.
No conviene aplicar cambios arbitrarios en php.ini y asumir que solucionan estas vulnerabilidades: todavía no se ha confirmado una mitigación específica y fiable.
Fuentes
- AWS — Elastic Beanstalk, actualización del 8 de octubre de 2026
- AWS — Elastic Beanstalk, actualización del 11 de agosto de 2026
- PHP — Anuncio oficial de la actualización crítica de seguridad
- CERT-EU — Security Advisory 2026-018
- watchTowr — CVE-2026-109618 y CVE-2026-109619
¿Te ha ayudado este artículo?
☕ Invítame a un café