PHP no estaba muerto: la noche en que internet recordó que todavía dependía de él

Hay algo curioso en la industria tecnológica: a veces declaramos muerto a un paciente que sigue trabajando ocho horas al día, mantiene a su familia y paga las cuentas de la casa.

Con PHP llevamos años haciendo exactamente eso.

Cada cierto tiempo aparece un nuevo lenguaje, un framework revolucionario o una arquitectura que promete cambiarlo todo. Entonces alguien publica un artículo explicando por qué PHP pertenece al pasado. Otro anuncia que ya nadie debería utilizarlo. Un tercero recomienda reescribirlo todo en la tecnología de moda.

Y, mientras tanto, millones de sitios web siguen funcionando.

Tiendas que venden productos. Blogs que publican historias. Empresas que reciben clientes. Foros que mantienen comunidades vivas. Sistemas que procesan pedidos mientras sus propietarios duermen.

Una parte enorme de ese mundo funciona gracias a PHP.

Pero el 21 de octubre de 2026, la conversación cambió.

Por unos días, el viejo lenguaje que supuestamente estaba muerto volvió a ocupar los titulares. No porque hubiera lanzado una nueva versión revolucionaria, ni porque una gran empresa lo hubiera elegido para construir el futuro.

Esta vez, la noticia era mucho menos agradable.

Habían encontrado dos vulnerabilidades críticas en su propio núcleo.

Y no eran precisamente errores que pudieran descartarse con un «bueno, a todos nos pasa».

El gigante que nadie mira

Imaginemos por un momento un edificio gigantesco.

No es especialmente bonito. Su arquitectura ya no impresiona a los visitantes. En los últimos años, han construido edificios más modernos, con mejores materiales y diseños que aparecen en las portadas de las revistas.

Los arquitectos jóvenes se burlan de sus pasillos. Los críticos aseguran que su estructura está anticuada. Algunos incluso anuncian que pronto será demolido.

Pero hay un detalle que todos olvidan: el edificio está lleno de gente.

Miles de personas trabajan allí cada día. Hay negocios, oficinas, almacenes y puertas por las que entran y salen millones de visitantes. El edificio no es una reliquia abandonada. Es parte de la infraestructura de una ciudad.

Ese edificio podría ser PHP.

Durante años, el lenguaje ha cargado con una reputación difícil de sacudir. Se le critica por sus decisiones históricas, por las particularidades de su sintaxis y por el legado que arrastra desde los primeros días de la web dinámica.

Algunas críticas son legítimas. PHP tiene una historia larga, y esa historia incluye decisiones que hoy probablemente se tomarían de otra manera.

Pero una cosa es reconocer sus defectos y otra muy distinta confundirlos con su desaparición.

Según los datos publicados por W3Techs en octubre de 2026, PHP estaba presente en aproximadamente el 69,7 % de los sitios web cuyo lenguaje de servidor se conoce.

No significa que controle literalmente el 69,7 % de todo lo que existe en internet. La estadística tiene un alcance concreto. Pero incluso con esa precisión, el número es extraordinario.

No estamos hablando de una tecnología que sobrevive en tres proyectos abandonados.

Estamos hablando de uno de los pilares sobre los que se ha construido la web que conocemos.

Y ahí aparece la paradoja: cuanto más invisible se vuelve una tecnología, más fácil resulta olvidar lo importante que es.

Hasta que algo falla.

La grieta en los cimientos

Las vulnerabilidades conocidas como PHP2Shell afectaron al núcleo de PHP y fueron identificadas como CVE-2026-109618 y CVE-2026-109619.

Los investigadores demostraron que los fallos podían permitir, bajo las condiciones de explotación correspondientes, ejecutar código de forma remota sin autenticación o acceder a información sensible de la memoria del proceso.

Ambas vulnerabilidades recibieron una puntuación de gravedad de 9,2 sobre 10 según CVSS 4.0.

El proyecto PHP publicó versiones corregidas el 21 de octubre.

La noticia tenía todos los ingredientes para provocar una alarma considerable: un componente fundamental, una superficie de exposición enorme y fallos que no dependían necesariamente de que la aplicación construida sobre PHP tuviera un error propio.

En otras palabras, no bastaba con mirar el código de una página web y preguntarse si su desarrollador había cometido un fallo.

El problema estaba más abajo, en una pieza de la maquinaria que muchas aplicaciones compartían.

Y eso cambia la naturaleza de la conversación.

Cuando una aplicación tiene una vulnerabilidad, podemos señalar el componente afectado y estudiar su alcance. Pero cuando el problema se encuentra en el entorno que ejecuta miles de aplicaciones distintas, la preocupación deja de estar confinada a un solo proyecto.

De pronto, la pregunta ya no es únicamente si una página concreta es vulnerable.

La pregunta es cuántas páginas dependen de una pieza de software que acaba de revelar un fallo grave.

