PHP alerta de dos fallos críticos y prepara parches de emergencia

PHP se prepara para publicar una actualización extraordinaria de seguridad por dos vulnerabilidades críticas que han encendido las alarmas entre administradores de servidores, empresas de alojamiento web y responsables de miles de aplicaciones. Los dos fallos han recibido una puntuación de 9,2 sobre 10 en CVSS v4.0, una gravedad poco habitual que explica que el proyecto haya roto su calendario normal de actualizaciones.

La publicación de los parches está programada para este miércoles 21 de octubre a las 14:00 UTC, las 16:00 en la España peninsular. Hasta entonces, PHP mantiene bajo embargo buena parte de los detalles técnicos, incluidas las versiones exactamente afectadas y las condiciones necesarias para explotar los errores. Investigadores de seguridad que conocen las vulnerabilidades apuntan a un posible escenario de ejecución remota de código, o RCE, uno de los riesgos más serios que puede afrontar un servidor.

Dos vulnerabilidades críticas obligan a PHP a reaccionar

El episodio comenzó a acelerarse después de que aparecieran públicamente datos sobre dos vulnerabilidades que todavía estaban sometidas a embargo. A partir de ahí, el equipo de seguridad de PHP decidió comunicar de forma anticipada que preparaba una versión extraordinaria y pidió a los usuarios que estuvieran listos para actualizar sus sistemas en cuanto estuvieran disponibles los paquetes corregidos.

Los identificadores que circulan entre investigadores son CVE-2026-109618 y CVE-2026-109619, aunque el primer aviso oficial de PHP no los menciona expresamente. Tampoco confirma algunas de las afirmaciones aparecidas tras la filtración, como que todas las versiones de PHP desde la rama 5 estén afectadas. Ese extremo, importante, sigue pendiente de la documentación técnica definitiva.

El nombre PHP2Shell también ha empezado a utilizarse para referirse conjuntamente a los dos fallos. No es una denominación oficial de PHP, sino una etiqueta surgida en el ámbito de la ciberseguridad. Parece un detalle menor, pero no lo es: en las horas previas a la publicación de un parche crítico se mezclan con facilidad información confirmada, investigaciones privadas y rumores que acaban circulando como hechos.

PHP, por el momento, ha confirmado lo esencial: existen dos vulnerabilidades críticas, ambas con una puntuación de 9,2, y requieren una respuesta de seguridad extraordinaria.

Qué implica una posible ejecución remota de código

Una vulnerabilidad de ejecución remota de código puede permitir que un atacante consiga ejecutar instrucciones en una máquina vulnerable desde el exterior. Eso no significa automáticamente que cualquier página construida con PHP pueda ser tomada al instante. Para medir el riesgo real hay que conocer las condiciones concretas del fallo, precisamente uno de los datos que todavía falta.

Puede existir una vulnerabilidad gravísima que solo funcione bajo una configuración determinada, utilizando cierto componente o cuando el servidor expone una funcionalidad concreta. También puede suceder lo contrario: que el vector de ataque sea relativamente sencillo y pueda explotarse a gran escala. Hasta la publicación del boletín técnico, convertir cualquiera de esos escenarios en certeza sería adelantarse a los hechos.

La puntuación CVSS 9,2, sin embargo, deja poco espacio para la complacencia. CVSS es el sistema empleado habitualmente para medir la gravedad de las vulnerabilidades teniendo en cuenta factores como el impacto, la complejidad del ataque o los privilegios necesarios. Una nota superior a nueve entra de lleno en la categoría crítica.

De ahí el tono poco habitual del aviso: PHP ha pedido a sus usuarios que estén preparados para actualizar inmediatamente cuando las nuevas versiones estén disponibles. Incluso podría adelantarse la publicación si los detalles técnicos quedan completamente expuestos o aparecen evidencias de explotación.

Los parches de emergencia llegarán a las 16:00 en España

El momento decisivo está previsto para las 16:00, hora peninsular española. Será entonces cuando deberían conocerse con mayor precisión los componentes afectados, las ramas vulnerables y las versiones que incorporan la corrección.

En estos momentos, las ramas mantenidas oficialmente son PHP 8.2, 8.3, 8.4 y 8.5. Antes de esta actualización extraordinaria, las últimas versiones publicadas eran PHP 8.2.34, 8.3.35, 8.4.26 y 8.5.11. Para los administradores, identificar la versión instalada se convierte así en uno de los primeros datos relevantes antes de aplicar el parche.

Las versiones antiguas plantean un problema añadido

