Alertas

Vulnerabilidades críticas detectadas en PHP

21 Oct 2026

Vulnerabilidad crítica - 21/10

Introducción

CVE-2026-109618 y CVE-2026-109619 son dos vulnerabilidades críticas en el núcleo de PHP, el lenguaje de servidor sobre el que funcionan WordPress, Drupal, Magento y la mayor parte del alojamiento compartido. Al tener PHP ese alcance, un fallo explotable en remoto afecta a una gran proporción de las aplicaciones web expuestas a Internet. Ambas se han descrito como de ejecución remota de código (RCE). El equipo de seguridad de PHP ha asignado a las dos una puntuación CVSS v4.0 de 9,2 (Crítico). Todavía no se ha publicado una puntuación CVSS 3.1 ni el vector completo. Para el vector AV/AC/PR/UI, el ámbito y la tríada CIA hay que consultar el advisory del fabricante cuando se publique.

CERT-EU señala que la severidad apunta a una posible RCE sin autenticación, pero PHP no lo ha confirmado. Si se confirmara, el impacto sería total en confidencialidad, integridad y disponibilidad: el atacante ejecutaría código con los privilegios del proceso PHP.

Fuentes secundarias aseguran que ambas son RCE y que se ha reproducido CVE-2026-109618, aunque no publicará detalles técnicos hasta que haya parches. Junto al aviso se filtró también una captura de una herramienta de explotación llamada PHP2Shell, atribuida a Calif.IO. A 21 de octubre de 2026 no consta explotación activa. Las vulnerabilidades no figuran en el catálogo CISA KEV. La corrección está programada para hoy: PHP publicará las versiones corregidas el 21 de octubre de 2026 a las 14:00 UTC, y podría adelantarlas si los detalles se hacen públicos o se detecta explotación.

Análisis

CVE-2026-109618 es una vulnerabilidad que fuentes públicas describen como una RCE que afecta a PHP desde la versión 5, y Florian Roth la sitúa en el núcleo de PHP. El registro del CVE sigue reservado y no se conoce una PoC pública. Tenable indica que, si se encadena con otra vulnerabilidad de PHP, permitiría ejecución remota de código, y que Calif ha llamado a esa cadena «php2shell».

CVE-2026-109619 es la segunda vulnerabilidad que CERT-EU vincula a la misma publicación de seguridad. También se describe como una RCE que afecta a PHP desde la versión 5. Su registro sigue reservado, PHP no ha dado detalles técnicos y no se conoce una PoC pública. PHP no ha dicho si los dos fallos están relacionados ni si pueden encadenarse.

No hay información verificable en cuanto al mecanismo técnico de la explotación. Phoenix Security añade que el salto del use-after-free a ejecución de código se afirma pero no se demuestra, y que no puede confirmarse la correspondencia con los CVE. Por eso, esta atribución debe tratarse como no confirmada.

En cuanto a explotabilidad e impacto, dado que el fallo está en el propio intérprete y no en una dependencia elegida por el usuario, cualquier petición que llegue al intérprete en las condiciones adecuadas podría desencadenarlo. Si la explotación tuviera éxito, el atacante obtendría ejecución de código en el servidor web. Los escenarios previsibles son la toma de cuentas en CMS y plataformas de comercio, el robo de credenciales de aplicación y de nube, el movimiento lateral desde el servidor web hacia redes internas y la persistencia mediante web shells.

La medida prioritaria y definitiva es actualizar PHP a las versiones corregidas en cuanto se publiquen y reiniciar PHP-FPM o el servidor web para que cargue el nuevo intérprete. El fallo debe corregirse en la infraestructura, actualizando PHP en los servidores; no se puede corregir desde el código de la aplicación. Hasta entonces, LAB52 recomienda elaborar un inventario completo de intérpretes PHP, incluidos paquetes del sistema, imágenes de contenedor, appliances y alojamiento gestionado; no exponer a Internet las aplicaciones PHP que no lo necesiten y limitar su acceso mediante VPN, ZTNA o listas de IP permitidas; aislar las aplicaciones expuestas que no puedan parchearse con rapidez, aplicar el mínimo privilegio a la cuenta que ejecuta PHP y, mientras no haya firmas específicas, centrar la monitorización en el comportamiento posterior a la explotación.

Versiones afectadas

Consultar el advisory del fabricante para conocer el detalle de las versiones vulnerables. Según la información pública previa al parche:

Ramas 8.2, 8.3, 8.4 y 8.5: según las fuentes públicas, todas afectadas, incluidas las versiones actuales 8.5.11, 8.4.26, 8.3.35 y 8.2.34.

Ramas 8.0 y 8.1: PHP no ha anunciado si recibirán corrección.

PHP 5 y PHP 7 (fuera de soporte): según las fuentes, todas las versiones afectadas, sin corrección prevista.

Versiones corregidas no confirmadas: se han apuntado 8.5.12, 8.4.27, 8.3.36 y 8.2.35, pero proceden de una sola fuente y deben verificarse en las notas oficiales.

Recomendaciones

Aplicar con carácter urgente la actualización oficial de PHP que corrige CVE-2026-109618 y CVE-2026-109619, prevista para el 21 de octubre a las 14:00 UTC (16:00 CEST). Empezar por los servidores expuestos a Internet y reiniciar PHP-FPM o el servidor web después de actualizar.

Consultar el aviso de PHP y el advisory 2026-018 de CERT-EU para confirmar las versiones afectadas y corregidas. Coordinar con los proveedores de alojamiento y con los mantenedores de las distribuciones Linux cuándo publicarán sus paquetes corregidos.

Hasta poder parchear, aplicar controles compensatorios: restringir a redes de confianza o de administración las aplicaciones PHP que no necesiten ser públicas, aislar las expuestas que no puedan actualizarse y tener reglas WAF preparadas para cuando se publiquen indicadores.

Revisar el inventario de activos para localizar todas las instalaciones de PHP (servidores, imágenes de contenedor, runners de CI/CD y productos de terceros que lo incluyan) y registrar su versión y su SAPI. Migrar a una rama soportada los sistemas con PHP 5, 7, 8.0 u 8.1.

Monitorizar registros y telemetría de los servidores web para detectar posibles intentos de explotación. En particular, vigilar procesos hijo inesperados de php-fpm o apache2 (shells, curl, wget), ficheros PHP nuevos u ofuscados en los directorios web y conexiones salientes anómalas.

Cuando se publiquen el parche y su diff, revisar los indicadores y tratar como posibles incidentes las instancias que hayan estado expuestas y sin parchear.

Workarounds

PHP no ha publicado workarounds para ninguna de las dos vulnerabilidades e indica que los detalles completos, las versiones afectadas y las corregidas llegarán con la actualización. No existen workarounds completos conocidos. Las únicas medidas parciales son reducir la exposición en red (VPN, listas de IP permitidas, aislamiento o desconexión temporal de las aplicaciones expuestas) y deshabilitar los endpoints y SAPI que no se usen. Estas medidas no sustituyen al parche oficial.

Referencias

https://www.php.net/archive/2026.php#2026-10-20-1

https://cert.europa.eu/publications/security-advisories/2026-018/

https://nvd.nist.gov/vuln/detail/CVE-2026-109618

https://nvd.nist.gov/vuln/detail/CVE-2026-109619

https://www.tenable.com/cve/CVE-2026-109618

https://seclists.org/oss-sec/2026/q4/266

https://labs.beazley.security/advisories/BSL-A1233

https://sansec.io/research/php2shell

https://watchtowr.com/intelligence/php-cve-2026-109618-faq/

Vulnerabilidad crítica - 23/10

Introducción

CVE-2026-115560 es una vulnerabilidad en el intérprete PHP, el lenguaje de servidor sobre el que funcionan plataformas como WordPress o Magento. PHP la comunicó el 23 de octubre mediante un breve aviso informativo, dos días después de la publicación urgente que corrigió los fallos críticos PHP2Shell, CVE-2026-109618 y CVE-2026-109619. Según el proyecto, se trata de un vector de ejecución remota de código (RCE) poco probable, ya que solo afecta a aplicaciones web con una configuración inusual, y PHP no publicará un parche de emergencia, sino que recomienda desactivar la funcionalidad session upload progress hasta la próxima versión ordinaria.

En el momento de redactar este informe no existe puntuación CVSS 3.1 ni vector publicado: PHP no ha indicado las versiones afectadas, las versiones que incluirán la corrección ni una puntuación de severidad. A efectos cualitativos, el impacto potencial descrito es la ejecución de código en el servidor, lo que implicaría compromiso de confidencialidad, integridad y disponibilidad, pero la explotabilidad está fuertemente condicionada por la configuración requerida.