No todas las instalaciones tienen la misma configuración ni presentan exactamente el mismo riesgo. Tampoco significa que todos los sitios afectados hayan sido comprometidos.

Pero la dimensión potencial del problema basta para recordarnos algo incómodo: la infraestructura que damos por sentada puede convertirse, de un día para otro, en nuestra mayor preocupación.

Y aquí es donde la historia deja de ser exclusivamente sobre PHP.

El pasado nunca se va del todo

Una de las particularidades del software es que rara vez construimos sobre terreno completamente nuevo.

Construimos sobre bibliotecas escritas hace años, decisiones heredadas, sistemas que nadie quiere reemplazar porque todavía funcionan y componentes que han pasado por tantas manos que ya resulta difícil recordar quién tomó cada decisión.

La web moderna es, en buena medida, una acumulación de capas.

Encima de una capa construimos otra. Luego añadimos un framework, una base de datos, un sistema de caché, una integración externa y un par de servicios que prometen hacerlo todo más rápido.

Con el tiempo, dejamos de pensar en los cimientos.

Nos importa que la aplicación funcione. Que la página cargue. Que los clientes puedan comprar. Que el sistema no se caiga durante una campaña importante.

Y mientras todo va bien, nadie quiere dedicar demasiado tiempo a preguntarse qué hay debajo.

PHP2Shell nos recordó que el código antiguo no necesita parecer antiguo para seguir teniendo consecuencias en el presente.

Según la investigación publicada por Wiz, los fallos habían permanecido en el código durante años y su explotación requería encadenar condiciones complejas. La investigación también mostró cómo las herramientas de inteligencia artificial podían ayudar a superar barreras técnicas que antes hacían mucho más difícil convertir ciertos errores en ataques prácticos.

Hay algo inquietante en esa combinación.

Durante años, una vulnerabilidad puede permanecer escondida, no necesariamente porque sea imposible encontrarla, sino porque comprenderla y demostrar cómo explotarla exige un trabajo considerable.

Después, las herramientas cambian. Los métodos de investigación mejoran. Las barreras disminuyen.

Y lo que ayer parecía demasiado complejo para convertirse en un ataque práctico puede dejar de serlo.

El software no tiene que empeorar para volverse más peligroso.

A veces, basta con que el mundo aprenda a mirar sus defectos de otra manera.

«PHP está muerto»

Volvamos ahora a quienes llevan años anunciando su funeral.

Es fácil burlarse de PHP. También es fácil defenderlo con estadísticas, señalar cuántos sitios lo utilizan y concluir que sus detractores están equivocados.

Pero creo que ambas reacciones se quedan cortas.

Que una tecnología sea ampliamente utilizada no significa que sea perfecta. Que tenga defectos no significa que sea inútil. Y que aparezca una vulnerabilidad crítica tampoco demuestra, por sí solo, que haya llegado su hora de desaparecer.

La seguridad es una propiedad que debemos mantener, no una medalla que una tecnología gana para siempre.

Los lenguajes más modernos también tienen vulnerabilidades. Los frameworks más elegantes también dependen de bibliotecas que pueden fallar. Los sistemas diseñados con las mejores intenciones pueden arrastrar errores durante años.

La diferencia está en cómo se descubren esos problemas, cómo se corrigen y qué hacen quienes mantienen los sistemas cuando llega el momento de actuar.

Por eso, si alguien utiliza PHP2Shell como prueba definitiva de que PHP está muerto, está confundiendo dos discusiones distintas.

Una trata sobre la evolución y las limitaciones de un lenguaje.

La otra trata sobre la seguridad de una infraestructura que sigue teniendo una presencia enorme en internet.

La segunda merece toda nuestra atención. Pero no resuelve automáticamente la primera.

Quizá PHP no sea la mejor opción para todos los proyectos nuevos. Quizá existan herramientas más adecuadas para determinadas necesidades. Quizá haya decisiones históricas de su diseño que hoy preferiríamos no haber tomado.

Todo eso puede discutirse.

Lo que no tiene demasiado sentido es celebrar la caída de una tecnología sin preguntarse qué ocurriría si desapareciera mañana.

Porque PHP no existe en un vacío. Vive dentro de aplicaciones, plataformas, empresas y servicios que tienen usuarios reales.

Y cuando hablamos de su seguridad, no estamos hablando únicamente de una discusión entre programadores.

Estamos hablando de personas que compran, trabajan, publican, estudian y confían sus datos a sistemas construidos con ese lenguaje.

El verdadero drama no es que PHP tenga una vulnerabilidad

El verdadero drama es que dependemos de muchísimo software que casi nunca vemos.

Nos hemos acostumbrado a pensar en internet como un servicio permanente. Abrimos una página y esperamos que funcione. Compramos un producto y esperamos que el pago se procese. Accedemos a una cuenta y esperamos encontrar nuestros datos.

No solemos preguntarnos qué versión del intérprete ejecuta el servidor, cuándo se actualizó una biblioteca o si alguien sigue manteniendo una pieza de código escrita hace quince años.

