El equipo de seguridad de PHP ha anunciado una actualización extraordinaria para corregir dos vulnerabilidades críticas que podrían permitir la ejecución remota de código en servidores afectados. Los fallos, identificados provisionalmente como CVE-2026-109618 y CVE-2026-109619, presentan una puntuación CVSS v4.0 de 9,2 cada uno. Se recomienda a las organizaciones identificar sus instalaciones de PHP y preparar la aplicación inmediata de las correcciones oficiales.
El equipo responsable del desarrollo y mantenimiento de PHP ha comunicado la próxima publicación de actualizaciones de seguridad destinadas a corregir dos vulnerabilidades críticas que afectan al entorno de ejecución utilizado por numerosas aplicaciones y servicios web.
La publicación está prevista para el 21 de octubre de 2026 a las 16:00 horas, horario peninsular español, aunque el equipo de PHP ha indicado que podría adelantarse si se divulgan detalles adicionales o aparecen evidencias de explotación activa.
Los análisis técnicos preliminares relacionan estas vulnerabilidades con posibles escenarios de ejecución remota de código (RCE). Este tipo de fallo puede permitir que un atacante ejecute instrucciones no autorizadas en el servidor afectado, con consecuencias que dependerán de los privilegios del proceso comprometido y de la configuración de seguridad del sistema.
PHP es una tecnología ampliamente utilizada para desarrollar y ejecutar aplicaciones web. Su presencia es habitual en portales corporativos, páginas institucionales, plataformas de comercio electrónico, sistemas de gestión de contenidos y servicios digitales de administraciones públicas y empresas.
Entre las plataformas que utilizan PHP se encuentran WordPress, Drupal, Joomla, Magento, Adobe Commerce, WooCommerce y Shopware. No obstante, la utilización de estas soluciones no implica necesariamente que todas sus instalaciones sean explotables. El riesgo efectivo dependerá de la versión de PHP utilizada, la configuración del servidor y las condiciones técnicas de las vulnerabilidades que confirme el fabricante.
Una característica especialmente relevante de esta situación es que los fallos se encuentran en el propio intérprete PHP y no exclusivamente en las aplicaciones desarrolladas sobre él. Por tanto, actualizar únicamente un gestor de contenidos, sus extensiones o sus complementos no garantiza la eliminación de estas vulnerabilidades.
La información disponible indica que se han difundido detalles preliminares antes de la publicación coordinada de las correcciones. Esta circunstancia incrementa la necesidad de actuar preventivamente, aunque todavía no se dispone de una caracterización oficial completa de los vectores de explotación ni de su alcance.
Vulnerabilidades identificadas
Se han difundido los siguientes identificadores asociados a las vulnerabilidades.
| Identificador | CVSS v4.0 | Impacto potencial |
| CVE-2026-109618 | 9,2 · Crítica | Ejecución remota de código |
| CVE-2026-109619 | 9,2 · Crítica | Ejecución remota de código |
El equipo de PHP ha confirmado la existencia de dos vulnerabilidades críticas con puntuación CVSS v4.0 de 9,2. La asociación de los identificadores CVE y los detalles sobre ejecución remota de código proceden de los análisis y comunicaciones técnicas difundidos antes del aviso definitivo.
El fabricante ha señalado que publicará la información completa sobre las vulnerabilidades, las versiones afectadas y las versiones corregidas junto con las actualizaciones de seguridad.
Versiones potencialmente afectadas
La información preliminar apunta a una posible afectación de versiones de PHP desde la rama 5.4. Sin embargo, este alcance procede de fuentes externas y todavía no ha sido confirmado oficialmente por el equipo de PHP.
Las ramas que actualmente cuentan con soporte oficial del proyecto son PHP 8.2, 8.3, 8.4 y 8.5.
Las versiones PHP 5.x, 7.x, 8.0 y 8.1 se encuentran fuera del soporte oficial. Estas instalaciones deberán revisarse de manera prioritaria y, cuando corresponda, migrarse a versiones mantenidas.
No obstante, determinadas distribuciones Linux y proveedores comerciales pueden mantener versiones antiguas mediante correcciones de seguridad retroportadas. En estos casos, deberá verificarse si el proveedor ha publicado una corrección específica.
La utilización de una rama de PHP con soporte no garantiza por sí sola que una instalación esté protegida. Es necesario comprobar que incorpora efectivamente las correcciones de seguridad correspondientes.
Impacto potencial
La explotación de una vulnerabilidad de ejecución remota de código podría permitir diferentes acciones maliciosas sobre los sistemas afectados.
Entre sus posibles consecuencias se encuentran el acceso no autorizado a información almacenada en el servidor, la modificación o eliminación de archivos, la instalación de programas maliciosos, la alteración de los contenidos publicados y la interrupción de servicios.
En determinadas circunstancias, el acceso inicial también podría facilitar el robo de credenciales, la consulta de configuraciones sensibles o nuevos intentos de acceso a sistemas internos.
La gravedad del impacto dependerá de los privilegios asociados al proceso PHP, de los controles de aislamiento existentes y de la exposición del servidor a redes externas.
En entornos de alojamiento compartido o infraestructuras que prestan servicio a múltiples aplicaciones, resulta especialmente importante evaluar el posible alcance de un compromiso.
Medidas de mitigación
1. Actualización del intérprete PHP
La medida correctiva principal consiste en instalar una versión de PHP que incorpore las correcciones oficiales en cuanto estén disponibles.
Las organizaciones deberán verificar las versiones publicadas por el equipo de PHP y aplicar las actualizaciones correspondientes a todas las instalaciones afectadas.
Se recomienda prestar especial atención a los sistemas que utilizan varias versiones de PHP simultáneamente, ya sea por requisitos de compatibilidad de distintas aplicaciones o por la coexistencia de intérpretes independientes para línea de comandos, servidores web y procesos en segundo plano.
Actualizar únicamente WordPress, Drupal, Joomla, Magento u otras aplicaciones que utilizan PHP no corrige necesariamente estas vulnerabilidades, ya que los fallos se encuentran en el propio entorno de ejecución.
2. Inventario y preparación de los sistemas
Antes de la publicación de las correcciones, las organizaciones deben identificar los activos potencialmente afectados y preparar su actualización.
Esta revisión debería abarcar servidores web, aplicaciones corporativas, plataformas de comercio electrónico, gestores de contenidos, contenedores, imágenes Docker y servicios de alojamiento administrado.
Es recomendable registrar la versión de PHP instalada, el sistema operativo, el responsable del servicio, su exposición a Internet, las aplicaciones dependientes y la criticidad de la información tratada.
Los sistemas accesibles públicamente y aquellos que prestan servicios esenciales o procesan datos sensibles deben recibir atención prioritaria.
Asimismo, se recomienda reservar una ventana de mantenimiento urgente, comprobar la compatibilidad de las aplicaciones en un entorno de pruebas y verificar que existen copias de seguridad recuperables antes de introducir cambios.
Cuando el mantenimiento de PHP dependa de un tercero, deberá solicitarse al proveedor confirmación de las versiones instaladas y de su calendario de actualización.
3. Medidas temporales de contención
Cuando no resulte posible instalar inmediatamente las correcciones, se recomienda reducir la superficie de exposición de los servicios potencialmente vulnerables.
Entre las medidas que pueden adoptarse se encuentran la restricción de accesos mediante direcciones IP autorizadas, redes privadas virtuales o mecanismos de autenticación situados antes de la aplicación.
También debe valorarse la retirada temporal de Internet de aquellos servicios que no puedan protegerse adecuadamente, especialmente si procesan información sensible o resultan esenciales para la organización.
La segmentación de red puede limitar el acceso desde un servidor comprometido hacia otros sistemas internos. Del mismo modo, restringir las conexiones salientes innecesarias contribuye a dificultar determinadas acciones posteriores al compromiso.
Los cortafuegos de aplicaciones web (WAF) y los mecanismos de filtrado de tráfico pueden aportar protección adicional frente a patrones de ataque conocidos. Sin embargo, su eficacia dependerá del vector de explotación y de las reglas aplicadas.
Actualmente no existe una medida de configuración universal cuya eficacia haya sido confirmada para ambas vulnerabilidades.
Por este motivo, no debe asumirse que desactivar determinadas funciones de gestión de sesiones, cargas de archivos o procesamiento de solicitudes HTTP elimina el riesgo.
Estas medidas temporales no sustituyen la instalación de las correcciones oficiales.
4. Comprobaciones posteriores a la actualización
Una vez aplicados los parches, deberá verificarse que los servicios utilizan efectivamente la versión corregida del intérprete PHP.
Para ello, se recomienda reiniciar los procesos afectados, incluidos los servicios PHP-FPM o los procesos del servidor web que correspondan según la arquitectura desplegada.
En servidores que ejecuten PHP mediante PHP-FPM, deberá comprobarse que los procesos trabajadores se han reiniciado y utilizan los nuevos binarios. Cuando PHP se integre directamente en Apache u otro servidor web, deberán seguirse los procedimientos específicos correspondientes.
También es importante diferenciar la versión de PHP disponible en la línea de comandos de la utilizada para atender las solicitudes web, ya que ambas pueden ser distintas.
El siguiente comando permite consultar la versión del intérprete disponible en la línea de comandos:
php -v
Cuando se utilice PHP-FPM, la comprobación puede complementarse con la consulta de su versión y configuración, teniendo en cuenta que el nombre del ejecutable puede variar según la distribución y la versión instalada.
La verificación deberá realizarse sin exponer públicamente información sensible sobre la configuración del servidor.
En infraestructuras basadas en contenedores, se recomienda reconstruir las imágenes con los componentes corregidos y volver a desplegarlas. Actualizar únicamente el sistema anfitrión no garantiza que los contenedores incorporen la nueva versión de PHP.
Finalmente, deberán realizarse pruebas funcionales de las aplicaciones y revisar los registros para identificar posibles errores derivados del proceso de actualización.
5. Sistemas con versiones de PHP sin soporte
Las instalaciones que utilizan PHP 5.x, 7.x, 8.0 u 8.1 requieren especial atención porque estas ramas han finalizado su ciclo de soporte oficial.
En estos casos, la medida recomendada consiste en planificar la migración a una versión mantenida y compatible con las aplicaciones utilizadas.
Cuando la migración no pueda realizarse de forma inmediata, deberá consultarse con el proveedor del sistema operativo, la distribución Linux o el servicio de soporte contratado para determinar si existen correcciones de seguridad retroportadas.
Las organizaciones deberán verificar expresamente que estas correcciones cubren las vulnerabilidades identificadas y no asumir que un paquete está protegido por el mero hecho de recibir actualizaciones generales del proveedor.
Hasta disponer de una solución, deberán reforzarse las restricciones de acceso, el aislamiento de los sistemas y la supervisión de posibles actividades maliciosas.
Detección y revisión de posibles compromisos
Ante el riesgo de ejecución remota de código, se recomienda revisar los sistemas potencialmente afectados en busca de comportamientos anómalos.
La monitorización debería incluir los procesos asociados a PHP y a los servidores web, las comunicaciones de red y los cambios en archivos y configuraciones.
Entre las evidencias que pueden justificar una investigación se encuentran:
- Ejecución de comandos inesperados. Aparición de procesos como sh, bash u otros intérpretes iniciados desde php-fpm, php-cgi, apache2 o httpd, cuando no formen parte del funcionamiento habitual de la aplicación.
- Conexiones salientes anómalas. Comunicaciones hacia direcciones IP, dominios o servicios externos desconocidos o no previstos.
- Modificaciones no autorizadas. Creación o alteración de archivos en directorios web, especialmente archivos PHP desconocidos que pudieran utilizarse como puertas traseras.
- Persistencia. Aparición de nuevas tareas programadas, servicios, cuentas o procesos que no hayan sido autorizados.
- Cambios de configuración. Modificaciones inesperadas en los parámetros de PHP, los servicios web o las políticas de acceso.
- Peticiones HTTP sospechosas. Solicitudes que presenten patrones inusuales, errores reiterados o comportamientos incompatibles con el uso legítimo de la aplicación.
Estos elementos constituyen indicadores generales de posible compromiso de servidores web. No deben interpretarse como indicadores exclusivos de CVE-2026-109618 o CVE-2026-109619.
En el momento de elaborar esta alerta no se dispone de una relación oficial y completa de indicadores de compromiso específicos para ambas vulnerabilidades.
La ausencia de alertas no garantiza que un sistema no haya sido comprometido. Si se identifican evidencias sospechosas, se recomienda preservar los registros y demás información relevante y activar los procedimientos de respuesta a incidentes.
Recomendaciones para administraciones públicas y empresas
Las organizaciones que utilicen PHP deberían coordinar las actuaciones entre los equipos de administración de sistemas, desarrollo, seguridad y continuidad de negocio.
En particular, resulta recomendable comprobar que los servicios contratados a terceros cuentan con responsables identificados y procedimientos de actualización definidos, incluyendo las plataformas web gestionadas por proveedores externos.
Las administraciones públicas deben prestar especial atención a los portales institucionales, sedes electrónicas y aplicaciones que puedan incorporar componentes PHP, verificando su exposición y las dependencias tecnológicas existentes.
La gestión de estas vulnerabilidades debería integrarse en los procedimientos habituales de gestión de activos, actualización de componentes, tratamiento de vulnerabilidades y respuesta a incidentes.
También se recomienda mantener un registro de las actuaciones realizadas, las versiones corregidas, las comprobaciones posteriores y las excepciones que deban mantenerse temporalmente.
Justificación de severidad
La alerta se clasifica con severidad crítica debido a la puntuación CVSS v4.0 de 9,2 asignada a ambas vulnerabilidades, la posibilidad de ejecución remota de código y la amplia utilización de PHP en infraestructuras web de empresas y administraciones públicas.
La potencial afectación de servidores expuestos a Internet, junto con la difusión anticipada de información técnica antes de la publicación de las correcciones, incrementa la urgencia de adoptar medidas preventivas.
CERT-EU ha recomendado preparar la aplicación inmediata de los parches y valorar el aislamiento de aplicaciones expuestas a Internet cuando no sea posible corregirlas.
La clasificación de severidad crítica corresponde al impacto potencial de las vulnerabilidades y no implica que se haya confirmado una campaña de explotación generalizada.
