PHP vio en 2024 la primera señal de PHP2Shell y su arreglo se trabó por meses

La primera señal del error que terminó en PHP2ShellNombre con que se conoce a un conjunto de fallas críticas del lenguaje de programación PHP, muy usado en sitios web, que los atacantes explotan contra servidores expuestos a internet. apareció en 2024, y su arreglo "se estancó y volvió a empezar una y otra vez durante meses", según el análisis que publicó la PHP Foundation el 21 de octubre, el mismo día del parche. La fundación, que contrata a desarrolladores del núcleo de PHP, lo llamó "una falla estructural, causada tanto por el proceso de decisión del equipo de seguridad como por su falta de recursos".

Ese texto volvió a circular el 4 de noviembre, cuando Tom's Hardware lo presentó como la prueba de que un grupo chico de mantenedores conocía el error desde hacía dos años, y DiarioBitcoin lo replicó en español. Las dos fallas, CVE-2026-109618 y CVE-2026-109619, permiten tomar el control de un servidor sin contraseña y ya se explotan, como contó LatamByte al informar los ataques contra firewalls de Palo Alto.

Una auditoría pagada por Alemania dio la primera pista

En 2024, PHP pasó por su primera auditoría de seguridad externa en años. La pagó la Agencia de Tecnología Soberana de Alemania (Sovereign Tech Agency), la organizó la fundación OSTIF y la hizo la empresa francesa Quarkslab, según el informe de resultados de la PHP Foundation. Mientras corregía uno de esos hallazgos, un desarrollador contratado por la fundación vio los primeros síntomas del problema detrás de CVE-2026-109618. Cuando una petición agota la memoria permitida, PHP puede dejar datos a medio armar y después tratarlos como válidos.

Ese año se imaginó un ataque posible, pero nadie encontró una forma concreta de llevarlo a cabo, y otros problemas con impacto claro pasaron adelante. El equipo de seguridad preparó varias soluciones y cada una tenía su costo. Una rompía la compatibilidad, otra abría la puerta a ataques de denegación de servicioAtaque o falla que deja un equipo, un servicio o una red sin poder responder a sus usuarios legítimos, por ejemplo porque se bloquea o se reinicia. Se conoce por la sigla en inglés DoS. y la tercera obligaba a cambiar muchas extensiones de terceros, una coordinación que parecía imposible. El equipo decidía por consenso y, según la fundación, "temía las repercusiones de elegir mal".

El giro llegó en agosto de 2026. Ryan A, investigador de la empresa de seguridad Calif, que auditaba PHP dentro del programa Patch the Planet de OpenAI, informó el 11 de agosto un ataque de ejecución remota de códigoVulnerabilidad o ataque, conocido por la sigla en inglés RCE, que permite a alguien ejecutar sus propias instrucciones en un equipo o servidor ajeno a distancia, por lo general a través de internet. con la misma causa. OpenAI reportó por su cuenta la misma raíz, Wiz sumó otras vías el 24 de agosto y OpenAI agregó más el 18 de septiembre. Desde el 11 de agosto, dice la fundación, corregirlo fue la prioridad de todo su equipo de seguridad, que trabajó "los fines de semana y a toda hora" hasta el parche.

Dos años, según quién lo cuente

La cifra de dos años sale de contar desde 2024, pero la fundación no dice que entonces supiera que el error se podía atacar. Describe una señal sin camino de ataque conocido, cuyo alcance completo recién quedó claro con los reportes de agosto. Larry Garfield, desarrollador y referente de la comunidad PHP, sostuvo en su blog que el problema "no era crítico" porque nadie lograba explotarlo, y que las filtraciones y los cambios de fecha vinieron de terceros, no del equipo de seguridad.

Que un grupo chico lo supiera antes de hacerlo público es, además, lo habitual. La divulgación coordinada consiste en guardar reserva hasta tener el parche listo, y en este caso se rompió antes de tiempo por una filtración del 20 de octubre y por la empresa Chainguard, que según la fundación publicó imágenes con el arreglo más de seis horas antes de lo acordado.

Tampoco coincide el tamaño del equipo. Tom's Hardware habla de un empleado de tiempo completo y 14 contratistas de medio tiempo, un dato que el mismo medio había dado el 26 de octubre como versión no confirmada. El análisis de la fundación no da números, y su página institucional dice que contrata 13 ingenieros de tiempo completo y parcial, aunque enumera 14 nombres. Tom's Hardware también atribuye el hallazgo a un modelo de OpenAI en la semana del 19 de octubre, cuando la cronología oficial ubica los primeros reportes en agosto.

Votar en lugar de esperar consenso

La fundación dice que el equipo de seguridad empezó a cambiar su forma de trabajo para que las decisiones se tomen por mayoría y se busquen acuerdos intermedios, y que un caso trabado como este llegaría ahora mucho antes a la dirección. En mayo creó un Equipo de Seguridad del Ecosistema, en julio sumó a Alexandre Daubois para clasificar y corregir reportes y en septiembre a Daniel Scherzer para reforzar el código.

También usa inteligencia artificial para validar reportes, entre ellas Claude MythosFamilia de modelos de inteligencia artificial de Anthropic presentada en abril de 2026. Por su capacidad para encontrar y explotar vulnerabilidades no se liberó al público, y su acceso se reserva a organizaciones verificadas., de Anthropic, y Daybreak Red, de OpenAI, aunque "una persona toma cada decisión", aclara. La carga creció. Desde el 1 de julio, el equipo publicó 15 identificadores CVEIdentificador único que recibe cada vulnerabilidad conocida públicamente, con la forma CVE-año-número, para que fabricantes, investigadores y defensores hablen de la misma falla. y descartó más de 100 reportes inválidos, repetidos o imposibles de reproducir.

Ninguna empresa de la región entre los aportantes

El análisis cierra con un pedido de dinero a las empresas, los proveedores de alojamiento y los gobiernos que dependen de PHP. En la página de la fundación en Open Collective, una de las vías por las que recibe aportes, figuran unas 224 organizaciones que donaron alguna vez, de Japón, Europa, Estados Unidos, China y Rusia, entre otros lugares. Al 5 de noviembre, LatamByte no encontró entre ellas ninguna empresa latinoamericana identificable. El mayor aportante es JetBrains, con más de medio millón de dólares, y quienes donan por GitHub Sponsors aparecen agrupados como un solo donante.

La región, en cambio, está entre las más expuestas. Según el conteo de Mallory que publicó LatamByte, el 88 % de los servidores de Argentina que muestran su versión corre PHP 8.1 o anterior, y en México y Brasil la proporción supera el 60 %. Esas ramas ya no reciben versiones del proyecto, así que dependen de arreglos de terceros o de una migración.

La fundación prometió convertir lo aprendido en "procesos duraderos y repetibles", sin fechas. La próxima prueba es CVE-2026-115560, la tercera vía de ataque, que PHP decidió corregir en la próxima versión regular y sin parche de emergencia.