PHP: Veintinueve Años Dejando La Puerta Abierta

PHP2Shell, Esta Semana

El 21 de octubre de 2026 el proyecto PHP publicó cuatro versiones a la vez, 8.5.12, 8.4.27, 8.3.36 y 8.2.35, para arreglar dos fallos críticos en el propio intérprete¹. No en WordPress. No en un plugin. En PHP.

Los dos tienen un 9,2 en CVSS 4.0. Los dos permiten ejecución remota de código sin login. Los investigadores que los encontraron dicen el alcance sin rodeos: «Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4.»²

El aviso del propio proyecto PHP dice el resto:

Y ya se estaba usando antes de que se avisara a nadie. La red de honeypots de Amazon registró un intento el 17 de octubre, cuatro días antes de la publicación³. watchTowr lo vio en el mundo real el día 21, y hubo pruebas de concepto funcionales públicas a las pocas horas del parche⁴.

Los dos son fallos de seguridad de memoria. Uno está en cómo el intérprete limpia después de quedarse sin memoria. El otro es un use-after-free: la memoria de una petición se libera y luego se vuelve a leer, y la siguiente petición en el mismo worker puede verla⁵⁶. Quédate con ese segundo. Vuelve más adelante.

Nada de esto es nuevo. De eso va el post. PHP2Shell no es un accidente que le pasó a un lenguaje cuidadoso. Es la última página de un historial de casi treinta años, y cada número que hay en él es público.

Un Solo Proceso Lo Guarda Todo

De noviembre de 2014 a abril de 2017 fui ingeniero Linux de tercer nivel en la plataforma de cloud y hosting de Pulsant. Parte del trabajo era configurar entornos PHP-FPM para clientes de comercio electrónico y afinarlos para que fueran rápidos.

Las intrusiones en PHP eran habituales. No de vez en cuando. Habituales. Y se reducían a dos causas: un mal despliegue, y ninguna separación entre el front end y el back end.

El lenguaje hace que la segunda sea lo normal. Un sitio PHP típico es un solo proceso. La plantilla de la página, la lógica de negocio y el SQL viven todos en el mismo manejador de peticiones, a menudo en el mismo fichero. Ese proceso corre como un único usuario del sistema operativo. Puede leer la contraseña de la base de datos, porque la contraseña está en un fichero al lado del código. Y normalmente puede escribir en su propio web root, porque así funcionan las subidas y las actualizaciones.

Esto no es mi opinión sobre cómo se despliega PHP. Es lo que documentan PHP y WordPress.

Vuelve a leer esa última fila. El fabricante te dice cómo sería el mínimo privilegio, y luego te dice que no lo hagas, porque las actualizaciones cambian el esquema.

Compáralo con la versión separada. El front end pinta páginas y no guarda secretos. El back end es un servicio aparte con su propio usuario, una API estrecha y sin permiso de escritura sobre su propio código. La cuenta de la base de datos puede hacer lo que el back end necesita y nada más. La guía de OWASP dice lo mismo con sus palabras: «The application’s backend database should be isolated from other servers», en «a dedicated internal network segment»¹². El propio manual de PHP dice que las aplicaciones «should never connect to the database as its owner or a superuser»¹³.

Nada de eso es exótico. Es como es un proceso hecho como es debido. La razón por la que importa aquí es simple. En el modelo separado, un fallo en el front end le da al atacante un front end. En el modelo PHP de siempre, un fallo en cualquier sitio le da las plantillas, el código, las credenciales y los datos, de una vez.

PHP-FPM ayuda, y la propia guía de instalación de PHP ya lo marca como la forma recomendada de correr PHP bajo Apache⁸. Sus pools pueden arrancar workers «with different uid/gid/chroot/environment»¹⁴. Pero un pool por sitio sigue siendo un sitio por proceso, con todo lo que ese sitio tiene. Es un muro mejor entre clientes. No es un muro dentro de la aplicación.

Ten esa imagen en la cabeza en cada sección de aquí abajo. Cada fallo del historial cae sobre ese proceso.

Veintinueve Años De CVE

La National Vulnerability Database lista cada CVE presentado contra el intérprete de PHP bajo un único identificador de producto, cpe:2.3:a:php:php. Pregúntale y te contesta 757¹⁵.

