PHP corrige dos vulnerabilidades críticas de ejecución remota sin autenticación: actualización inmediata

Qué ha cambiado

El proyecto PHP ha publicado actualizaciones de seguridad urgentes para corregir dos vulnerabilidades críticas que pueden permitir ejecución remota de código sin autenticación. Las vulnerabilidades son: - CVE-2026-109618; - CVE-2026-109619.

Las dos fueron anunciadas con una puntuación CVSS v4.0 de 9.2, categoría crítica. PHP recomienda actualizar inmediatamente y afirma que no existe una mitigación completa que sustituya la actualización.

QUÉ VERSIONES CORRIGEN EL PROBLEMA Las versiones publicadas con las correcciones son: - PHP 8.5.12; - PHP 8.4.27; - PHP 8.3.36; - PHP 8.2.35. Quien utilice una de estas ramas debería comprobar que su instalación ha llegado, como mínimo, a la versión corregida correspondiente.

En distribuciones Linux o servicios gestionados, el número visible puede no coincidir exactamente con el número oficial de PHP porque algunos proveedores aplican parches de seguridad mediante backports. Por eso, además de mirar el número de versión, conviene comprobar el aviso de seguridad del proveedor o del hosting.

QUIÉN ESTÁ EN RIESGO PHP considera en riesgo las instalaciones que sirven peticiones web. El aviso incluye expresamente: - PHP-FPM; - Apache con mod_php; - php-cgi; - FrankenPHP; - LiteSpeed.

El riesgo es especialmente alto para mod_php. PHP indica que existe una explotación demostrada en la que una petición no autenticada puede alcanzar la vulnerabilidad antes de que se ejecute el código de la propia aplicación.

Esto es importante porque el problema no depende necesariamente de que exista una vulnerabilidad previa en WordPress, un plugin o el código de la aplicación. La vulnerabilidad está en el runtime PHP.

CVE-2026-109618: CORRUPCIÓN DURANTE UN FALLO DE MEMORIA PHP describe CVE-2026-109618 como una ejecución remota de código relacionada con corrupción durante el manejo de una situación de falta de memoria. Simplificado: 1.

PHP está procesando datos internos de una petición. 2.

Se produce una condición de memoria en un momento delicado. 3.

Parte de los datos puede quedar inicializada de forma incompleta. 4.

Durante la limpieza, PHP puede tratar esa información inválida como si fuera válida. 5.

Esa situación puede terminar siendo explotable para ejecutar código. La explicación técnica completa es más compleja, pero la consecuencia editorial importante es clara: no se trata simplemente de “hacer caer PHP”.

El proyecto PHP clasifica el resultado posible como ejecución remota de código sin autenticación.

CVE-2026-109619: ESTADO GLOBAL QUE SOBREVIVE MÁS DE LO DEBIDO La segunda vulnerabilidad, CVE-2026-109619, está relacionada con estado interno perteneciente a una petición que puede sobrevivir después de que la memoria que lo respaldaba haya sido liberada.

Una petición posterior atendida por el mismo worker puede llegar a utilizar ese estado antiguo antes de que la inicialización normal lo restablezca. De nuevo, la consecuencia publicada por PHP es RCE sin autenticación.

La diferencia entre ambos CVE es importante porque no son dos nombres para un mismo fallo. Representan dos rutas distintas dentro del manejo interno de PHP.

NO ES UNA VULNERABILIDAD DE WORDPRESS WordPress ha publicado una alerta porque millones de sitios WordPress utilizan PHP.

Pero WordPress deja expresamente claro que: - las vulnerabilidades no son específicas de WordPress; - afectan a cualquier servidor que aloje una aplicación PHP; - no se necesita ni está prevista una actualización de WordPress para corregir estos dos fallos. Esto evita una confusión importante.

Actualizar WordPress Core no repara una vulnerabilidad del intérprete PHP. La acción necesaria está en la versión de PHP utilizada por el servidor.

CÓMO COMPROBAR LA VERSIÓN EN WORDPRESS En un sitio WordPress puede consultarse desde: Herramientas → Salud del sitio → Información → Servidor. Ahí aparece la versión de PHP que está ejecutando realmente el sitio.

También suele estar disponible en el panel de control del proveedor de hosting. Si el servidor es administrado por un proveedor, el responsable del sitio debería comprobar si el proveedor ya ha desplegado el parche y qué versión o paquete identifica como corregido.

PHP 8.1 Y VERSIONES ANTERIORES PHP 8.1 y ramas anteriores ya no reciben actualizaciones normales de seguridad del proyecto PHP. Eso convierte este incidente en un problema mayor para instalaciones antiguas.

PHP indica que algunos proveedores Linux y servicios LTS pueden ofrecer correcciones mediante backport. Además, debido a la gravedad de estos fallos, el equipo de seguridad de PHP ha publicado backports mínimos de código fuente para: - PHP 7.4; - PHP 8.0; - PHP 8.1.

Eso no significa que esas ramas vuelvan a estar soportadas oficialmente. Son parches excepcionales para ayudar a organizaciones que compilan desde código fuente o que no tienen acceso inmediato a un proveedor LTS.

La recomendación sigue siendo migrar a una rama soportada. PHP 8.2 TAMBIÉN NECESITA PLAN DE SALIDA PHP 8.2 dispone de la versión corregida 8.2.35.

