PHP no es el patito feo

La crisis de seguridad que ha puesto en jaque a miles de servidores reabre el debate sobre uno de los lenguajes de programación más utilizados del mundo.

El martes 20 de octubre, el equipo de PHP anunció parches urgentes después de que se filtrara antes de lo previsto la existencia de dos vulnerabilidades críticas. El miércoles 21, a las 14:00 UTC, publicó las versiones corregidas. Desde entonces, administradores de sistemas y empresas de medio mundo se han apresurado a actualizar sus servidores.

El apodo, PHP2Shell, no exagera: ambos fallos pueden permitir que un atacante ejecute código en un servidor sin necesidad de iniciar sesión. Varias instituciones europeas llegaron a desconectar sus páginas web por precaución ante una amenaza que afecta a una de las tecnologías sobre las que funciona buena parte de Internet.

Como programador que vive de PHP no voy a quitarle hierro al asunto, pero tampoco voy a comprar el titular fácil de que PHP es inseguro por naturaleza.

Qué son y a quién afectan

Los dos fallos, identificados como CVE-2026-109618 y CVE-2026-109619, tienen una gravedad de 9,2 sobre 10. Ambos están relacionados con la forma en que PHP gestiona la memoria del servidor. El primero aparece cuando una petición manipulada provoca que PHP se quede sin memoria y gestione incorrectamente parte de la información. El segundo permite que una petición aproveche datos que deberían haberse eliminado al terminar la anterior. En determinadas condiciones, ambos pueden permitir que un atacante ejecute instrucciones en el servidor.

Lo especialmente preocupante es que los fallos están en el propio núcleo de PHP, no en las aplicaciones que se construyen con él. Por eso pueden afectar a webs desarrolladas con WordPress, Drupal o herramientas profesionales como Laravel y Symfony, incluso aunque su código esté correctamente escrito. En determinadas configuraciones, el ataque puede producirse antes de que la aplicación empiece siquiera a ejecutarse.

Pero hay un matiz importante. Según los investigadores de Wiz, los problemas se remontan a código que lleva más de una década funcionando. Lo que ha cambiado es nuestra capacidad para encontrar y aprovechar sus debilidades. Los modelos de Inteligencia Artificial más avanzados han permitido demostrar ataques que hasta hace poco exigían meses de trabajo de equipos altamente especializados. No estamos ante errores recién introducidos, sino ante vulnerabilidades antiguas que las nuevas herramientas han hecho mucho más peligrosas.

Siete de cada diez webs

La cifra explica el ruido. Según W3Techs, PHP está presente en el 69,3 % de las webs cuyo lenguaje de servidor se conoce. Java aparece en el 5,4 % y ASP.NET, la plataforma web de C#, en el 4,2 %. Cuando aparece una vulnerabilidad en PHP, una parte enorme de Internet puede quedar expuesta.

Hay un dato todavía más incómodo: entre las webs que utilizan PHP, el 26,9 % sigue en PHP 7 y el 7,7 % en PHP 5, ramas que el proyecto dejó de mantener hace años. Ese tercio largo de webs ancladas en el pasado refleja un problema que va mucho más allá de este incidente: la deuda técnica acumulada por organizaciones que continúan utilizando tecnologías obsoletas sin planificar su renovación.

El lenguaje puede evolucionar, mejorar su rendimiento y reforzar su seguridad, pero ninguna de esas mejoras sirve de mucho si quienes lo utilizan permanecen instalados en versiones que dejaron de recibir soporte.

Los precedentes

El historial también ayuda a poner esta crisis en perspectiva. Antes de esta semana, el catálogo de vulnerabilidades explotadas de la agencia estadounidense CISA recogía tres fallos del propio PHP: CVE-2012-1823, CVE-2019-11043 y CVE-2024-4577. No es un registro de todos los problemas de seguridad del lenguaje, pero sí una referencia útil sobre vulnerabilidades cuya explotación se ha constatado. Los tres casos anteriores requerían configuraciones específicas del servidor.

PHP2Shell rompe ese patrón porque también permite atacar determinadas instalaciones con configuraciones habituales por defecto, incluido el veterano mod_php de Apache. Por eso se ha calificado como una de las vulnerabilidades más graves de los últimos años, y no le falta razón.

¿Por qué ahora? Mi lectura es que la Inteligencia Artificial está abaratando la búsqueda de fallos en código antiguo y, sobre todo, la posibilidad de convertirlos en ataques reales. PHP, por su enorme implantación, es un objetivo especialmente atractivo. Ser el más utilizado también tiene ese precio: estás permanentemente en el punto de mira.

El patito feo que sostiene la web

Esta semana volveré a oír que PHP es el hermano pobre de Java o de C#. Pero el historial de fallos graves no distingue entre lenguajes «serios» y «de juguete».

En diciembre de 2021, Log4Shell, un fallo en una biblioteca de software ampliamente utilizada en Java, provocó una alerta internacional y permitió ataques de enorme alcance. En octubre de 2025, Microsoft corrigió en ASP.NET Core una vulnerabilidad con una gravedad de 9,9 sobre 10. Nadie concluyó por ello que Java o C# fueran lenguajes de segunda.

La diferencia es de escala: un fallo en una tecnología presente en el 69 % de las webs hace más ruido que uno en otra utilizada por el 5 %. Lo que de verdad distingue a un ecosistema es cómo responde ante sus problemas.

PHP adelantó un día la publicación de los parches tras la filtración, facilitó las correcciones con antelación a distribuciones y proveedores de soporte y proporcionó soluciones incluso para algunas ramas que ya no cuentan con mantenimiento oficial.

También sería injusto ignorar la evolución del proyecto. El PHP actual, con tipado estricto, enumeraciones, compilación JIT y entornos de desarrollo como Laravel o Symfony, poco tiene que ver con el de 2005. Es un lenguaje maduro, capaz de sostener aplicaciones complejas y servicios de gran escala. La caricatura del PHP improvisado y desordenado pertenece, en buena medida, a otra época.

Qué nos toca hacer ahora

Lo primero es obvio: actualizar hoy, no el lunes. Amazon registró un intento de explotación el 17 de octubre, cuatro días antes de la divulgación pública, así que conviene revisar los registros de actividad desde esa fecha y no limitarse al momento en que aparecieron los parches. Además, el 23 de octubre se comunicó una tercera vulnerabilidad, de alcance mucho más limitado, que obliga a comprobar determinadas configuraciones y aplicar medidas adicionales.

Lo segundo es menos cómodo. Si tu servidor sigue utilizando PHP 7 o PHP 5, tu problema no es únicamente PHP2Shell, sino la deuda técnica que llevas años acumulando. Y esta semana te ha pasado la factura.

Lo tercero afecta a quienes vivimos de este lenguaje. Defender PHP no consiste en negar sus fallos, sino en exigir que se trate como la infraestructura crítica que es: auditorías periódicas, financiación estable y migraciones planificadas. PHP no es el patito feo. Es el cisne que lleva treinta años con la mayor parte de la web a la espalda.

Gonzalo Muñoz Sánchez, Profesor del Grado en Desarrollo Full-Stack de UDIT