Esa cifra es solo el intérprete. Ni WordPress, ni Drupal, ni plugins, ni frameworks. Solo el programa que ejecuta tu PHP.

Destacan dos picos. El primero es marzo de 2007, cuando un antiguo miembro del equipo de seguridad de PHP montó el Month of PHP Bugs, publicando fallos en el Zend Engine, el núcleo de PHP y sus extensiones «on a day by day basis»¹⁶. Había fundado el PHP Security Response Team, luego lo dejó, y dijo por qué: «I dislike the ways bugs are handled»¹⁷. Cuando el fundador del equipo de seguridad de un proyecto se va y publica un fallo al día, eso te dice cómo iban las cosas por dentro.

El segundo pico es 2016: 120 CVE, 65 de ellos de corrupción de memoria. Más sobre eso abajo.

La cifra de memoria es un suelo, no una estimación. NVD etiqueta buena parte de los fallos antiguos como «Other» en vez de con un tipo de debilidad, incluidos algunos de los use-after-free de la sección siguiente. La cifra real es más alta. Uso la que puedo demostrar.

El Motor Está Escrito En C

Aquí es donde el argumento de la seguridad de memoria hay que hacerlo con cuidado, porque un desarrollador PHP señalará, con toda la razón, que su código nunca llama a malloc. Los scripts PHP no gestionan la memoria a mano. No puedes escribir un desbordamiento de búfer en PHP como lo escribes en C.

No te hace falta. El intérprete que ejecuta tu script está escrito en C, y sus extensiones están escritas en C. Cada byte de entrada no fiable que recibe tu sitio, cada cabecera, cada subida, cada campo de formulario, cada cookie, lo analiza ese C antes de que lo vea tu código. Cuando ese C está mal, tu PHP cuidadoso da igual. PHP2Shell lo demostró: el aviso dice que el ataque puede dispararse «before any application code runs»¹.

El historial muestra en qué se ha equivocado ese C:

Esas son las clases a las que se refieren las agencias de seguridad cuando hablan de seguridad de memoria. En noviembre de 2022 la NSA aconsejó a las organizaciones «to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible»¹⁸. En diciembre de 2023 CISA, con el National Cyber Security Centre del Reino Unido entre los coautores, le puso un número: «two-thirds of reported vulnerabilities in memory unsafe programming languages still relate to memory issues»¹⁹.

Ninguno de los dos documentos nombra a PHP. No les hace falta. Nombran el lenguaje con el que está hecho PHP.

El peor ejemplo repetido es unserialize(), la función que convierte una cadena guardada otra vez en objetos PHP. Ha tenido la misma clase de fallo, en el mismo sitio, más de una vez:

El manual de PHP lo sabe. Su página para la función lleva el aviso: «Do not pass untrusted user input to unserialize() regardless of the options value of allowed_classes.»²³ Eso es un lenguaje diciéndote que una de sus propias funciones integradas no es segura de usar sobre lo que la mayoría del código web maneja todo el día.

Luego está PHP-FPM, el gestor de procesos que la propia guía de instalación de PHP recomienda frente a mod_php. En octubre de 2019, CVE-2019-11043 mostró que «in certain configurations of FPM setup it is possible to cause FPM module to write past allocated buffers … opening the possibility of remote code execution»²⁴. La configuración en cuestión era un montaje habitual de nginx. Se arregló el 24 de octubre de 2019²⁵. CISA lo añadió después a su catálogo de vulnerabilidades que se sabe que se explotan, marcado como usado en campañas de ransomware²⁶.

La PHP Foundation sí encargó una auditoría de seguridad seria del código fuente del intérprete, y hay que reconocérselo. Los resultados, publicados el 10 de abril de 2025, encontraron 27 problemas, 17 de ellos con implicaciones de seguridad²⁷. Eso es buena práctica y debería ser lo normal. También son 17 más, en una auditoría de un código que ya llevaba casi tres décadas de informes de fallos públicos.

El Lenguaje Cometió Los Mismos Errores Un Piso Más Arriba

