DTT, Articulo DTT, Alertas de Seguridad

[DTT Alerta de seguridad] Vulnerabilidades críticas en PHP permiten ejecución remota de código

Autor

Coordinador del Laboratorio de Desarrollo y Transferencia de Tecnología

octubre 21, 2026

Identificador: DTT-AS-2026-002
Fecha: 21 de octubre de 2026
Emisor: Laboratorio de Desarrollo y Transferencia de Tecnología (DTT) – UCB Sede Tarija
Nivel de alerta: Crítico
Dirigido a: Administradores de servidores web, proveedores de hosting, equipos de TI de instituciones y empresas, y desarrolladores que operan sitios o aplicaciones en PHP

El proyecto PHP publicó el 20 de octubre de 2026 dos vulnerabilidades críticas en el núcleo del lenguaje, identificadas como CVE‑2026‑109618 y CVE‑2026‑109619. Ambas permiten que un atacante remoto, sin autenticarse, ejecute código en el servidor con los privilegios del proceso web, y ambas tienen una puntuación CVSS v4.0 de 9,2. Al día siguiente, el 21 de octubre, se liberaron las versiones corregidas.

Se han reportado ataques contra servidores PHP antes de que existieran los parches, por lo que la situación debe tratarse como un día cero. PHP es la base de WordPress, Moodle, Joomla, Drupal, WHMCS, la mayoría de los paneles de hosting compartido y una gran parte de los sistemas institucionales y comerciales en Bolivia. Cualquier servidor expuesto a Internet con una versión afectada debe considerarse en riesgo hasta ser actualizado.

Versiones afectadas

Rama de PHP	Versiones afectadas	Versión corregida
PHP 8.5	Anteriores a 8.5.12	8.5.12
PHP 8.4	Anteriores a 8.4.27	8.4.27
PHP 8.3	Anteriores a 8.3.36	8.3.36
PHP 8.2	Anteriores a 8.2.35	8.2.35
PHP 8.1, 8.0 y 7.4	Todas (ramas sin soporte regular)	Solo parches de código fuente retroportados

Están expuestas las instalaciones que atienden solicitudes web, incluidas las que usan PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. Según el equipo de PHP, el riesgo es mayor en Apache mod_php.

Indicadores de exposición

El servidor ejecuta una versión de PHP anterior a las indicadas en la tabla.
El sitio o aplicación es accesible desde Internet y acepta solicitudes POST (formularios, inicios de sesión, cargas de archivos, APIs).
Se utiliza Apache con mod_php, o PHP-FPM con trabajadores que atienden múltiples solicitudes sucesivas.
Se mantienen sistemas heredados en PHP 7.4, 8.0 u 8.1 que dependen de paquetes de terceros.
Se usan paquetes del repositorio voluntario rpms.remirepo.net, que según PHP no tenía actualizaciones disponibles el día de la publicación.

Riesgos

Una explotación exitosa puede permitir:

Ejecutar código arbitrario en el servidor sin credenciales.
Instalar puertas traseras (webshells) persistentes.
Leer o modificar bases de datos, archivos de configuración y credenciales.
Exponer fragmentos de memoria con datos de otros usuarios (CVE‑2026‑109619).
Usar el servidor como punto de entrada a la red interna o para atacar a terceros.
En hosting compartido, afectar a todos los sitios que comparten el mismo proceso o usuario del sistema.

Recomendaciones

Actualizar PHP de inmediato a la versión corregida de su rama: 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Después de actualizar, reiniciar PHP-FPM, Apache o el servicio correspondiente para que ningún proceso antiguo quede en memoria.
Si usa paquetes de su distribución (Debian, Ubuntu, AlmaLinux, etc.) o de un proveedor de soporte extendido, confirmar que el paquete incluye las correcciones de ambos CVE; el número de versión de la distribución puede no coincidir con el de PHP.
Para PHP 8.1, 8.0 y 7.4, aplicar los parches retroportados publicados por PHP o solicitar una versión corregida a su proveedor. La recomendación de fondo es migrar a una rama mantenida.
Si un sistema expuesto a Internet no puede actualizarse, aislarlo de las redes públicas hasta aplicar la corrección.
Revisar registros de acceso y de errores desde el 20 de octubre en busca de solicitudes POST multipart anómalas, errores fatales repetidos o archivos PHP nuevos en directorios públicos.
En organizaciones con muchos servidores, inventariar todas las instancias de PHP, incluidas las de contenedores, entornos de prueba y servicios olvidados.

Cómo verificar la versión instalada

Desde la terminal del servidor:

php -v
php -i | grep -E "memory_limit|post_max_size|upload_max_filesize|session.upload_progress.enabled"

Tenga en cuenta que la versión de la línea de comandos puede ser distinta a la que usa el servidor web. En paneles como cPanel, HestiaCP o Plesk, verifique la versión asignada a cada dominio.

Medidas temporales si no es posible actualizar de inmediato

Estas medidas reducen la exposición a rutas de ataque conocidas, pero no sustituyen la actualización:

CVE‑2026‑109618: establecer memory_limit=-1 a nivel administrativo y reiniciar los procesos, verificando que ninguna configuración de aplicación, directorio o pool vuelva a fijar un límite finito. Un valor como 128M no desactiva la vulnerabilidad, y -1 puede aumentar el consumo de memoria del servidor.
Mantener post_max_size bajo: 8 MB si no se permiten cargas de archivos y 32 MB si son necesarias, con upload_max_filesize por debajo de ese valor. Limitar en el servidor web o proxy el tamaño de solicitud, número de campos, partes multipart, cabeceras y profundidad de anidamiento, incluso para solicitudes sin una cabecera Content-Length válida. Si la aplicación no usa formularios multipart, bloquearlos antes de que lleguen a PHP.
No utilizar RLIMIT_AS ni RLIMIT_DATA: pueden provocar justamente los fallos de asignación que activan la vulnerabilidad. Los límites de memoria de contenedor o cgroup ayudan a la disponibilidad, pero no son una mitigación completa.
CVE‑2026‑109619: desactivar session.upload_progress.enabled a nivel administrativo y reiniciar todos los procesos. En PHP 8.5, desactivar también fatal_error_backtraces.
Corregir directivas por solicitud inválidas u obsoletas que generen avisos, así como errores fatales y tiempos de ejecución agotados en rutas accesibles sin autenticación. Ocultar avisos con error_reporting, display_errors o el operador @ no mitiga CVE‑2026‑109619.

Detalles técnicos

Vulnerabilidades relacionadas

CVE‑2026‑109618 — Ejecución remota de código por corrupción durante agotamiento de memoria (OOM)

En ciertas rutas de procesamiento, una asignación de memoria puede fallar cuando los datos de la solicitud aún no están completamente inicializados. PHP interrumpe el procesamiento, pero durante el cierre de la solicitud puede utilizar ese estado inválido y provocar una corrupción de memoria que permite ejecutar código de forma remota.

El vector más relevante son las solicitudes POST multipart: un número elevado de cabeceras en las partes, controles de archivo vacíos o nombres de campo anidados pueden disparar el consumo de memoria aunque la solicitud parezca respetar los límites configurados. PHP validó la ejecución remota de código sin autenticación contra Apache mod_php, antes de que se ejecute cualquier código de la aplicación. El análisis del código considera también susceptible a PHP-FPM, aunque no se ha demostrado un exploit completo para esa ruta.

Más información: PHP — RCE via OOM corruption (GHSA-w8hw-w9fx-j79w)

CVE‑2026‑109619 — Ejecución remota de código por uso de estado global obsoleto

Parte del estado interno de una solicitud puede quedar en el proceso trabajador después de liberarse su memoria. Si una solicitud posterior llega al mismo trabajador y utiliza ese estado antes de que PHP lo reinicialice, se produce un uso después de liberar (use-after-free), con posible divulgación de memoria y ejecución remota de código.

El equipo de PHP confirmó rutas de explotación en Apache mod_php y PHP-FPM. La explotación puede depender de un error fatal o de una operación de sesión, y de que el mismo trabajador procese solicitudes sucesivas. En PHP 8.5 se demostró además una ruta relacionada con las trazas de errores fatales.

Más información: PHP — RCE via stale global state (GHSA-6wmf-4rv5-p3rp)

CVE	Tipo	CVSS v4.0	Autenticación	Rutas confirmadas
CVE‑2026‑109618	Corrupción de memoria por OOM	9,2 (Crítica)	No requerida	Apache mod_php (PHP-FPM susceptible)
CVE‑2026‑109619	Use-after-free por estado global obsoleto	9,2 (Crítica)	No requerida	Apache mod_php y PHP-FPM

Cronología

Antes del 20 de octubre de 2026: se reportan ataques contra servidores PHP aprovechando estas fallas antes de existir parches.
20 de octubre de 2026: PHP publica el aviso de seguridad y anuncia parches para el día siguiente, incluidas las ramas 7.4, 8.0 y 8.1.
21 de octubre de 2026: se publican PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, junto con los parches retroportados. INCIBE-CERT actualiza su aviso INCIBE-2026-762 con importancia 5 (crítica).
Octubre de 2026: ENISA y otras agencias emiten una declaración conjunta; el NCSC de Países Bajos publica en GitHub el repositorio php2shell relacionado con estas vulnerabilidades.

En resumen

Confirmado

CVE‑2026‑109618 y CVE‑2026‑109619 son vulnerabilidades críticas (CVSS 9,2) documentadas por el propio proyecto PHP.
Ambas permiten ejecución remota de código sin autenticación.
La ejecución remota se validó contra Apache mod_php; CVE‑2026‑109619 tiene rutas confirmadas también en PHP-FPM.
Existen versiones corregidas para todas las ramas mantenidas y parches de código fuente para 7.4, 8.0 y 8.1.
Se reportaron ataques antes de la publicación de los parches.

No confirmado

Cuál de los dos CVE se utilizó en cada uno de los ataques reportados; la actividad se atribuye al conjunto.
Un exploit completo de CVE‑2026‑109618 sobre PHP-FPM.
La eficacia total de las medidas temporales: el propio PHP advierte que no cubren todas las variantes.
El número de servidores comprometidos en Bolivia o la región.