La versión de PHP que corrige CVE-2026-109618 y CVE-2026-109619 se conocerá el miércoles 21 de octubre de 2026 a las 14:00 UTC, cuando el equipo de seguridad de PHP publique el parche. Mientras tanto, ya puedes comprobar si tu rama de PHP va a recibir la corrección.
Actualización pendiente: al momento de publicar esta nota (21 de octubre de 2026, antes de las 14:00 UTC), PHP todavía no había publicado el parche. Añadiremos aquí la versión corregida de cada rama en cuanto aparezca en php.net.
El anuncio oficial salió en la lista php.announce. En él, el equipo de seguridad de PHP confirma dos vulnerabilidades críticas, cada una con una puntuación CVSS v4.0 de 9.2. El aviso no menciona identificadores CVE, versiones afectadas ni detalles técnicos.
https://news-web.php.net/php.announce/509
¿Qué versión de PHP corrige CVE-2026-109618 y CVE-2026-109619?
Al momento de publicar, todavía ninguna: PHP no había anunciado los números de versión corregidos. Según php.net, las versiones afectadas y las corregidas se publicarán junto con el parche.
Lo que sí puedes hacer ya es identificar tu rama. PHP mantiene cuatro ramas con soporte: 8.2, 8.3, 8.4 y 8.5. Sus versiones más recientes son las de la actualización de seguridad del 24 de septiembre:
| Rama | Última versión antes de este parche | Soporte de seguridad hasta |
|---|---|---|
| 8.5 | 8.5.11 | 31 dic 2029 |
| 8.4 | 8.4.26 | 31 dic 2028 |
| 8.3 | 8.3.35 | 31 dic 2027 |
| 8.2 | 8.2.34 | 31 dic 2026 |
Si tu rama aparece en la tabla, recibirás una corrección. Si no aparece, lee más abajo la sección sobre versiones antiguas.
PHP 8.6.0 sigue en fase de release candidate (RC3, con la RC4 prevista para el 22 de octubre) y no debe usarse en producción.
¿A qué hora sale el parche de seguridad de PHP?
El PHP critical security release está programado para las 14:00 UTC del miércoles 21 de octubre de 2026. En hora local:
| Ciudad | Hora local |
|---|---|
| Ciudad de México | 08:00 |
| Bogotá, Lima | 09:00 |
| Buenos Aires, Santiago | 11:00 |
| Madrid | 16:00 |
Puede llegar antes. El equipo se reservó el derecho de adelantar la publicación si se filtran detalles de alguna de las vulnerabilidades o si detecta explotación activa.
¿Qué se sabe de las vulnerabilidades PHP2Shell?
Oficialmente, muy poco. Conviene separar lo que dijo PHP de lo que están reportando otros.
Confirmado por PHP:
- Son dos vulnerabilidades, ambas de severidad crítica con CVSS v4.0 9.2.
- Habrá una publicación coordinada a las 14:00 UTC.
- El anuncio de PHP no nombra CVE, ni versiones afectadas, ni cómo funcionan los fallos.
Reportado por investigadores, no por PHP:
- Identificadores. CVE-2026-109618 y CVE-2026-109619 aparecieron primero en una publicación de Hacker News que luego fue borrada. Después los repitió watchTowr a BleepingComputer, y figuran en el aviso 2026-018 de CERT-EU.
- Alcance y gravedad. watchTowr afirma que ambas son vulnerabilidades de ejecución remota de código (RCE) que afectan a PHP 5, 6, 7 y 8. La firma les asigna CVSS 10, frente al 9.2 oficial de PHP.
- Estado de la explotación. watchTowr dice haber reproducido CVE-2026-109618. Al 20 de octubre no había observado explotación activa.
- CERT-EU recoge estos reportes. Atribuye la caracterización como RCE a filtraciones, y el alcance “desde PHP 5” a un investigador de seguridad. Recomienda identificar ya las aplicaciones basadas en PHP y, donde no se pueda parchear de inmediato, aislar de la red pública las aplicaciones expuestas a internet.
- Apodo. Los fallos circulan con el nombre no oficial de PHP2Shell.
- Mecanismo. Un análisis de terceros atribuye uno de los fallos a un heap use-after-free en
session.upload_progress. Ni PHP ni CERT-EU lo han confirmado, así que trátalo como no verificado.
¿Cómo saber qué versión de PHP tengo con php -v y phpinfo()?
En la terminal, ejecuta:
php -v
La primera línea muestra la versión y el SAPI, por ejemplo PHP 8.3.35 (cli).
Ojo: el binario php de tu terminal es el CLI. Tu servidor web puede estar ejecutando otra compilación vía PHP-FPM o el módulo de Apache, con otra versión y otro php.ini.
Para ver lo que realmente ejecuta tu sitio, crea temporalmente un archivo con <?php phpinfo(); en la raíz web y ábrelo en el navegador. Luego bórralo de inmediato, porque expone toda tu configuración.
Para ver qué php.ini carga el CLI:
php --ini
¿Instalas PHP con los paquetes de tu distribución de Linux? Entonces la corrección llegará como una actualización de seguridad de la distro, y su número de versión puede no coincidir con el de PHP. Revisa también los avisos de seguridad de tu distribución.
¿Qué pasa si uso PHP 8.1, 7.4 o 5.x?
No vas a recibir una corrección oficial. PHP 8.1 y todas las versiones anteriores están en end of life (fin de soporte), y el proyecto PHP solo parchea las cuatro ramas con soporte.
Si se confirma el alcance reportado (“desde PHP 5”), todo servidor en una rama sin soporte seguirá expuesto después de las 14:00 UTC. Las opciones realistas son:
- migrar a una rama con soporte;
- depender de un proveedor o distribución que aplique backports de seguridad, como hacen algunas distribuciones Linux empresariales;
- aislar la aplicación de internet, como sugiere CERT-EU.
Ten en cuenta que la propia rama 8.2 pierde el soporte de seguridad el 31 de diciembre de 2026, dentro de diez semanas.
¿Hay una mitigación mientras llega el parche?
Hay una medida temporal que está circulando, pero no está confirmada como solución a estas CVE. Varios investigadores sugieren desactivar el seguimiento del progreso de subidas en php.ini:
session.upload_progress.enabled = Off
Dos datos hacen que valga la pena considerarla incluso sin confirmación:
- Viene activada por defecto. El manual indica que su valor por defecto es
1. - El propio manual de PHP ya recomienda desactivarla si no usas barras de progreso de subida. La función escribe en el almacén de sesión los nombres de archivo y de campo que envía el cliente, sin validarlos. Según el manual, eso hace trivial explotar cualquier vulnerabilidad de inclusión local de archivos.
La directiva es INI_PERDIR, así que cámbiala en php.ini, no en tiempo de ejecución con ini_set(). Después recarga PHP-FPM o tu servidor web.
Al momento de publicar esta nota, ni PHP ni CERT-EU habían confirmado que este ajuste bloquee alguna de las dos vulnerabilidades. Úsalo para reducir la exposición, no como sustituto de la actualización.
¿Cómo actualizar PHP cuando salga el parche?
En cuanto se publique, sigue este orden:
- Lee el anuncio de la versión en php.net. Ahí estarán la versión corregida de tu rama y el detalle de las CVE.
- Actualiza primero todo lo que sirve tráfico web. Después, el CLI, los workers y los contenedores. Reconstruye las imágenes Docker que fijan una imagen base de PHP.
- Comprueba la versión que realmente corre. Usa
php -vyphpinfo()en el SAPI web para verificar que es la nueva. - Revisa el ajuste de
session.upload_progress. Si lo desactivaste y tu aplicación usa barras de progreso de subida, decide de forma deliberada si lo vuelves a activar después de parchear.
¿Y tú? ¿Qué versión de PHP corre hoy en tu servidor de producción?
- El mismo día que salga
- Esta semana
- Depende de mi hosting o de mi distribución
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: ¿Tu proyecto usa una versión vulnerable de Handlebars? Cómo comprobarlo y actualizar a 4.7.10