La Fundación PHP tiene una empleada a tiempo completo y 14 contratistas. Cuida el lenguaje que corre en cerca del 70% de los sitios web. La crisis PHP2Shell lo puso en evidencia.
La organización admitió que el retraso del parche fue un fallo estructural. Ahora pide financiamiento estable a empresas, proveedores de hosting y gobiernos.
Qué fue PHP2Shell y por qué paralizó la web
El 21 de octubre, el proyecto PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Los parches cierran dos vulnerabilidades críticas de ejecución remota de código: CVE-2026-109618 y CVE-2026-109619.
En Apache con mod_php, un atacante sin cuenta podía ejecutar código antes de que corriera la aplicación. CISA pidió parchear de inmediato o desconectar los equipos sin actualización.
PHP mueve WordPress, Drupal, MediaWiki y servicios de gobierno. Cloudflare reportó millones de intentos de explotación. Barron dijo a Reuters que no hay evidencia de ataques exitosos contra sistemas ya actualizados ni de explotación antes de la divulgación.
Una fundación con una sola empleada fija
Barron es la única empleada a tiempo completo de la fundación. Trabaja con 14 contratistas, en su mayoría a tiempo parcial, y un consejo que no cobra. El dinero sale de donaciones y subvenciones.
La cuenta no cuadra con la dependencia. Reuters señala que PHP puede sostener hasta el 70% de los sitios del mundo. “Dada esa dependencia, está claro que PHP está increíblemente infrafinanciado”, dijo Barron.
La Fundación PHP se creó en 2021 con el impulso de JetBrains, Automattic, Laravel y otras empresas. Hoy reclama aportes de quienes construyen sobre el lenguaje.
La IA encontró el fallo y multiplicó el trabajo
El problema de memoria detrás de CVE-2026-109618 apareció en una auditoría externa de 2024. La coordinó OSTIF, la ejecutó Quarkslab y la financió la agencia alemana Sovereign Tech Agency. No había una ruta clara de explotación.
El arreglo se estancó entre incompatibilidades, riesgos de denegación de servicio y falta de especialistas.
El 11 de agosto de 2026, un investigador de Calif reportó una ejecución remota de código con la misma causa. OpenAI y Wiz encontraron vectores adicionales. Desde julio, el equipo publicó 15 CVE y revisó más de 100 reportes inválidos, duplicados o imposibles de reproducir. La IA también duplicó las propuestas de cambio de código, pero no la cantidad de colaboradores.
Un tercer fallo sin parche de emergencia
El 23 de octubre, PHP avisó de una tercera vulnerabilidad, CVE-2026-115560. Necesita una combinación poco común de configuración y código, y no tendrá parche de emergencia: la corrección llegará en la próxima versión regular. La mitigación es poner session.upload_progress.enabled=0.
La Fundación insiste en que las herramientas automáticas encuentran errores más rápido, pero no deciden cómo corregirlos. Esa decisión depende de ingenieros que conozcan todo el motor de PHP, y hoy hay pocos.
Qué revisar si tu sitio usa PHP
Si administras WordPress, Drupal o hosting, revisa la versión de PHP. Las ramas 8.1 y anteriores ya no reciben actualizaciones. Actualiza a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, reinicia los workers y busca plugins, paneles o contenedores que arrastren versiones viejas.
El parche tapa el agujero de esta semana. La pregunta que deja PHP2Shell es quién paga para que la próxima revisión no tarde otros dos años.
Más en: Ciberseguridad, Programación