Aquí aparece una segunda cuestión, bastante menos vistosa pero posiblemente más incómoda. Una parte de Internet continúa utilizando versiones antiguas de PHP que ya han terminado su ciclo de soporte y no reciben las mismas actualizaciones que las ramas actuales.

PHP mantiene cada versión durante varios años, primero con soporte activo y después con correcciones limitadas a problemas de seguridad. Actualmente, PHP 8.2 y 8.3 reciben únicamente actualizaciones de seguridad, mientras que 8.4 y 8.5 continúan dentro de su periodo de soporte activo. PHP 8.1 y las ramas anteriores están fuera del soporte oficial.

Si las vulnerabilidades terminan afectando también a esas versiones antiguas, el problema dejaría de ser simplemente pulsar el botón de actualizar. Algunas instalaciones podrían necesitar una migración hacia una rama mantenida, algo más delicado para webs antiguas, aplicaciones hechas a medida o sistemas que llevan años funcionando con dependencias congeladas.

Ahí aparece una de las paradojas de la web: una aplicación puede funcionar durante años, silenciosa como una nevera vieja, hasta que surge un agujero de seguridad y aquella aparente estabilidad empieza a parecer menos una virtud y más una deuda técnica acumulada.

Qué deben revisar propietarios de webs y administradores

La prioridad no está tanto en WordPress, Drupal, una tienda electrónica o cualquier otro programa concreto como en la versión de PHP que ejecuta el servidor. PHP trabaja por debajo de una enorme cantidad de páginas y aplicaciones; tener actualizado el gestor de contenidos no garantiza necesariamente que el intérprete PHP del alojamiento también lo esté.

Antes de los parches definitivos tampoco existe un procedimiento universal de mitigación publicado por PHP. Lo esencial es identificar qué versión utiliza cada servidor y tener preparado el proceso de actualización, especialmente en sistemas accesibles directamente desde Internet. En alojamientos gestionados, el cambio puede depender del proveedor y no del propietario de la página.

Actualizar deprisa no significa actualizar a ciegas

También conviene evitar la reacción opuesta: saltar varias versiones principales en una web de producción sin comprobar nada. Seguridad y compatibilidad deben ir de la mano. Una aplicación antigua que cambia bruscamente de rama puede encontrarse con funciones eliminadas, extensiones incompatibles o código que dejó de ser válido hace tiempo.

En servidores críticos resulta especialmente importante disponer de copias de seguridad recientes, comprobar la actualización cuando sea posible y verificar después que PHP, el servidor web, las extensiones y la aplicación siguen funcionando correctamente. La urgencia de un parche no convierte una actualización improvisada en buena administración.

No constan ataques activos confirmados por el momento

Otro dato importante rebaja, al menos de momento, la temperatura del asunto. No se han comunicado públicamente ataques activos confirmados que estén aprovechando de forma general estas dos vulnerabilidades y tampoco existe un exploit público ampliamente disponible que permita reproducirlas.

Esa situación, eso sí, puede cambiar cuando aparezcan los detalles técnicos. Después de cada gran parche comienza una carrera bastante conocida: los administradores estudian la actualización para instalarla y los atacantes la examinan para descubrir exactamente qué se ha corregido. En ocasiones, comparar el código antiguo con el nuevo permite reconstruir la vulnerabilidad.

Por eso las primeras horas posteriores a la publicación pueden resultar especialmente sensibles. Los servidores correctamente mantenidos reciben el arreglo; los abandonados permanecen quietos. Y ese segundo grupo empieza a destacar, metafóricamente, como una ventana iluminada en una calle oscura.

El boletín definitivo marcará la dimensión real del fallo

Hasta que PHP publique toda la documentación, hay tres elementos que conviene mantener separados: el proyecto ha confirmado dos vulnerabilidades críticas con gravedad 9,2, investigadores especializados las relacionan con ejecución remota de código y el alcance exacto continúa pendiente de confirmación técnica.

La actualización extraordinaria permitirá conocer qué instalaciones son realmente vulnerables y qué versiones solucionan el problema. Será entonces cuando pueda medirse la dimensión de PHP2Shell más allá del nombre inquietante y del inevitable ruido que acompaña a una alerta de esta magnitud.

Lo que sí está claro es que se trata de una situación poco corriente. PHP no acostumbra a adelantar una actualización crítica mediante un aviso de estas características. Cuando una tecnología presente en una parte enorme de la web pide a sus usuarios que estén preparados para parchear en cuanto aparezcan nuevas versiones, el mensaje merece atención: sin alarmismo, pero sin aplazar una actualización crítica.