Este fallo es independiente y no queda corregido por las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. No se ha informado de explotación de CVE-2026-115560; los ataques observados desde el 21 de octubre se dirigen a los dos fallos PHP2Shell anteriores. No figura en el catálogo CISA KEV ni se conoce PoC pública.

Análisis

No hay clasificación CWE asignada públicamente. El fallo afecta a la interacción entre el mecanismo de serialización de sesiones y la funcionalidad session upload progress. Para que pueda darse, la aplicación debe configurar session.serialize_handler como php_binary o php_serialize, cambiarlo después a php en tiempo de ejecución con ini_set() antes de invocar session_start(), y mantener habilitado session upload progress. PHP no ha publicado el mecanismo técnico exacto. Tampoco se ha aclarado si comparte causa raíz con CVE-2026-109619.

En cuanto a explotabilidad, el vector sería remoto, ya que session upload progress se activa con peticiones de subida de ficheros. Sin embargo, el requisito de que el propio código de la aplicación cambie el manejador de serialización en tiempo de ejecución reduce drásticamente la superficie real: las aplicaciones que nunca modifican el serialize handler en ejecución pueden mantener la funcionalidad habilitada. El riesgo se concentraría en aplicaciones a medida o heredadas que manipulen la configuración de sesión de forma dinámica. Debe tenerse en cuenta que session upload progress está activada por defecto.

Si se explotara con éxito, el atacante podría ejecutar código con los privilegios del proceso PHP, accediendo a credenciales de base de datos, secretos de configuración, datos de sesión de usuarios y, potencialmente, utilizando el servidor como punto de pivote hacia la red interna. Los servidores web PHP son objetivos de alto valor por su exposición a Internet y su volumen de despliegue.

Al no existir aún parche, la medida prioritaria es aplicar la mitigación oficial y, en cuanto se publique la próxima versión ordinaria de PHP, actualizar. LAB52 recomienda establecer session.upload_progress.enabled=0 en todas las instancias, auditar el código de las aplicaciones en busca de llamadas a ini_set() sobre session.serialize_handler, mantener un manejador de serialización único y fijo en la configuración, aplicar mínimo privilegio al proceso PHP, no exponer innecesariamente a Internet aplicaciones internas y monitorizar peticiones multipart anómalas que incluyan el campo de progreso de subida. Asimismo, dado el contexto de explotación activa de PHP2Shell, debe verificarse que todas las instancias se encuentran en 8.5.12, 8.4.27, 8.3.36 u 8.2.35 o superiores.

Versiones afectadas

Consultar el advisory del fabricante para conocer el detalle de las versiones vulnerables. PHP publicará el advisory completo con la próxima versión ordinaria; las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 no corrigen este fallo.

Recomendaciones

Establecer con carácter urgente session.upload_progress.enabled=0 hasta que PHP publique la versión ordinaria que corrige CVE-2026-115560, y actualizar en cuanto esté disponible.

Consultar el aviso informativo de PHP y seguir la publicación del advisory completo para verificar versiones afectadas y corregidas.

Auditar el código de las aplicaciones para detectar cambios de session.serialize_handler en tiempo de ejecución y eliminarlos, manteniendo un único manejador definido en php.ini.

Revisar el inventario de activos para identificar instalaciones PHP, especialmente las expuestas a Internet, y confirmar que también tienen aplicados los parches de PHP2Shell (8.5.12, 8.4.27, 8.3.36, 8.2.35).

Monitorizar registros del servidor web y de PHP en busca de peticiones multipart/form-data anómalas, errores de deserialización de sesión o creación inesperada de procesos hijo por parte de PHP.

Workarounds

PHP indica que desactivar session upload progress (session.upload_progress.enabled=0) protege completamente frente a este vector; es la misma medida ya recomendada el 21 de octubre en el advisory de CVE-2026-109619, por lo que quien la aplicó entonces y la mantiene no necesita hacer nada más. Alternativamente, no modificar session.serialize_handler en tiempo de ejecución elimina la condición necesaria. Si el cambio se aplica mediante .user.ini, debe tenerse en cuenta que este fichero solo lo leen las versiones CGI y FastCGI de PHP, no el módulo de Apache, y que por defecto se relee cada 300 segundos. Estas medidas no sustituyen a la actualización oficial cuando se publique.