Índice de contenidos
Claves de la noticia
- PHP ha publicado cuatro versiones que corrigen dos vulnerabilidades críticas capaces de permitir ejecución remota de código sin autenticación.
- Los avisos técnicos distinguen ataques demostrados contra mod_php y rutas condicionadas por la aplicación: utilizar PHP-FPM no acredita inmunidad.
- La actualización del intérprete debe comprobarse con el proveedor de alojamiento; PHP 8.2 conserva soporte oficial solo hasta el 31 de diciembre.
PHP ha pasado de la alerta preventiva a la publicación de parches este 21 de octubre. Para las empresas y particulares que mantienen webs, la urgencia consiste en confirmar qué intérprete atiende realmente sus peticiones y si incorpora las correcciones. Tener el gestor de contenidos al día no responde por sí solo a esa pregunta.
Cuatro ramas corregidas y un calendario desigual
El aviso público del proyecto PHP identifica las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 como las primeras corregidas de sus respectivas ramas. Los dos identificadores son CVE-2026-109618 y CVE-2026-109619. El anuncio previo había fijado su publicación para las 14:00 UTC, las 16:00 en la España peninsular; ahora existen referencias concretas para contrastar la respuesta del alojamiento.
| Rama | Primera corrección | Fin de seguridad |
|---|---|---|
| 8.2 | 8.2.35 | 31-12-2026 |
| 8.3 | 8.3.36 | 31-12-2027 |
| 8.4 | 8.4.27 | 31-12-2028 |
| 8.5 | 8.5.12 | 31-12-2029 |
La comparación cruza el aviso de hoy con el calendario de soporte del proyecto. Una resta de fechas entre el 21 de octubre y el 31 de diciembre da 71 días hasta el fin de soporte de PHP 8.2. Instalar 8.2.35 resuelve esta emergencia, pero deja una migración pendiente este mismo trimestre. Para un comercio que prepara la campaña navideña, parchear y planificar el cambio de rama son dos trabajos diferentes.
El soporte de una distribución puede incorporar correcciones mediante backports, sin adoptar exactamente la numeración de la descarga original. Por eso, una versión aparentemente anterior necesita contraste con el aviso del proveedor. Tampoco un número reciente basta si el servicio sigue ejecutando procesos antiguos. La evidencia útil es la correspondencia entre paquete corregido, servicio reiniciado y entorno que recibe tráfico.
La aplicación puede llegar demasiado tarde
El informe sobre corrupción por falta de memoria explica que una interrupción puede dejar estructuras internas parcialmente inicializadas. Durante la limpieza de la petición, PHP puede tratarlas como válidas. Los investigadores documentan ejecución remota contra Apache con mod_php antes de que empiece el código de la aplicación. Una comprobación dentro de un plugin o de una página de acceso no alcanza a proteger esa fase previa.
Ese documento distingue el comportamiento de FPM: cuando falla el arranque de una petición, el proceso hijo termina, lo que evita esa secuencia concreta. Sin embargo, el análisis también contempla fallos posteriores al arranque ligados a la aplicación. La diferencia modifica las condiciones del ataque; no convierte el nombre del servidor en una garantía de seguridad ni permite afirmar que todos los entornos sean explotables del mismo modo.
El segundo aviso, sobre estado global obsoleto, describe otra frontera: un trabajador puede conservar referencias a memoria de una petición ya liberada y volver a utilizarlas en otra. Publica rutas de explotación validadas para mod_php y FPM, con requisitos distintos. De ahí una conclusión práctica: descartar FPM por el comportamiento descrito en el primer fallo deja sin evaluar el segundo.
Los avisos otorgan a ambas vulnerabilidades una puntuación crítica de 9,2. Eso expresa gravedad, no un recuento de servidores comprometidos. Los documentos consultados no permiten calcular cuántas webs españolas están expuestas, ni afirmar que una instalación concreta haya sufrido una intrusión. La distinción entre prueba técnica, condiciones de explotación e incidente real evita convertir una emergencia verificable en una cifra de víctimas inventada.
Qué pedir al alojamiento y qué muestra WordPress
Para quien utiliza un servicio gestionado, la consulta al proveedor puede ser precisa: qué paquete incorpora ambos arreglos, qué sitios y contenedores lo utilizan y si se han renovado sus trabajadores. En un servidor propio, esa misma comprobación corresponde a quien administra el sistema. No exige cambiar de CMS; exige localizar la capa responsable de ejecutar su código.
La documentación de Salud del sitio de WordPress sitúa la información técnica en Herramientas, Salud del sitio, Información. Su apartado de servidor permite consultar la versión de PHP. Es una primera referencia para hablar con soporte, no un análisis de explotación ni una certificación de que todos los servicios del alojamiento usan el mismo binario.
Esta separación de responsabilidades también ayuda a entender por qué la respuesta al compromiso de certificados de eMudhra dependía de los almacenes de confianza de cada producto. El componente donde reside un fallo determina quién distribuye la corrección. Y, como ilustra la actualización de JDK 21 y sus condiciones, elegir un paquete requiere conocer también su canal de mantenimiento.
Reducir exposición no equivale a cerrar el incidente
PHP publica medidas provisionales para rutas específicas, pero advierte que no sustituyen una actualización completa. El aviso de estado global señala que ocultar errores no elimina el acceso al estado vulnerable; tampoco la ausencia de mensajes demuestra seguridad. Los ajustes de configuración deben evaluarse con el administrador, porque su efecto depende del fallo, del servicio y de cómo se aplican.
La comprobación de cierre más defendible es concreta: ambos parches incorporados en el intérprete que sirve la web, trabajadores renovados y aplicación funcionando tras el cambio. En PHP 8.2 hay además una fecha límite cercana para migrar. Una web puede superar la emergencia de hoy y seguir necesitando otro cambio antes de terminar el año.
Imagen: recreación conceptual generada por IA de infraestructura de alojamiento; no representa un servidor atacado ni una instalación identificable.
