PHP ha muerto, y hace diez días hubo que parchear medio internet

Esta semana me ha llegado por tres sitios distintos el mismo meme. Es una lista de años, y en cada año alguien da a PHP por muerto y recomienda pasarse a otra cosa: ColdFusion, ASP.NET, Django, Ruby on Rails, Flask, AngularJS, Next.js, Python y, para 2025, «cualquier otra cosa». La última línea es la de 2026: PHP acaba de publicar dos vulnerabilidades críticas de ejecución remota, se rompió el embargo, el parche sale el 21 de octubre a las 14:00 UTC y, si tienes una versión antigua, «entrega ya tu servidor». Debajo, el logotipo de PHP con los brazos abiertos: «Como podéis ver, no estoy muerto».

Meme anónimo que circula en redes, sobre un fotograma de Black Panther (Marvel Studios, 2018). Reproducido a título de cita. Derechos de sus titulares.

Tiene gracia porque el remate es verdad. Como llevo más de veinte años escribiendo PHP y oyendo que está muerto, me he tomado la molestia de revisarlo.

Las esquelas

La lista no pretende fechar nada: cuenta cuándo se puso de moda decir que había que dejar PHP por otra cosa. Aun así, un par de líneas tienen su gracia mirándolas de cerca. La primera esquela es de 1995, el año en que Rasmus Lerdorf anunció PHP, así que lo enterraron con unos meses de vida. La de 2003 recomienda Django, que entonces era una herramienta interna de un periódico de Kansas y no se publicó hasta 2005: había que aprenderlo dos años antes de poder descargarlo. Y en 2022 la alternativa moderna era Python, que es de 1991, cuatro años mayor que PHP.

Ninguno de esos lenguajes y frameworks es malo, y varios los uso yo. Lo que falla es la idea de que la llegada de uno nuevo jubila al anterior. En la web eso no pasa casi nunca, porque lo que ya funciona sigue funcionando y nadie lo reescribe por gusto.

Y lo de 2026, también

La última línea del meme es casi toda cierta, y la conté con detalle el día del parche en «PHP2Shell: los dos fallos de PHP que hay que parchear hoy». En resumen:

• Dos fallos críticos de ejecución remota: cierto. CVE-2026-109618 y CVE-2026-109619, con un 9,2 sobre 10 en CVSS v4, que permiten ejecutar órdenes en el servidor sin usuario ni contraseña.
• Se rompió el embargo: cierto. El 20 de octubre un mensaje en Hacker News, borrado después, adelantó que venían dos fallos gordos, y watchTowr confirmó a la prensa que eran reales.
• watchTowr se equivocó y escribió 2926: no he encontrado ni rastro de eso, ni en sus publicaciones ni en la prensa que las cita. Si alguien lo tecleó así, lo corrigió pronto. Lo dejo como lo que es en el meme: un chiste.
• El parche, el 21 de octubre a las 14:00 UTC: cierto. Salieron PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, según el aviso de php.net.
• «Solo PHP 8 en adelante»: a medias. El proyecto sacó versión nueva para las ramas 8.2 a 8.5. Para la 7.4, la 8.0 y la 8.1 publicó los arreglos como código fuente, para quien compila PHP o mantiene esas ramas por su cuenta, pero no una versión que se instale sin más.
• Si tienes una versión antigua, entrega el servidor: exagerado, pero menos de lo que parece. Lo explico más abajo, porque es la parte del meme que más importa.

Desde entonces ha habido ataques reales, y el 26 de octubre CISA, la agencia de ciberseguridad de Estados Unidos, metió los dos fallos en su catálogo de vulnerabilidades que se están explotando.

Por qué no se muere

Ilustración generada con IA para este artículo.

Según los datos de W3Techs consultados el 30 de octubre, PHP está detrás del 69,2 % de las webs cuyo lenguaje de servidor se puede identificar. Lleva años bajando poco a poco, y aun así tiene más que todos los demás juntos. Y WordPress, que está escrito en PHP, mueve por sí solo el 39,5 % de todas las webs.

No es nostalgia ni pereza. Hay razones bastante prosaicas:

• Está en todas partes. Desde principios de los 2000 cualquier hosting barato trae PHP sin que lo pidas, y subir un fichero y que funcione sigue siendo la forma más corta de pasar de no tener web a tenerla.
• WordPress y compañía. Una parte enorme de la web son webs de negocios pequeños, y esas webs las mueven WordPress, Drupal, PrestaShop o Moodle. Mientras esos programas estén escritos en PHP, PHP no se va a ninguna parte.
• Cambió mucho mientras le hacían las esquelas. El PHP que daban por muerto en 2004 era otro lenguaje. PHP 7, a finales de 2015, fue en muchos casos el doble de rápido que su predecesor. PHP 8, en 2020, trajo un sistema de tipos mucho más serio, compilación JIT y una sintaxis que ya no da vergüenza enseñar. Composer resolvió las dependencias, Laravel y Symfony pusieron orden, y desde 2021 hay una PHP Foundation que paga a gente para que trabaje en el lenguaje.