El C es una capa. El lenguaje de encima cometió el mismo tipo de error en su diseño: fiarse de entradas de las que no tenía por qué fiarse, y tardar años en dejar de hacerlo.

register_globals merece su propia línea. Durante años, cualquier parámetro de la petición, ?admin=1 por ejemplo, se convertía en una variable de tu script, y si tu código comprobaba $admin antes de darle valor, el atacante ya se lo había dado por ti. El propio manual de PHP llamó a su desactivación «the most controversial change in PHP»²⁹. Diez años de desactivada por defecto a desaparecida. Ese es el tiempo que el proyecto toleró una característica que sabía peligrosa, porque quitarla rompería sitios.

El caso phar es el mismo patrón una capa más abajo. En 2018 Sam Thomas mostró en Black Hat que operaciones normales de ficheros sobre una ruta phar:// deserializaban metadatos aportados por el atacante, llevando el problema de unserialize() a funciones que nadie consideraba peligrosas³⁶. PHP 8.0, a finales de 2020, dejó de hacerlo automáticamente, «to fix potential security vulnerabilities due to object instantiation, autoloading, etc.»³⁴.

Luego, el type juggling. El == de PHP convierte tipos antes de comparar, así que las cadenas que parecen números se comparan como números. El RFC que arregló parte de esto en PHP 8.0 lo dijo claro: «This results in many surprising comparison results, the most notable of which is that 0 == “foobar” returns true.»³⁵

Ese arreglo fue real. También fue parcial. Aquí está la misma comprobación ejecutada en los contenedores oficiales php:7.4-cli y php:8.5-cli, el segundo con la 8.5.12, la versión parcheada contra PHP2Shell esta semana, con las dos salidas lado a lado:

$ php -r 'var_dump(0 == "foobar");'
bool(true)            # 7.4.33
bool(false)           # 8.5.12

$ php -r 'var_dump("0e462097431906509019562988736854" == "0e830400451993494058024219903391");'
bool(true)            # 7.4.33
bool(true)            # 8.5.12

Dos cadenas distintas, iguales. Las dos empiezan por 0e seguido de dígitos, así que PHP lee las dos como cero por diez elevado a algo, y cero es igual a cero. Las dos tienen la forma de un hash MD5. Compara un hash de contraseña guardado con == en vez de === o hash_equals(), y cualquier entrada cuyo hash empiece así coincide. Lleva años documentado. Sigue funcionando en la versión más nueva.

Ese es el lenguaje en un ejemplo. Un arreglo que entró, la mitad del problema que se quedó atrás, y la versión segura exigiendo que sepas que existe otro operador.

Una Shell, Casi Cada Año

La pregunta que vale la pena hacerle a cualquier plataforma no es cuántos fallos ha tenido. Es cada cuánto alguien podría quedarse con el servidor entero sin contraseña y sin que nadie haga clic en nada.

NVD puntúa cada CVE. Filtra los 757 por la puntuación que significa exactamente eso, ataque por red, sin privilegios, sin interacción del usuario, impacto alto en confidencialidad e integridad, y salen 172¹⁵.

172 repartidos en 23 de los 28 años que tienen algún CVE de PHP. Solo cinco están en blanco. Solo 2016 tiene 65.

Una puntuación de gravedad es una calificación, no una intrusión. Así que la segunda mitad del cuadro es el catálogo Known Exploited Vulnerabilities de CISA, que solo lista fallos con explotación confirmada en el mundo real²⁶. De sus 1 754 entradas a 21 de octubre de 2026, 81 son el propio PHP o aplicaciones escritas en PHP:

2026 ya es el peor año de PHP en el catálogo, y PHP2Shell todavía no está dentro. Tres de los de este año están en el propio núcleo de WordPress: dos añadidos el 21 de julio, y una inclusión remota de ficheros el 25 de septiembre.

Y el catálogo se queda muy corto con PHP. Está hecho en torno a los sistemas federales de EE. UU. y necesita un CVE más explotación confirmada. Tiene 3 entradas de plugins de WordPress. El ecosistema de plugins de WordPress registró 11 334 vulnerabilidades solo en 2025³⁷. El 81 es la parte que alguien oficial dejó por escrito.

WordPress Lo Multiplica

