El INCIBE-CERT ha actualizado este miércoles su alerta por dos vulnerabilidades críticas en PHP con ejecución remota de código sin autenticación.
El aviso, registrado con el identificador INCIBE-2026-762, se actualizó el miércoles 21 de octubre de 2026 a las 15:53 horas para confirmar que ya están disponibles las versiones corregidas. Hasta esa publicación, el INCIBE-CERT (el equipo de respuesta ante incidentes del Instituto Nacional de Ciberseguridad, que emite alertas tempranas para empresas, administraciones y ciudadanos) mantenía abierta la advertencia sobre una explotación activa. El documento puede consultarse íntegro en la página oficial del aviso.
EN 30 SEGUNDOS
- ¿Qué ha ocurrido? El INCIBE-CERT actualiza el aviso INCIBE-2026-762 por dos vulnerabilidades críticas en el núcleo de PHP que permiten ejecución remota de código sin autenticación, con CVSS v4.0 de 9,2.
- ¿Dónde y cuándo? Actualización publicada el miércoles 21 de octubre de 2026 a las 15:53 horas; afecta a servidores web con PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed.
- ¿Qué resultado? Parches disponibles en 8.5.12, 8.4.27, 8.3.36 y 8.2.35, además de retroportaciones para las ramas 8.1, 8.0 y 7.4; el proyecto reconoce ataques previos a la publicación de las actualizaciones.
Qué versiones quedan expuestas y cómo se corrige
Las ramas afectadas son cuatro. En la serie 8.5 queda expuesta cualquier instalación anterior a 8.5.12; en la 8.4, las anteriores a 8.4.27. Por debajo, la rama 8.3 exige 8.3.36 y la 8.2 requiere 8.2.35. PHP considera en riesgo las instalaciones que procesan solicitudes web, incluidas las que utilizan PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed.
Los dos fallos tienen una puntuación CVSS v4.0 de 9,2, en el rango de severidad crítica. El primero, CVE-2026-109618, permite ejecución remota de código por corrupción de memoria durante un agotamiento de memoria (OOM): una asignación falla cuando los datos de la solicitud aún no están inicializados y el cierre del proceso reutiliza ese estado inválido. El segundo, CVE-2026-109619, se apoya en un estado global obsoleto que permanece en el proceso trabajador después de liberarse la memoria de una solicitud previa.
La solución pasa por actualizar a la versión corregida de cada rama: 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Quien despliegue paquetes de una distribución o de un proveedor de soporte LTS debe comprobar que incluyen las correcciones. Para PHP 8.1, 8.0 y 7.4, ramas que ya no reciben actualizaciones regulares del proyecto, existen parches de código fuente retroportados disponibles en la página de descargas de PHP.
El aviso incorpora una advertencia operativa: PHP ha comunicado ataques contra servidores antes de la publicación de las actualizaciones, aunque la actividad reportada se refiere al conjunto de vulnerabilidades y no identifica cuál de los dos CVE se utilizó en cada caso. También advierte de que el repositorio voluntario rpms.remirepo.net no dispondrá de actualizaciones el mismo día, por lo que recomienda usar los paquetes de la distribución o compilar PHP desde el código fuente.
El aviso INCIBE-2026-762 fija en 9,2 la severidad de dos fallos que permiten ejecutar código sin credenciales: la actualización inmediata es la única mitigación completa.
Si la actualización no puede aplicarse de inmediato, el aviso recoge medidas temporales que reducen la exposición, pero no la eliminan. Para CVE-2026-109618, PHP señala memory_limit=-1, aplicado de forma administrativa, como mitigación de configuración principal. El valor 128M no desactiva la vulnerabilidad y el propio proyecto advierte de que -1 no es una solución completa y puede elevar el consumo de memoria del servidor.
El vector más destacado es la solicitud multipart por POST. Mantener post_max_size en 8 MB cuando no se permiten cargas y en 32 MB cuando son necesarias, con upload_max_filesize por debajo, limita el margen de maniobra. Conviene además aplicar límites en el servidor web o proxy al tamaño de la solicitud ya decodificada, a los campos, a las partes multipart, a las cabeceras y a la profundidad de anidamiento, incluidas las peticiones sin cabecera Content-Length válida.
Para CVE-2026-109619 hay que desactivar administrativamente session.upload_progress.enabled y reiniciar todos los procesos; en PHP 8.5, también fatal_error_backtraces. Ocultar avisos con error_reporting, display_errors o el operador @ no mitiga el fallo. PHP desaconseja expresamente RLIMIT_AS y RLIMIT_DATA, que pueden provocar fallos de asignación y activar la ruta vulnerable. Si el sistema está expuesto a Internet y no puede actualizarse, la recomendación es aislarlo de las redes públicas.
Apache mod_php, la ruta con mayor riesgo
El aviso identifica Apache mod_php como el escenario de mayor exposición. PHP ha validado la ejecución remota de código sin autenticación contra mod_php antes de que se ejecute código de la aplicación. El análisis del código también considera susceptible a PHP-FPM, aunque no se ha demostrado un exploit completo para esa ruta específica.
En el caso de CVE-2026-109619, el equipo del proyecto describe rutas confirmadas tanto en Apache mod_php como en 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 ha demostrado además una ruta relacionada con las trazas de errores fatales.
Ambos fallos comparten un patrón incómodo: el atacante no necesita credenciales. Un número elevado de cabeceras en las partes multipart, controles de archivo vacíos o nombres de campos anidados elevan el consumo de memoria aunque la solicitud parezca respetar los límites configurados. Los límites de memoria de contenedor o cgroup pueden servir como barrera de disponibilidad, pero tampoco constituyen una mitigación completa.
El panorama de la ciberseguridad
PHP sostiene buena parte de la infraestructura web que procesa solicitudes en producción, y ese es el motivo por el que un aviso de severidad crítica en su núcleo escala de inmediato a los equipos de sistemas de administraciones, pymes y proveedores de servicios. Los datos del propio aviso dibujan la escala del problema: dos CVE con CVSS 9,2, cuatro ramas mantenidas en riesgo, tres ramas legacy con parches retroportados y cinco interfaces de servidor afectadas.
La respuesta institucional se articula en dos niveles. El primero es la alerta temprana: el INCIBE-CERT publica avisos con identificador propio y actualiza el estado de explotación, como ha ocurrido este miércoles con INCIBE-2026-762. El segundo es la investigación: la Policía Nacional, a través de su Brigada de Investigación Tecnológica, y la Guardia Civil, mediante el Grupo de Delitos Telemáticos, son las unidades especializadas en perseguir la explotación de este tipo de fallos cuando se traduce en intrusión, fraude o exfiltración de datos.
El CCN-CERT, el equipo de respuesta ante incidentes del Centro Criptológico Nacional dependiente del CNI, mantiene la vigilancia sobre infraestructuras críticas y administraciones públicas, el segmento donde un fallo de ejecución remota en el servidor web tiene mayor impacto. Su catálogo de guías de configuración segura es la referencia para los responsables de sistemas. Para el administrador, la conclusión operativa es única y no admite interpretación: actualizar a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, reiniciar los procesos y verificar que ninguna configuración de aplicación, directorio o pool vuelve a fijar un límite de memoria finito.