De esa época tengo un recuerdo en la estantería de la oficina. Cuando todavía compraba libros de programación, compré uno de PHP 6. Lo guardo con cariño, porque es de una versión que nunca llegó a publicarse.

Mi ejemplar de PHP 6 and MySQL 5 for Dynamic Web Sites (Larry Ullman, Peachpit Press, 2008), en la oficina. Foto propia; portada reproducida a título de cita, derechos de sus titulares.

PHP 6 iba a traer soporte nativo de Unicode, y la portada lo anuncia: la palabra se repite en el fondo naranja una y otra vez. Ese cambio acabó atascando el proyecto: se empezó en 2005 y en 2010 se abandonó por lo difícil que resultaba implementarlo. Cuando en 2014 tocó ponerle nombre a la siguiente versión, se votó saltarse el 6 y llamarla PHP 7, entre otras cosas porque ya había libros y tutoriales sobre un PHP 6 que no era ese. Uno de esos libros es el mío.

Esta misma web es PHP 8.3 con CodeIgniter 4. No lo elegí por llevar la contraria: lo elegí porque es lo que mejor conozco, porque se despliega en cualquier sitio y porque hay una comunidad enorme detrás, así que quien venga después de mí encontrará documentación, librerías y gente que sepa mantenerlo.

Y está la paradoja que retrata el meme, aunque no por donde parece. Que se descubra un fallo no demuestra que un lenguaje esté vivo: también se encuentran fallos en programas abandonados, y ahí se quedan. Lo que demuestra que PHP está vivo es lo que pasó después. Dos equipos reportaron los fallos en agosto, el proyecto los corrigió en cuatro ramas a la vez y publicó los arreglos para otras tres, Ubuntu tenía sus paquetes corregidos ese mismo día, Cloudflare desplegó reglas de cortafuegos también en su plan gratuito y CISA lo añadió a su catálogo cinco días después. Eso es un ecosistema mantenido respondiendo, y solo se organiza así alrededor de lo que está debajo de millones de servidores. El ecosistema Java pasó por lo mismo en diciembre de 2021 con Log4Shell, un fallo en la librería Log4j, y nadie concluyó que Java hubiera muerto.

Tampoco es que PHP sea especialmente inseguro. Es que lo que está en todas partes, cuando falla, falla en todas partes.

Lo que sí está muerto

Aquí el meme acierta sin querer. En PHP lo que muere no es el lenguaje, son las versiones. Cada rama tiene una fecha a partir de la cual el proyecto deja de corregirle fallos de seguridad: la 7.4 la tuvo en noviembre de 2022, la 8.0 en noviembre de 2023 y la 8.1 el 31 de diciembre de 2025. A partir de ahí la versión sigue funcionando, pero el proyecto ya no la mantiene ni garantiza que vaya a corregirle nada. Este mes publicó, por la gravedad del caso, los arreglos para 7.4, 8.0 y 8.1 como código fuente, pero no una versión nueva que se instale, y con el próximo fallo puede que ni eso.

Y las cifras de W3Techs del 30 de octubre dicen esto sobre las webs en PHP que dejan ver su versión:

Sumado, casi la mitad de las webs en PHP que dicen su versión están en una rama para la que el proyecto no sacó versión nueva el 21 de octubre. Hay que leerlo con cuidado: muchas distribuciones Linux siguen corrigiendo sus versiones antiguas por su cuenta (Ubuntu 22.04 ya tiene arreglado su PHP 8.1), así que una web que anuncia 8.1 puede estar parcheada. Con PHP 5 es otra historia: lleva desde finales de 2018 fuera del soporte oficial, y una de cada trece webs en PHP lo sigue anunciando. Si la tuya es una de ellas, toca revisarla ya.

Así que el «entrega ya tu servidor» es exagerado, pero tiene base. Una web en PHP 5 o en un PHP 7 que no mantiene nadie no se ha vuelto un problema este mes. Lleva años acumulando riesgo, y este mes vuelve a quedar claro por qué importa mantenerla. Es lo que contaba en «No necesito mantenimiento web»: una web no se rompe un día concreto, se va quedando atrás, y un día como el 21 de octubre se cobra toda la deuda de golpe.

Lo que me llevo del meme

Que PHP lleva treinta años muriéndose y sigue detrás de casi siete de cada diez webs de las que se sabe en qué están hechas. Y que la pregunta útil no es si PHP está vivo, sino si lo está la versión que tienes.

Si no lo sabes, en WordPress está en Herramientas → Salud del sitio → Información → Servidor, y en «Vulnerabilidad crítica: qué significa y qué puede pasar de verdad» expliqué a quién le toca actualizar cada cosa. Si tu versión está fuera del soporte oficial y no sabes si tu proveedor sigue manteniéndola, o si no tienes claro quién debería ocuparse, escríbeme: actualizar el servidor suele ser lo fácil, y lo que lleva trabajo es dejar la web funcionando en una versión que siga recibiendo parches.