No tenemos por qué hacerlo todos. Para eso existen profesionales, equipos de mantenimiento y proveedores de infraestructura.

Pero esa invisibilidad tiene un precio.

Cuando algo sale mal, descubrimos que la experiencia sencilla que tenemos frente a la pantalla depende de una cantidad enorme de decisiones técnicas, muchas de ellas tomadas mucho antes de que llegáramos.

PHP2Shell no significa que internet vaya a desaparecer ni que todos los sitios construidos con PHP estén comprometidos. Sería exagerado decirlo.

Sin embargo, sí nos obliga a mirar una realidad menos espectacular y bastante más importante: la estabilidad de la web depende del trabajo continuo de quienes mantienen sus cimientos.

Ese trabajo rara vez recibe aplausos.

Nadie suele publicar un artículo viral porque un administrador actualizó correctamente un servidor un martes por la tarde. No hay conferencias multitudinarias para celebrar que una dependencia se mantuvo al día durante cinco años. Y difícilmente alguien escribirá un hilo épico sobre un equipo que evitó un incidente gracias a una rutina de mantenimiento bien ejecutada.

Las buenas decisiones de mantenimiento suelen producir un resultado extraordinariamente aburrido: nada ocurre.

El sitio sigue funcionando. Los clientes siguen comprando. Los usuarios siguen entrando.

Y todo el mundo se olvida de quienes hicieron posible que así fuera.

Hasta la próxima alarma.

¿Y si dejáramos de confundir lo nuevo con lo mejor?

La industria tecnológica tiene una relación particular con la novedad.

Cada cierto tiempo aparece algo que promete resolver los problemas de la generación anterior. Cambiamos herramientas, reescribimos aplicaciones y aprendemos nuevos paradigmas. A veces, esos cambios son necesarios y mejoran de verdad las cosas.

Otras veces, simplemente cambiamos el vocabulario con el que describimos los mismos problemas.

El software moderno también necesita mantenimiento. Las arquitecturas distribuidas también pueden fallar. Los sistemas construidos con tecnologías recientes también acumulan deuda técnica.

No existe una generación de herramientas que nos permita dejar de ser responsables de lo que construimos con ellas.

Y quizá esa sea la lección más interesante de esta historia.

El futuro de la web no depende únicamente de inventar tecnologías nuevas. También depende de mantener las que ya sostienen una parte importante del presente.

PHP puede evolucionar, perder terreno en determinados ámbitos o seguir siendo relevante durante muchos años. No hace falta convertirlo en un héroe para reconocer su importancia, ni en un villano para admitir sus problemas.

Lo que sí necesitamos es abandonar la idea de que una tecnología deja de merecer atención cuando deja de estar de moda.

Porque los sistemas que más necesitan mantenimiento no siempre son los más interesantes.

A veces son aquellos que llevan tanto tiempo funcionando que hemos dejado de pensar en ellos.

El gigante sigue en pie

Al final, PHP2Shell no es una historia con un desenlace sencillo.

No hay un villano derrotado para siempre. No existe un lenguaje que haya demostrado su superioridad absoluta. Tampoco tenemos motivos para declarar que PHP ha ganado otra década de vida por haber publicado parches.

Hay vulnerabilidades graves. Hay trabajo de mantenimiento que hacer. Hay sistemas antiguos que merecen una revisión seria. Y hay una comunidad que tuvo que responder a un problema importante en una pieza fundamental de la web.

También hay una realidad difícil de ignorar: PHP sigue estando presente en una proporción enorme de los sitios web cuyo lenguaje de servidor conocemos.

Quizá por eso me resulta tan curioso que llevemos tantos años hablando de su muerte.

Mientras discutíamos sobre qué lenguaje dominaría el futuro, PHP seguía ejecutando aplicaciones en el presente. Mientras algunos preparaban su epitafio, otros mantenían tiendas, blogs, plataformas y servicios que millones de personas utilizaban sin pensar en qué lenguaje había detrás.

Y cuando aparecieron las grietas, no importó demasiado cuántas veces habíamos anunciado su final.

Importó que el sistema siguiera siendo necesario.

Tal vez deberíamos dejar de preguntarnos si PHP está muerto.

La pregunta más incómoda es otra: ¿cuántas de las tecnologías que consideramos obsoletas siguen siendo demasiado importantes como para permitirnos descuidarlas?

Porque una cosa es que una tecnología haya dejado de estar de moda.

Y otra, muy distinta, es que el mundo haya dejado de depender de ella.

PHP no necesita que sus detractores lo quieran. Tampoco necesita que sus defensores lo conviertan en una religión.

Necesita que quienes lo utilizan comprendan la responsabilidad que implica mantenerlo.

El gigante no es inmortal. Nunca lo fue.

Pero sigue en pie.

Y quizá el error nunca estuvo en pensar que algún día podría caer, sino en creer que ya había dejado de importar.