WordPress es el 39,6 % de todos los sitios web, y el 58,3 % de los sitios cuyo gestor de contenidos se puede identificar³⁸. PHP es el lenguaje de servidor del 69,3 % de los sitios donde eso se puede ver³⁹. Así que sea cual sea el historial de PHP, WordPress lo lleva a una parte muy grande de la web, y luego añade el suyo.

El núcleo no es el problema principal. Los plugins sí.

Wordfence, con su propia base de datos, contó 8 223 para 2024, un 68 % más que en 2023, y encontró que «Roughly 35% of the vulnerabilities disclosed in 2024 remain unpatched in 2025»⁴¹. Bases de datos distintas, totales distintos, misma forma.

Párate un momento en los números de 2025. Casi la mitad de las vulnerabilidades no tenían arreglo del desarrollador cuando se hicieron públicas. Y en las que los atacantes de verdad persiguen, la mediana entre la publicación y la explotación masiva es de cinco horas. Casi nadie revisa las actualizaciones de sus plugins cada cinco horas. Casi nadie puede.

El modelo de plugins es el multiplicador. La seguridad de un sitio depende del autor menos cuidadoso de cualquier cosa que tenga instalada, y Wordfence encontró que «over one third of developers are unreachable or unresponsive» cuando se les avisa de un fallo⁴¹. Patchstack contó 1 614 plugins y temas retirados del repositorio en 2024 por problemas de seguridad que nadie arregló⁴⁰. Y por el modelo de un solo proceso, cada plugin corre con todos los derechos del sitio.

Los incidentes son una lista larga. Estos son los que tienen fuentes primarias detrás:

He ido con cuidado con la fila de 2016. Wordfence mostró que el sitio del bufete corría una versión del slider trivialmente explotable. No mostró que así se llevaran los documentos, y no voy a afirmar más de lo que dicen las pruebas.

Cómo Se Queda El Malware

Entrar es la mitad. Quedarse dentro es la otra mitad, y PHP lo pone fácil por una razón que vuelve directa a la imagen del proceso único.

El intérprete ejecuta cualquier fichero .php al que llegue. El web root normalmente lo puede escribir el mismo usuario que ejecuta el código. Así que en cuanto un atacante tiene cualquier forma de escribir un fichero, un formulario de subida, un fallo de un plugin, un gestor de ficheros, puede escribir un script que se ejecuta cada vez que alguien lo pide. Eso es una web shell: un fichero pequeño, metido en tu sitio, recibiendo órdenes.

CISA lleva años diciendo en qué lenguajes están escritas sobre todo: «The most commonly observed web shells are written in languages that are widely supported, such as PHP and ASP.»⁵⁰ La guía conjunta de la NSA y la Australian Signals Directorate las llama «a long-standing, pervasive threat that continues to evade many security tools», y difíciles de detectar porque son «easily modified by attackers and often employ encryption, encoding, and obfuscation»⁵¹.

Los números de limpieza muestran lo a menudo que están ahí:

Así que en el año de limpieza más reciente, la mitad de los sitios hackeados seguía teniendo una vía de vuelta guardada en disco. Restaura la base de datos, parchea el plugin, y el atacante vuelve a entrar por el fichero que dejó.

No hay arreglo ingenioso para esto. Está el aburrido y como es debido, y la NSA lo dejó por escrito: «web applications should not have permission to write directly to a web accessible directory or modify web accessible code»⁵¹. Esa sola frase es el modelo de capas separadas del principio de este post, dicho por una agencia de inteligencia.

La guía de hardening de WordPress, para lo que vale, ni menciona impedir que PHP se ejecute en el directorio de subidas¹¹. Por eso la tabla cita a OWASP y a la NSA en su lugar.

Fíjate en lo que no está en esa tabla. Los ajustes de hardening del propio PHP. El manual es honesto sobre ellos. disable_functions «can be circumvented and should not be considered a sufficient security measure for shared hosting environments», y open_basedir «is just an extra safety net, that is in no way comprehensive, and can therefore not be relied upon when security is needed»⁵⁵. Cuando la documentación de un lenguaje te dice que sus mandos de seguridad no son límites de seguridad, créetela. Así que el límite tiene que venir de fuera del proceso.

