Última revisión: 22 de octubre de 2026.
Si administras un servidor PHP, una instalación de WordPress o un entorno con PHP-FPM, revisa hoy mismo la versión activa. El equipo de PHP ha publicado parches para dos vulnerabilidades críticas capaces de permitir la ejecución remota de código sin autenticación: CVE-2026-109618 y CVE-2026-109619.
Los fallos afectan a la gestión interna de memoria y del estado de las peticiones. Un atacante podría enviar peticiones especialmente diseñadas y ejecutar código con los privilegios del proceso web. El impacto dependerá del servidor, las extensiones instaladas y la configuración, pero los sistemas expuestos a Internet deben tratarse como prioritarios.
Qué ha ocurrido con PHP
PHP utiliza trabajadores que pueden atender varias peticiones consecutivas. En determinadas circunstancias, información perteneciente a una petición anterior podía permanecer referenciada después de que la memoria asociada ya hubiera sido liberada.
Ese comportamiento puede provocar un use-after-free: el uso de una zona de memoria que ya no debería considerarse válida. Si el atacante consigue controlar el contenido de esa memoria, el fallo puede acabar en ejecución de código arbitrario.
Los avisos técnicos publicados por el proyecto PHP califican ambos problemas como críticos, con una puntuación de 9,2 sobre 10 en CVSS 4.0. El aviso oficial de PHP recomienda actualizar de inmediato porque no existe una mitigación de configuración que sustituya completamente al parche.
CVE-2026-109618: corrupción de memoria por falta de memoria
La primera vulnerabilidad está relacionada con las situaciones de out-of-memory, cuando PHP agota la memoria disponible mientras procesa una petición.
En ciertos caminos de ejecución, PHP podía interrumpir prematuramente el procesamiento sin dejar completamente inicializada la información interna de la petición. Durante las tareas de limpieza, esos datos incompletos podían tratarse como válidos y provocar corrupción de memoria.
El escenario merece especial atención en servidores que aceptan formularios multipart, subidas de archivos o peticiones con muchas cabeceras y variables. El advisory de CVE-2026-109618 documenta el problema y sus límites técnicos.
CVE-2026-109619: estado obsoleto entre peticiones
La segunda vulnerabilidad afecta al estado interno que PHP conserva entre una petición y la siguiente dentro del mismo trabajador.
Un error fatal, una excepción, un problema de memoria o determinados avisos de configuración podían dejar referencias a datos pertenecientes a una petición ya finalizada. Cuando el mismo trabajador atendía otra petición, PHP podía reutilizar accidentalmente esa información liberada.
El impacto se ha confirmado en determinadas configuraciones con mod_php y también se han validado escenarios contra PHP-FPM. La exposición exacta depende del servidor web, las extensiones y la forma en que la aplicación gestione sesiones, errores, subidas de archivos y parámetros de configuración.
Desactivar display_errors, ocultar los avisos o cambiar error_reporting no ofrece una protección completa. El problema puede producirse antes de que PHP decida mostrar o registrar determinados errores. Consulta el advisory de CVE-2026-109619 para conocer los escenarios analizados.
Qué versiones de PHP están afectadas
Las ramas anteriores a las siguientes versiones corregidas deben actualizarse:
| Rama de PHP | Versión corregida |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Los proveedores de hosting y las distribuciones Linux pueden publicar paquetes con una numeración propia. Por eso, además del número principal, conviene revisar el changelog del paquete y las notificaciones del proveedor.
PHP 8.2 seguirá recibiendo actualizaciones de seguridad hasta el 31 de diciembre de 2026. Aunque todavía tenga soporte, conviene planificar la migración a una rama con un ciclo de mantenimiento más amplio.
Cómo comprobar y actualizar PHP
Comprueba la versión del cliente PHP con:
php -vSi utilizas PHP-FPM, revisa también el binario o servicio correspondiente:
php-fpm8.3 -v
systemctl status php8.3-fpmEl nombre exacto puede variar según la distribución y la rama instalada.
En Debian o Ubuntu:
sudo apt update
sudo apt upgradeEn RHEL, AlmaLinux, Rocky Linux o Fedora:
sudo dnf updateDespués de actualizar, reinicia el servicio PHP-FPM que utilice el sitio:
sudo systemctl restart php8.3-fpmTambién puede ser necesario reiniciar Apache o Nginx si la instalación utiliza módulos integrados o mantiene procesos antiguos. Revisa todas las ramas instaladas: un mismo servidor puede utilizar PHP 8.1 para una aplicación antigua y PHP 8.3 para otra más reciente.
PHP-FPM, Apache, LiteSpeed y FrankenPHP
El problema no se limita a una única forma de ejecutar PHP. Deben revisarse las instalaciones que utilicen:
- PHP-FPM.
- Apache con
mod_php. php-cgi.- FrankenPHP.
- LiteSpeed o LSAPI.
El riesgo demostrado es especialmente relevante en algunas configuraciones de Apache con mod_php, pero PHP-FPM no debe considerarse automáticamente seguro. Cada virtual host puede utilizar un socket, una versión o un pool distinto.
En servidores con cPanel y EasyApache, revisa los paquetes disponibles desde WHM/cPanel. cPanel ha publicado referencias para las ramas compatibles, entre ellas ea-php82 8.2.35, ea-php83 8.3.36, ea-php84 8.4.27 y ea-php85 8.5.12. Consulta su boletín específico para cPanel.
¿Afecta PHP2Shell a WordPress?
WordPress depende de PHP, pero actualizar WordPress no actualiza necesariamente el intérprete PHP del servidor. Son componentes distintos.
Para revisar la versión desde WordPress:
- Accede a Herramientas.
- Abre Salud del sitio.
- Entra en Información.
- Consulta el apartado Servidor.
Si el sitio funciona con una versión vulnerable, la actualización debe realizarse desde el panel del alojamiento, WHM, Plesk o la plataforma que gestione el servidor.
Antes de cambiar de versión, crea una copia de seguridad y comprueba la compatibilidad del tema y los plugins. Después, revisa los registros de errores, las tareas programadas, las conexiones con la base de datos y los formularios.
Un plugin de seguridad puede filtrar algunos patrones de ataque, pero no modifica el binario PHP que contiene el fallo. La corrección debe aplicarse en la infraestructura.
Si necesitas revisar las actualizaciones, copias de seguridad y controles de seguridad de una web WordPress, puedes consultar nuestro servicio de mantenimiento web y SEO para WordPress.
Qué hacer si no puedes aplicar el parche de inmediato
La actualización es la única corrección completa. Si existe una limitación temporal, estas medidas pueden reducir algunos escenarios, pero no sustituyen al parche:
- Reducir la exposición directa del servidor mediante un proxy inverso o un WAF.
- Limitar el tamaño de las peticiones y de las subidas de archivos.
- Mantener bajo control
post_max_size,upload_max_filesizey los límites de entrada. - Desactivar
session.upload_progresssi la aplicación no lo necesita. - Eliminar directivas PHP obsoletas que generen avisos durante la inicialización.
- Reiniciar todos los trabajadores PHP después de modificar la configuración.
- Supervisar los registros de Apache, Nginx, PHP-FPM y del sistema.
Cómo comprobar si el servidor pudo verse comprometido
Utilizar una versión vulnerable no demuestra por sí solo que haya existido un ataque, pero sí justifica una revisión. Después de actualizar, comprueba:
- Fechas de modificación inusuales en archivos PHP.
- Nuevos usuarios administrativos en WordPress.
- Plugins, temas o extensiones que nadie del equipo haya instalado.
- Procesos desconocidos ejecutándose con el usuario del servidor web.
- Peticiones anómalas en los registros.
- Cambios en
.htaccess, archivos de configuración o tareas programadas. - Conexiones salientes inesperadas desde los procesos web.
Si aparecen indicios de intrusión, aísla el servidor, conserva los registros, rota las contraseñas y claves, revisa los accesos y analiza la integridad de las aplicaciones antes de limpiar los archivos.
Conclusión
Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 requieren una revisión inmediata de cualquier servidor que procese peticiones PHP.
Las versiones corregidas son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Comprueba todas las versiones instaladas, actualiza también los paquetes gestionados por cPanel o el proveedor de hosting y reinicia los trabajadores PHP para que el parche quede activo.
¿No sabes qué versión utiliza tu servidor o si la actualización puede afectar a tu web? En Iberostudio podemos revisar el entorno, comprobar las versiones activas y ayudarte a aplicar el cambio con control de compatibilidad.