Sin embargo, PHP recuerda que esta rama alcanza su fin de vida el 31 de diciembre de 2026. Por tanto, actualizar 8.2.34 a 8.2.35 resuelve esta emergencia concreta, pero no elimina la necesidad de preparar una migración a una rama con soporte posterior a diciembre.

¿SIRVE UN WAF? WordPress señala que algunos proveedores pueden desplegar reglas WAF como medida de reducción de riesgo.

PHP también publica mitigaciones temporales para rutas concretas de ambas vulnerabilidades. Pero hay que mantener una diferencia esencial: MITIGACIÓN ≠ CORRECCIÓN.

PHP afirma que las medidas temporales no convierten una instalación vulnerable en segura. Para CVE-2026-109618 se describen medidas relacionadas con límites de memoria y tamaño de peticiones.

Para CVE-2026-109619 se describen cambios como desactivar determinadas funciones de progreso de subida de sesiones y reiniciar workers, además de otras defensas específicas. Son medidas para reducir exposición mientras se actualiza.

No son una razón para posponer la actualización. QUÉ DEBE HACER UNA ORGANIZACIÓN Una respuesta mínima debería incluir: 1.

identificar todos los servidores que ejecutan PHP; 2. identificar qué aplicaciones están expuestas a Internet; 3.

comprobar la versión real de PHP; 4. comprobar si el proveedor ya ha aplicado un paquete corregido; 5.

actualizar a una versión corregida; 6. reiniciar los procesos o servicios cuando el proveedor o el procedimiento de actualización lo requiera; 7.

verificar después que la versión corregida está realmente cargada; 8. revisar servidores olvidados, staging públicos, subdominios e instalaciones antiguas; 9.

documentar excepciones que no puedan actualizarse; 10. migrar ramas sin soporte en lugar de dejarlas permanentemente en parches excepcionales.

No basta con actualizar “el sitio principal”. Un servidor PHP olvidado puede seguir siendo una superficie de ataque.

QUÉ VERSIONES DEBEN CONSIDERARSE CORREGIDAS Para las ramas soportadas directamente por PHP: - 8.5 → 8.5.12 o posterior; - 8.4 → 8.4.27 o posterior; - 8.3 → 8.3.36 o posterior; - 8.2 → 8.2.35 o posterior.

Para distribuciones Linux y proveedores LTS: hay que seguir el boletín del proveedor, porque puede existir un paquete con número de versión anterior pero con el parche aplicado mediante backport. Esto es especialmente importante en Debian, Ubuntu, RHEL y otros entornos que mantienen ramas mediante parches propios.

QUÉ NO DEBE HACERSE No conviene: - asumir que actualizar WordPress corrige PHP; - asumir que un WAF elimina el riesgo; - asumir que “no usamos mod_php” significa “no estamos afectados”; - dejar PHP 8.1 o anterior expuesto sin comprobar soporte del proveedor; - basarse únicamente en el número de versión si la distribución utiliza backports; - posponer la actualización esperando una prueba pública de explotación.

La ausencia de una explotación pública conocida no convierte una RCE crítica en segura. ¿HAY EXPLOTACIÓN ACTIVA?

El aviso previo de PHP explicaba que el equipo se reservaba el derecho a publicar antes de tiempo si aparecían detalles públicos o evidencia de explotación activa.

En la información oficial revisada por RadarAbierto no se afirma que exista explotación generalizada en Internet en el momento de esta publicación. Por tanto, RadarAbierto no la da por demostrada.

La urgencia no depende de esa condición. Dos RCE sin autenticación con CVSS 9.2 y sin mitigación completa justifican por sí solas la actualización inmediata.

QUÉ HA COMPROBADO RADARABIERTO RadarAbierto ha contrastado la alerta de WordPress con el aviso primario del proyecto PHP.

PHP confirma: - dos vulnerabilidades críticas; - CVE-2026-109618 y CVE-2026-109619; - CVSS v4.0 9.2 para ambas; - posible RCE sin autenticación; - exposición de instalaciones que sirven peticiones web; - riesgo especialmente alto demostrado en mod_php; - versiones corregidas 8.5.12, 8.4.27, 8.3.36 y 8.2.35; - ausencia de una mitigación completa distinta de actualizar; - disponibilidad de algunos backports excepcionales para ramas antiguas.

WordPress confirma además que no es necesaria una actualización de WordPress Core para estos fallos.

RECURSOS Aviso oficial de PHP: https://www.php.net/ WordPress — Critical PHP Security Release: https://wordpress.org/news/2026/10/critical-php-security-release/ Descargas oficiales de PHP: https://www.php.net/downloads.php QUÉ SEGUIREMOS RadarAbierto seguirá: - explotación pública o inclusión en catálogos de vulnerabilidades explotadas; - avisos de CISA, NCSC y otros CERT; - paquetes corregidos de distribuciones Linux; - confirmaciones de proveedores de hosting; - nuevos detalles técnicos de ambos CVE; - posibles cambios en mitigaciones; - y el proceso de retirada de PHP 8.2 antes de su fin de vida del 31 de diciembre de 2026.

Cómo ha evolucionado

Primer registro en RadarAbierto: 21/10/2026. Estado actual: actual.

Añadiremos los cambios posteriores sin borrar este registro.

Seguir el contexto

La señal conserva procedencia y relaciones internas para que puedas comprobar el origen y explorar cambios relacionados.