Hasta En php.net Entraron

Si la infraestructura del propio proyecto fuera sólida, podrías argumentar que el historial se debe a un problema difícil bien gestionado. Han entrado en ella dos veces.

La de 2021 es la que importa. Alguien metió código en el árbol de fuentes del propio lenguaje, haciéndose pasar por la gente que lo mantiene. Se pilló. La respuesta del proyecto merece citarse porque es la correcta, dicha sin rodeos: «maintaining our own git infrastructure is an unnecessary security risk», y los repositorios se mudaron a GitHub⁵⁷.

Reconocimiento a quien se lo merece: fue una buena decisión, tomada rápido y explicada en abierto. Pero mira lo que admite. Durante años, el código fuente canónico de un lenguaje que mueve la mayor parte de la web vivió en una infraestructura propia que el mismo proyecto decidió que era un riesgo que no debía estar cargando.

Media Web Corre Una Versión Que Nadie Parchea

Todo lo anterior supone que el sitio está al día. Muchísimos no lo están.

php.net soporta ahora mismo cuatro ramas. La 8.2 recibe solo arreglos de seguridad, hasta el 31 de diciembre de 2026. La 8.3, la 8.4 y la 8.5 son el resto⁵⁸. Todo lo anterior está en fin de vida: la 8.1 desde el 31 de diciembre de 2025, la 8.0 desde noviembre de 2023, la 7.4 desde noviembre de 2022⁵⁹.

Ahora la parte medida de lo que de verdad está corriendo:

Solo PHP 7.4, sin soporte desde hace casi cuatro años, es cerca de una quinta parte de todos los sitios PHP que muestran su versión. La página de requisitos del propio WordPress pide PHP 8.3, y luego dice que WordPress «also works with PHP 7.4+», mientras señala que esas versiones «have reached their official End Of Life»⁶³. Un fabricante que sigue funcionando sobre una versión muerta es un fabricante que ha decidido no obligarte a moverte.

Dos matices honestos. W3Techs solo ve la versión en los sitios que la anuncian. Y algunas distribuciones Linux portan arreglos a versiones viejas de PHP, así que «sin soporte de php.net» no siempre es «sin parchear». Pero PHP2Shell es la prueba de eso. El proyecto sí publicó parches de código fuente para la 7.4, la 8.0 y la 8.1 esta vez¹, y aun así alguien tiene que compilarlos, distribuirlos e instalarlos. En un hosting compartido con una versión de la que nadie se hace cargo, ese alguien es nadie.

Yo Lo Dejé. Tú También Deberías Plantearte Irte.

Yo escribía PHP. Después de Pulsant abandoné el lenguaje, por los problemas que causaba y el trabajo que esos problemas daban. No por un mal incidente. Por años de las mismas dos causas, sitio tras sitio, y la limpieza cayéndole a quien estuviera de turno.

Así que lo voy a decir claro. Si la decisión es tuya, plantéate dejarlo. Hoy existen herramientas mejores para esto, y Go es la primera a la que te señalaría.

No porque esté de moda. Porque quita, por defecto, la mayor parte de lo que este post ha estado contando:

Que sea compilado importa dos veces. Es más rápido: los programas en Go «are compiled ahead of time to native machine code», sin máquina virtual debajo, y uno de sus objetivos de diseño declarados es «to approach the performance of C for comparable programs»⁶⁶. Y es más seguro, porque no hay un intérprete en el camino de la petición analizando código en tiempo de ejecución, ni un motor en C de 757 CVE entre la red y tu programa. PHP, si se le deja, hace lo contrario. Sin OPcache carga, analiza y compila cada script en cada petición, sin ninguna necesidad, miles de veces por minuto en un sitio con tráfico. OPcache existe para evitar eso, «removing the need for PHP to load and parse scripts on each request»⁶⁴. Pero no viene activado de serie. Hasta la 8.4 incluida es una extensión compartida aparte que alguien tiene que cargar con zend_extension y configurar. Solo PHP 8.5 la integra: «The Opcache extension is now always built into the PHP binary and is always loaded»⁷⁰. El propio RFC del proyecto para ese cambio dice que «running PHP in production without OPcache is generally considered a mistake»⁷¹. W3Techs pone la 8.5 en el 4,5 % de los sitios con PHP 8⁶⁰, así que para casi todo lo que corre hoy el arreglo para no compilar cada script en cada petición sigue siendo un añadido del que alguien tuvo que acordarse. E incluso cargado, lo que guarda en caché es bytecode para que lo ejecute el intérprete en C. Go compila una vez, antes de que el programa vea una sola petición.

