Las vulnerabilidades php2shell han revelado que la fundación que financia el desarrollo y el mantenimiento de PHP, el lenguaje de programación omnipresente en la web, tiene una sola persona a tiempo completo en plantilla, y su directora reclama más financiación. Pero el problema de fondo no se resuelve solo con dinero: lo que falta es gente capaz de revisar el código, y los datos muestran que el proyecto no está consiguiendo convertir a los recién llegados en esa gente.
El 21 de octubre, el proyecto PHP publicó parches de emergencia para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, bautizadas como php2shell, qu,e permiten la ejecución de código en el servidor sin autenticación. Según la alerta de CISA, afectan a cualquier instalación que sirva páginas web dinámicas utilizando este lenguaje, desde Apache con mod_php hasta PHP-FPM, FrankenPHP o LiteSpeed.
La publicación de los parches se adelantó un día tras varias filtraciones, entre ellas un mensaje en Hacker News y el vídeo de un exploit, según explicó Derick Rethans, miembro de la fundación, en una entrevista con Nuno Maduro. El 26 de octubre, CISA incluyó ambas vulnerabilidades en su catálogo de fallos que ya se están utilizando en ataques reales.
Hasta aquí, sería una crisis de seguridad más. Lo que la llevó a los medios de comunicación no especializados fue otra cosa: saber que hay un minúsculo grupo de personas detrás de un lenguaje que mueve cerca del 70 % de los sitios web con lenguaje de servidor identificable.
Una persona en plantilla
«Tenemos un único miembro del personal a tiempo completo (yo) y 14 contratistas, la mayoría a tiempo parcial». Así lo describió Elizabeth Barron, directora ejecutiva de la PHP Foundation, en una entrevista por correo con Reuters. Los miembros de la junta, añadió, son voluntarios sin sueldo y el dinero procede de donaciones y subvenciones.
Su conclusión: dada la dependencia de empresas y gobiernos, «está claro que PHP está increíblemente infrafinanciado».
El titular apareció en periódicos de todo el mundo, pero no explica toda la historia. Esos 14 contratistas son ingenieros que trabajan en el núcleo del lenguaje, y fueron ellos quienes respondieron a la crisis. La propia fundación ha recordado que sin su financiación habría sido imposible tener a varias personas dedicadas al problema a tiempo completo, fines de semana incluidos. Hace cinco años, ni siquiera eso existía.
2021: dos personas
A finales de 2021, según Techzine, el futuro del código fuente de PHP estaba en manos de dos desarrolladores: Dmitry Stogov y Nikita Popov. Cuando Popov anunció que dejaba de dedicarse a PHP, diez empresas se unieron para crear la PHP Foundation.
JetBrains, que impulsó la iniciativa, publicó en su anuncio, un apartado se titulaba directamente «The bus factor»: la expresión que se usa en informática para preguntar cuántas personas tendrían que desaparecer para que un proyecto se detenga. En PHP, la respuesta era dos.
El rescate funcionó. La fundación pasó de 6 desarrolladores financiados en 2023 a 11 a comienzos de 2026, y hoy, según Barron, a 14 (la web de la fundación habla de 13). Ha recibido dinero público del Sovereign Tech Fund, dependiente del Gobierno alemán. Sin ese rescate, la respuesta a php2shell habría sido muy distinta.
Pero sus cuentas son públicas, y no evidencian estabilidad. Según su informe de transparencia de 2025, la fundación firmó aproximadamente el 42 % de todos los commits al núcleo de PHP ese año. Es decir, casi la mitad del trabajo de desarrollo y mantenimiento depende de una docena de contratistas de la Fundación. Al mismo tiempo, los patrocinadores bajaron a 536, sustancialmente menos que el año anterior, y la fundación gastó más de lo que ingresó: unos 784.000 dólares frente a 645.000 recibidos tras comisiones, según el análisis de Xenospectrum.
La financiación, además, está muy concentrada. Según la página de la fundación en Open Collective, de los algo más de tres millones de dólares recaudados desde 2021, más de la mitad procede de cuatro contribuyentes: Automattic (wordpress), JetBrains (PHPStorm), el fondo público alemán y la Linux Foundation. Esta concentración es una debilidad: si uno de ellos cambia de prioridades, el proyecto peligra. Por eso el diagnóstico de «falta dinero» se queda corto. El dinero llegó, aunque sigue faltando. El dinero no es la única carencia.
El dinero compra horas, no experiencia
En su entrevista Barron dijo algo más que no despertó tanta atención. El proyecto recibe casi el doble de propuestas de cambio que hace un año (propuestas para dotar al lenguaje de otras funciones o capacidades, o soluciones a problemas), «pero el número de colaboradores no se ha duplicado». Y revisar esas propuestas exige, en sus palabras, «una cantidad enorme de intervención y experiencia humana».
Ese es el cuello de botella. Aunque millones de personas programan en PHP, muy pocas entienden el intérprete que lo ejecuta: el Zend Engine, escrito en C, con su gestión de memoria y sus convenciones internas. Ese conocimiento no se encuentra inmediatamente disponible en el mercado laboral. O el proyecto lo forma durante años, o no existe.
El caso de php2shell lo demuestra. Una auditoría de 2024, financiada por el Gobierno alemán, ya apuntaba al posible problema, aunque nadie creyó entonces que fuera explotable. El equipo lo estudió, pero corregirlo exigía tocar el gestor de memoria sin romper las extensiones, y con un equipo de seguridad pequeño había otras prioridades. Hizo falta que en agosto de 2026 tres organizaciones demostraran, con ayuda de IA, que el fallo se podía explotar. Rethans lo resume así: la fundación, con tan poca gente, no puede priorizarlo todo a la vez. Y este es el otro problema del proyecto. Si durante mucho tiempo no ha incorporado gente nueva al núcleo de desarrolladores (internals), ahora no hay a quién contratar aunque llegue el dinero. La fundación puede pagar más horas a los mismos expertos, pero no puede comprar expertos que nadie formó.
La falta de relevo no es solo una percepción externa. En marzo, durante el debate de una propuesta para abrir la evolución del lenguaje a la comunidad, un colaborador escribió en la lista interna que Internals lleva justo la trayectoria contraria a la necesaria, y que eso debe cambiar para que PHP y la fundación tengan éxito.
Qué les pasa a los que llegan
Dos días después de la entrevista de Reuters, un colaborador, Artem Ukrainskiy, publicó en la lista de desarrolladores un análisis independiente sobre lo que ocurre con las propuestas de quienes contribuyen por primera vez a php-src, el repositorio del núcleo. Revisó un año completo, de octubre de 2025 a octubre de 2026: 831 propuestas de 219 personas, en torno a una cuarta parte del total.
La primera lectura parece desmentir la imagen de un club cerrado. Se aceptaron 418 propuestas, la mitad. Además llegaron cada vez mas contribuyentes nuevos: de 1 a 5 debutantes por semana al principio, a entre 5 y 12 en otoño.
Un análisis de los números muestra un panorama menos acogedor: un solo autor abrió 232 propuestas con un 84 % de aceptación. Sin él, la tasa global de aceptación cae del 50% al 37%. Los 209 autores fuera de los diez más activos se quedan en un 27%. Además 125 propuestas están inactivas: se cerraron tras no recibir respuesta o llevan más de 50 días paradas. Entre las propuestas cerradas con motivo conocido, la causa más frecuente es que el cambio no se quiere (38), por delante de las que retiró su autor (34) y los duplicados (31).
Hay un dato más que conecta con el aluvión del que hablaba Barron: las propuestas con descripciones redactadas por IA, un 14 % del total, se aceptan en torno al 20 % de las veces, frente al 55 % del resto: más volumen no significa más trabajo útil, pero sí consume tiempo de revisión.
La primera respuesta en la lista al hilo de Artem Ukrainskiy resumía la experiencia de su autor: lo que más fricción le causó como colaborador nuevo fue crear una propuesta y que nadie respondiera.
¿Intransigencia o prudencia?
La reticencia a aceptar nuevas propuestas es comprensible. Muchas partes del núcleo tienen un mantenedor responsable, y quien acepta un cambio en su área se compromete a mantenerlo durante años. Decir «no» es a menudo la defensa razonable de un equipo pequeño. Que la primera causa de rechazo sea «el cambio no se quiere», puede leerse como cerrazón o como prudencia, y probablemente es ambas cosas.
El problema aparece en la asimetría. El mismo colaborador que se quejaba del silencio señalaba otro obstáculo: una sola objeción poco fundamentada puede costarle a un autor meses de trámites en forma de RFC, el procedimiento formal para proponer cambios en el lenguaje. Para un veterano, es un filtro. Para un recién llegado sin tiempo pagado, es motivo para no volver. Y así se cierra el círculo. Los revisores que la fundación necesitará mañana son los desarrolladores que hoy pretenden iniciar una colaboración. Cada propuesta que queda sin contestar es un candidato que se pierde.
El diagnóstico de esta semana, «falta dinero», es incompleto. El dinero hace falta, y las empresas que facturan gracias a PHP deberían aportar mucho más. Pero si solo sirve para pagar más horas a los mismos expertos, el lenguaje seguirá dependiendo de un grupo pequeño y difícil de sustituir, como en 2021. La inversión que más falta no es la más visible: dedicar tiempo pagado a involucrar a los recién llegados. Es la única forma de que la próxima crisis encuentre más manos que esta.
