Muy pocas veces el equipo que mantiene un lenguaje de programación avisa con antelación de que va a publicar parches de urgencia. Es justo lo que ha hecho el proyecto PHP, el lenguaje que funciona por debajo de una parte enorme de la web: blogs, tiendas online, foros y gestores de contenido como WordPress. Sus responsables pidieron a los administradores de sistemas que tuvieran todo listo para actualizar, porque iban a corregir dos fallos de seguridad críticos fuera del calendario habitual. Así lo contó Ars Technica.

Los dos fallos tienen identificador, CVE-2026-109618 y CVE-2026-109619, y una puntuación de gravedad de 9,2 sobre 10 en la escala CVSS 4.0. En internet ya circulan con un apodo poco tranquilizador: PHP2Shell.

Qué se sabe y qué no

Todo empezó con una filtración. El 20 de octubre apareció en Hacker News un mensaje que hablaba de dos fallos de ejecución remota de código en PHP. Según ese mensaje, afectaban a todas las versiones desde PHP 5 y se iban a hacer públicos el jueves 22. La empresa de seguridad watchTowr confirmó después que la información era auténtica y que los fallos estaban bajo embargo. Dicho de otro modo: los conocía un grupo reducido mientras se preparaba la solución. La filtración obligó a mover el calendario, y PHP fijó la publicación de los parches para el 21 de octubre a las 14:00 UTC (las 16:00 en la España peninsular). También se reservó el derecho de adelantarla si veía indicios de que alguien ya los estaba aprovechando.

Hay que separar lo confirmado de lo que todavía no lo está. Según el análisis de la empresa Huntress, en el momento del aviso no se habían publicado ni el componente afectado ni la forma de explotar los fallos, ni tampoco qué configuración hace falta para que un servidor sea vulnerable. Tampoco había pruebas de que alguien los estuviera usando en ataques reales. La lista exacta de versiones afectadas también estaba pendiente de confirmar.

Por qué «ejecución remota de código» es lo peor que se puede leer

Un fallo de ejecución remota de código (RCE, por sus siglas en inglés) permite a un atacante, desde cualquier lugar de internet, hacer que el servidor ejecute las órdenes que él quiera. En la práctica, eso es como entregarle las llaves de la máquina. Puede instalar programas, robar bases de datos o usar el equipo como base para otros ataques. De ahí el mote PHP2Shell: la idea es pasar de una simple página web en PHP a una shell, la consola de comandos del sistema.

Hay otro detalle que lo complica todo. El fallo no está en un plugin ni en una aplicación concreta. Está en el propio intérprete de PHP, la pieza sobre la que se apoyan WordPress y el resto del software escrito en este lenguaje. Por eso no basta con actualizar la web: hay que actualizar PHP en el servidor. Y en muchos casos eso depende del proveedor de alojamiento, no del dueño del sitio.

Las primeras estimaciones del sector no son tranquilizadoras. Según recoge The Hacker News, la firma Sansec calcula que los ataques masivos podrían empezar unos 15 minutos después de que se publique el parche. Ese plazo tan corto tiene una explicación: cuando sale una corrección, los atacantes comparan el código antiguo con el nuevo para averiguar qué se ha arreglado y construir un ataque.

La letra pequeña: las versiones antiguas

Aquí está el problema de fondo. Solo las ramas de PHP que siguen con soporte, de la 8.2 a la 8.5, van a recibir la corrección. Si se confirma que los fallos vienen de muy atrás, una enorme cantidad de servidores que todavía usan PHP 7 o versiones anteriores se quedarán sin parche oficial. Hay miles de webs antiguas, intranets y aplicaciones de empresa que nadie ha actualizado en años, y ahí se encuentra el mayor riesgo.

Las recomendaciones de los especialistas para administradores se resumen en estos puntos:

• Hacer inventario de todas las instalaciones de PHP, también las que vienen dentro de software de terceros.
• Tener preparada la actualización para aplicarla en cuanto salga el parche oficial.
• Aislar de internet los servidores con versiones sin soporte o, mejor aún, migrarlos.
• Vigilar comportamientos raros, como procesos de PHP que abren consolas de comandos o descargan archivos con herramientas como curl o wget.
• Guardar los registros si se detecta algo sospechoso, para poder investigarlo después.

Si tienes un blog o una tienda en un alojamiento compartido, lo más útil es comprobar en el panel qué versión de PHP usas, cambiar a una rama con soporte si puedes y preguntar a tu proveedor si ya ha aplicado la actualización.

Por qué importa

PHP es una de esas infraestructuras invisibles que sostienen buena parte de la web. Un fallo en el intérprete afecta a la vez a millones de sitios, sin importar lo bien que esté escrito cada uno. Este caso también muestra lo frágiles que son los embargos de seguridad: una filtración puede recortar los plazos de todos. Y vuelve a dejar claro que tener el software al día no es un capricho. Quien sigue con versiones abandonadas se queda fuera de las soluciones justo cuando más falta hacen.