Más rápido y más seguro, siempre que esté bien programado. Esa última cláusula es todo lo que viene en los próximos párrafos.

El paquete de plantillas de Go resume su diseño en una línea: genera «HTML output safe against code injection», y «The escaping is contextual, so actions can appear within JavaScript, CSS, and URI contexts.»⁶⁷ Su guía de bases de datos es igual de clara: «You can avoid an SQL injection risk by providing SQL parameter values as sql package function arguments.»⁶⁸ Eso son los valores por defecto. En PHP son cosas que tienes que saber ir a buscar.

La fila que yo subrayaría es la del fichero soltado. La mitad de los sitios hackeados que Sucuri limpió en 2023 seguía teniendo una backdoor en disco⁵³, y eso solo funciona porque el intérprete ejecuta cualquier script al que llegue. Un servicio compilado no va buscando scripts. Un fichero soltado no tiene dónde enchufarse.

Ahora la parte honesta, porque un lenguaje no es una cura. Go es más seguro en memoria, no perfectamente. Su propio modelo de memoria dice que una carrera de datos sobre un slice, un map o un valor de interfaz «can in turn lead to arbitrary memory corruption»⁷², y Go trae la herramienta para pillarla. Compila con -race, o ejecuta go test -race, y el binario se compila con un detector que informa de una carrera en el momento en que ocurre. Pilla carreras en tiempo de ejecución y no en tiempo de compilación, y «can’t find races in code paths that are not executed», así que tiene que estar en cada ejecución de tests y bajo una carga realista⁷³. PHP no tiene nada parecido. Mantener la memoria de una petición lejos de la siguiente se deja enteramente al motor, y PHP2Shell es ese motor haciéndolo mal: memoria liberada por una petición, leída por la siguiente en el mismo worker⁶. Fuera de eso, Go para la clase de corrupción de memoria que este post ha estado contando, y hace que la forma segura sea la fácil para otras dos. No para una comprobación de login rota, un control de permisos que falta o una consulta construida pegando cadenas si te empeñas en hacerlo. Go también publica sus propios avisos de seguridad, a través de su base de datos de vulnerabilidades⁶⁹. Y un servicio en Go corriendo como root desde un directorio escribible sigue estando mal desplegado.

Lo que cambia es el valor por defecto. Lo normal en PHP es un solo proceso que lo guarda todo. Lo normal en Go es un programa que hace un solo trabajo, que es la separación del principio de este post con la mayor parte del trabajo ya hecho. Si Go no le va a tu equipo, Rust es la otra salida. Los dos se compilan de antemano a código máquina nativo. Rust funciona «with no runtime or garbage collector»⁷⁴, y el compilador y el runtime de Go están «implemented in Go and assembler, without C» desde Go 1.5⁷⁵.

C# y Java también están en la lista de lenguajes seguros en memoria de las agencias¹⁸, pero no son una salida del problema con el que empezó este post. Los dos corren sobre una máquina virtual escrita en C++. HotSpot, de OpenJDK, son «around 3000 C/C++ header and source files, comprising more than 1.2 million lines of code»⁷⁶, y el recolector de basura y el compilador JIT de .NET son código fuente C++ en el árbol de CoreCLR⁷⁷. Es la misma forma que PHP: un gran motor nativo entre la red y tu código. Y Java carga código en una aplicación en marcha a propósito. Su cargador de clases estándar existe «to load classes and resources from a search path of URLs referring to both JAR files and directories»⁷⁸, y Log4Shell lo convirtió en ejecución remota de código: quien controlaba un mensaje de log «can execute arbitrary code loaded from LDAP servers»⁷⁹. El fallo entró directo en el catálogo de CISA²⁶. Es la misma puerta que la de PHP, con más ceremonia delante.

