Dos vulnerabilidades críticas capaces de permitir ejecución remota de código sin autenticación. Una tercera alerta amplía el problema. Y miles de servidores podrían seguir expuestos si no se han aplicado las correcciones correspondientes.
No estamos hablando de un plugin defectuoso ni de un agujero aislado en una web. El foco está en PHP, el intérprete que ejecuta el código de una enorme cantidad de sitios y aplicaciones. Cuando el fallo está en esa capa, actualizar WordPress o cambiar una extensión no basta necesariamente para cerrar la puerta.
Las agencias europeas de ciberseguridad han alertado del riesgo y han pedido a las organizaciones identificar los sistemas afectados, aplicar las correcciones y priorizar los servicios expuestos a Internet. El impacto real dependerá de cuántos sistemas sigan vulnerables, cómo estén configurados y qué permisos tenga el proceso PHP.
01 / Tres días que elevaron la alerta
Se anuncian dos fallos críticos
El proyecto PHP prepara actualizaciones para corregir dos vulnerabilidades que pueden desembocar en ejecución remota de código. CERT-EU emite un aviso preliminar y recomienda preparar el parcheo inmediato.
Se publican las versiones corregidas
PHP publica las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Los administradores deben identificar qué instalaciones usan versiones afectadas y actualizar el intérprete o el paquete del proveedor.
PHP publica una recomendación adicional
El equipo de PHP emite un aviso informativo sobre un posible vector adicional, identificado como CVE-2026-115560, y recomienda desactivar temporalmente el progreso de subida de sesiones. La documentación disponible es limitada y se trata de un escenario poco habitual.
02 / Qué significa realmente RCE
RCE significa Remote Code Execution, o ejecución remota de código. En términos sencillos, un atacante puede enviar una petición especialmente construida y, si se cumplen las condiciones necesarias, conseguir que el servidor ejecute instrucciones que no debería ejecutar.
El alcance de una intrusión depende de los permisos del proceso PHP, el aislamiento del sistema y los recursos accesibles. Entre las consecuencias potenciales están el acceso a datos, la modificación de archivos, la instalación de mecanismos de persistencia o la interrupción del servicio. No todos esos resultados están garantizados en todos los entornos, pero explican por qué un RCE sin autenticación exige una respuesta urgente.
03 / Los dos fallos originales
RCE por corrupción de memoria durante OOM
Cuando PHP alcanza una condición de falta de memoria (out-of-memory), interrumpe la petición. En determinadas rutas de ejecución, la interrupción puede dejar estructuras internas parcialmente inicializadas. La limpieza posterior puede tratar datos inválidos como si fueran válidos y operar sobre memoria incorrecta.
El riesgo no consiste simplemente en que una petición consuma demasiada memoria: el problema está en cómo el intérprete maneja ese estado de error y las estructuras que quedan detrás.
RCE por estado global obsoleto (stale global state)
Parte del estado global puede conservar referencias a memoria asociada a una petición que ya ha terminado o cuyo contenido se ha liberado. Si un trabajador reutilizado procesa otra petición antes de que ese estado se reinicialice correctamente, puede acceder a información que ya no debería utilizar.
Es un problema de ciclo de vida de memoria y referencias internas, no algo que se solucione únicamente actualizando el tema o los plugins de una web.
Los avisos técnicos contemplan entornos como PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo exacto depende de la versión, la configuración y el camino de ejecución; el propio equipo de PHP señala que el riesgo es mayor en mod_php, donde se ha demostrado un exploit que se dispara antes de que se ejecute el código de la aplicación.
04 / ¿Qué versiones están afectadas?
Las versiones corregidas publicadas para las dos vulnerabilidades iniciales son las siguientes:
| Rama de PHP | Versión corregida |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
En general, las versiones anteriores dentro de estas ramas están afectadas por los dos fallos iniciales. PHP 8.1 y las ramas anteriores están fuera del soporte ordinario del proyecto, aunque algunos proveedores pueden distribuir parches retroportados. El equipo de PHP ha publicado backports mínimos para PHP 7.4, 8.0 y 8.1 en su repositorio oficial. Por eso, hay que consultar el aviso de seguridad de la distribución o del proveedor de alojamiento, no mirar únicamente el número de versión.
05 / La tercera alerta: CVE-2026-115560
El 23 de octubre, el equipo de PHP publicó un aviso informativo sobre un posible vector adicional de ejecución remota de código, identificado como CVE-2026-115560. Se trata de un escenario que solo se produce bajo una combinación poco habitual de configuración y código de aplicación: que la aplicación cambie session.serialize_handler en tiempo de ejecución antes de iniciar la sesión y que el progreso de subida de archivos siga activado. El propio equipo de PHP lo considera un riesgo improbable y lo gestionará en su ciclo de publicación habitual, no como un parche de emergencia.
La recomendación preventiva es desactivar temporalmente esa funcionalidad en la configuración de PHP:
session.upload_progress.enabled=0
La configuración debe aplicarse en el entorno PHP correspondiente y reiniciar los trabajadores cuando proceda. Esta misma medida ya aparecía como mitigación en el aviso de CVE-2026-109619 del 21 de octubre; si ya la aplicaste entonces, no es necesario hacer nada más para este nuevo aviso. Consulta la versión más reciente del aviso oficial para conocer el alcance definitivo.
06 / Por qué puede afectar a tantos servicios
PHP está presente en gestores de contenidos, aplicaciones empresariales, tiendas online, paneles de administración y productos de terceros. Algunas instalaciones están perfectamente inventariadas; otras quedan escondidas dentro de imágenes de contenedores, appliances o aplicaciones empaquetadas.
Cuando se publica una actualización de seguridad, los defensores pueden estudiar el parche para comprobar que funciona. Los atacantes también pueden analizar las diferencias entre versiones y buscar sistemas que aún no se han actualizado. La circulación de pruebas de concepto aumenta la urgencia, pero no demuestra por sí sola que todos los servidores vulnerables estén siendo explotados de forma masiva.
Por eso, la magnitud del problema no se mide simplemente contando los avisos publicados. Depende de cuántas instalaciones vulnerables sigan expuestas, de la rapidez con la que se parcheen y de qué permisos tenga PHP dentro de cada servidor.
07 / Qué hacer ahora
- Inventariar: localizar versiones de PHP en servidores, contenedores, plataformas y productos de terceros.
- Actualizar: instalar la versión corregida o el paquete oficial de seguridad del proveedor.
- Revisar ramas antiguas: comprobar si existe un parche retroportado. Si no existe, planificar una migración o aislar el servicio.
- Mitigar el vector adicional: revisar la configuración de sesiones y aplicar la medida temporal indicada por el equipo de PHP.
- Verificar: reiniciar los trabajadores cuando corresponda y confirmar que el servidor web usa el runtime corregido.
- Investigar: si el servicio estuvo expuesto, revisar registros, archivos modificados, procesos y posibles señales de persistencia.
Si un servicio expuesto no puede corregirse o mitigarse con rapidez, debe valorarse su aislamiento de redes públicas hasta poder verificar la solución. Una medida temporal reduce determinados caminos de ataque, pero no equivale a reparar el problema de raíz.
08 / Preguntas frecuentes
¿Todas las webs que usan PHP están hackeadas?
No. Que una versión sea vulnerable no significa que todas las instalaciones hayan sido comprometidas. El riesgo depende de la versión, la configuración, la exposición y las medidas de aislamiento.
¿Actualizar WordPress es suficiente?
No necesariamente. El intérprete PHP es una capa distinta del CMS y de sus plugins. Hay que comprobar y corregir la versión PHP que ejecuta la web.
¿Una versión antigua siempre está desprotegida?
No puede determinarse solo por el número de versión. Algunos proveedores retroportan correcciones de seguridad. Comprueba el paquete exacto y el aviso de tu proveedor.
¿La tercera alerta afecta a todos los sitios?
No. El escenario descrito por PHP requiere una combinación muy concreta de configuración de sesiones y comportamiento de la aplicación. El propio equipo de PHP lo considera un riesgo improbable y lo gestiona en su ciclo normal de publicación.
Fuentes y avisos oficiales
- PHP — Aviso de seguridad: Critical remote code execution vulnerabilities, update now (21 oct. 2026)
- PHP — Aviso informativo: Session upload progress (CVE-2026-115560) (23 oct. 2026)
- CERT-EU — Critical Vulnerabilities in PHP (Advisory 2026-018)
- NCSC del Reino Unido — Alerta de seguridad sobre PHP
- ENISA — Comunicado conjunto sobre vulnerabilidades críticas de PHP
Visitas: 0
Automation & Data Specialist | Web Development | Data Processing & Integration