Así que elige Go o Rust. Mueve primero el back end, un endpoint cada vez, y deja el front end PHP sin nada que valga la pena robar hasta que también pueda irse.

Si Lo Sigues Desplegando Así, ¿Puedes Llamarte Profesional?

Hay suficientes pruebas arriba como para que esto haya dejado de ser una opinión. Así que aquí está la pregunta, hecha directamente. Si sigues desplegando PHP como un solo proceso que guarda el código, las credenciales y un web root escribible, ¿puedes llamarte profesional?

Depende de cuál de tres personas seas. Y saber cuál no es algo que te pasa. Asegurarte de saberlo es el trabajo.

Tienes una restricción real, y la has dejado por escrito. Un producto del que depende el negocio solo existe en PHP. Una migración está presupuestada y en el presupuesto del año que viene. Bien. Eso es profesional, siempre que el motivo esté en papel con una fecha al lado, el usuario de ejecución no pueda escribir el código, las subidas no puedan ejecutarse, la cuenta de la base de datos esté recortada, y hayas parcheado PHP2Shell esta semana. Estás corriendo un riesgo conocido a propósito, con los muros que le puedes poner alrededor.

Nunca te lo han dicho. Nadie te enseñó el historial, y el tutorial del que aprendiste lo metía todo en un directorio. Eso es una laguna, y todo el mundo tiene lagunas. Deja de ser una laguna en el momento en que has leído hasta aquí.

Lo sabes, y lo montas igual. Has visto los números, o suficientes. Sabes que la contraseña de la base de datos está en el web root y que el web root es escribible. Lo despliegas así porque es más rápido, porque el cliente no va a pagar por algo mejor, y porque nadie te ha hecho justificarlo. Ese es el caso al que apunta esta pregunta. El fallo no es la laguna en lo que sabes. Es construir por encima de una laguna que ya has visto y a la que nunca volviste para cerrarla.

Todo el mundo estuvo ahí alguna vez. Quedarse ahí por elección es la parte que no tiene defensa.

La Puerta Siempre Estuvo Abierta

Lo que me llama la atención al leer este historial no es que PHP tenga fallos. Todos los lenguajes los tienen. Es lo poco que de todo esto fue nunca una sorpresa.

El proyecto sabía que register_globals era peligroso en 2002 y lo quitó en 2012. Su manual te dice que no te fíes de unserialize(), que no te fíes de disable_functions, que no te fíes de open_basedir. Su propia documentación dice que un script bajo mod_php puede llegar a la base de datos sin contraseña. Las agencias llevan años diciendo que el lenguaje con el que está hecho es de donde salen dos tercios de los fallos de memoria. Cada aviso está ahí, por escrito, de la gente que debería saberlo.

Y siguió ganando de todos modos, porque era barato. Barato de alojar, barato de aprender, barato de venderle a un cliente que quería una web para el viernes. Un directorio, un proceso, una contraseña en un fichero, y un sitio que funcionaba. Lo que costaba en la tarifa era un plan de hosting compartido. Lo que costaba de verdad nunca salió en la factura: las limpiezas, las backdoors dejadas en disco, los números de tarjeta de los clientes robados por PHP malicioso, la ventana de cinco horas entre la publicación y el ataque.

Esa es la parte con la que no tengo paciencia. No los fallos. La decisión, tomada una y otra vez por gente que sabía más, de que la forma barata bastaba porque nadie estaba mirando. Un estándar es lo que mantienes cuando nadie está mirando. La separación entre front end y back end, el código de solo lectura, la cuenta de base de datos recortada: nada de eso es nuevo, nada de eso es caro, y todo ello habría convertido buena parte de los incidentes de arriba en nada sobre lo que valiera la pena escribir.

PHP2Shell no es el final de este historial. Es solo la entrada de esta semana. El lenguaje lo parcheará, los hostings acabarán desplegando la actualización, y la cuota de versiones subirá poco a poco como siempre, despacio. Lo que decide si el próximo te cuesta caro no es PHP. Es si construiste los muros que nunca te dio, o te fuiste a algo que ya viene con ellos.