Por Canuto  

La Fundación PHP reconoció que una falla detectada en 2024 quedó meses sin solución por desacuerdos técnicos y falta de recursos. Tras filtraciones que precipitaron la divulgación de dos vulnerabilidades críticas, la organización anunció cambios en sus decisiones de seguridad y pidió más apoyo para proteger una tecnología ampliamente utilizada en la web.

***

  • Uno de los dos errores críticos agrupados bajo el nombre PHP2Shell se detectó en 2024, pero las opciones de reparación implicaban costos para la compatibilidad y el ecosistema.
  • La circulación anticipada de identificadores CVE, un video de demostración y un parche publicado antes de tiempo alteraron la divulgación coordinada.
  • La Fundación creó un equipo de seguridad, contrató a dos ingenieros y reemplazó el consenso por votaciones mayoritarias para resolver decisiones técnicas.

 

 

La Fundación PHP atribuyó la demora a fallas de proceso y falta de personal. Dos vulnerabilidades críticas en componentes centrales del lenguaje llevaron a adelantar la divulgación y preparar una actualización de seguridad.

La Fundación PHP reconoció que su equipo de seguridad conocía desde 2024 uno de los dos errores críticos que quedaron bajo el nombre PHP2Shell, pero pasó meses sin acordar una reparación. La falla estaba en la gestión de memoria, una parte fundamental de PHP, y el debate sobre sus posibles soluciones se estancó por los riesgos que cada alternativa planteaba para el ecosistema.

La organización publicó su explicación el miércoles, después de anunciar una actualización de seguridad para el 21 de octubre. La Agencia de la Unión Europea para la Ciberseguridad (CERT-EU) informó que la Fundación había anunciado el 20 de octubre una próxima publicación para abordar dos vulnerabilidades críticas. Huntress identificó los CVE-2026-109618 y CVE-2026-109619 y describió los fallos como vulnerabilidades de ejecución remota de código. Huntress y CERT-EU dieron cuenta de la divulgación y del lanzamiento previsto.

Según informó The Next Web, los errores afectan la gestión de memoria y el manejo de errores, áreas por las que pasan numerosas solicitudes procesadas por PHP. Esa ubicación central elevó su gravedad y complicó las correcciones, porque un cambio podía repercutir en aplicaciones y extensiones.

Una reparación detenida por sus costos

Un desarrollador principal encontró el problema de memoria mientras el equipo corregía otra falla detectada durante la primera auditoría de seguridad externa de PHP. En ese momento, alguien planteó que podía existir una vía de explotación, pero el equipo no identificó un método concreto para entrar y dio prioridad a problemas más claros. La incertidumbre sobre el riesgo no eliminó el defecto, aunque sí contribuyó a que la reparación quedara relegada.

Cuando el equipo de seguridad retomó el asunto, evaluó varias soluciones que implicaban costos distintos. Una alternativa rompía la compatibilidad hacia atrás, otra podía abrir un riesgo de denegación de servicio y una tercera obligaba a modificar miles de extensiones desarrolladas por terceros. La Fundación explicó que no había una opción sin consecuencias y que cada decisión podía afectar a usuarios y desarrolladores de manera diferente.

El grupo era pequeño y trabajaba mediante consenso, un modelo que exigía alcanzar acuerdo antes de adoptar una corrección. La preocupación por escoger una alternativa equivocada hizo que el análisis se estancara y comenzara de nuevo durante meses, en vez de producir una decisión definitiva. La Fundación calificó el resultado como una falla estructural, vinculada tanto al proceso de toma de decisiones como a la falta de recursos del equipo de seguridad.

La organización no presentó el retraso como un simple desacuerdo técnico, sino como un problema interno que dificultó responder a un riesgo conocido. Esa admisión también puso de relieve una tensión habitual en el mantenimiento de software ampliamente desplegado: reparar una vulnerabilidad puede reducir un peligro inmediato, pero una modificación con efectos secundarios puede romper sistemas que dependen de comportamientos existentes. En PHP, el alcance de las dependencias volvió más difícil cerrar el debate.

Filtraciones alteraron el calendario

La secuencia cambió el 20 de octubre, cerca de las 15:00 UTC, cuando dos identificadores CVE comenzaron a circular en foros y redes sociales. Los datos incluían una hora de publicación incorrecta y una puntuación de gravedad de 10,0, aunque la calificación real era 9,2. En ese momento no se habían divulgado detalles técnicos, pero la Fundación decidió adelantar su anuncio y mover el lanzamiento del 22 al 21 de octubre. SecureLayer7 también informó de un parche de emergencia previsto para el 21 de octubre a las 14:00 UTC y citó una puntuación CVSS de 9,2.

La Fundación dijo que no publicó la solución de inmediato porque los distribuidores todavía preparaban los paquetes y una salida precipitada habría dejado a muchos usuarios sin una vía sencilla para actualizar. El objetivo era coordinar la disponibilidad de las correcciones para facilitar la protección de los sistemas afectados. Sin embargo, los incidentes posteriores debilitaron ese calendario y expusieron información que la organización pretendía divulgar de manera controlada.

Alrededor de las 20:00 UTC, Calif, una de las firmas que reportó las vulnerabilidades, publicó por accidente un video en el que su prueba de concepto funcionaba contra objetivos reales. La firma lo retiró, pero las copias se propagaron; según la Fundación, ese material aceleró la aparición de código público de explotación al día siguiente. El equipo de seguridad añadió que vigiló de cerca ese código y que, al momento del lanzamiento, no había observado un exploit funcional.

La organización también señaló que Chainguard publicó imágenes con la corrección más de seis horas antes del lanzamiento previsto. La empresa había recibido el parche por adelantado, como otros distribuidores, para que sus usuarios pudieran actualizarse en cuanto se anunciara la solución. Pero hacer pública la imagen antes de tiempo permitió que un atacante estudiara el parche en formato binario mientras otros usuarios aún esperaban, lo que la Fundación consideró una ruptura del embargo y del trabajo de coordinación.

Más recursos y un nuevo método de decisión

La publicación de la Fundación también reclamó apoyo financiero de empresas, proveedores de alojamiento y gobiernos que utilizan PHP. La organización afirmó que el lenguaje sostiene una parte considerable de la web, incluidos servicios gubernamentales, tiendas en línea y bancos, mientras la labor de seguridad depende de un grupo reducido de desarrolladores financiados por la propia entidad y de cierta ayuda voluntaria. Para la Fundación, esa diferencia entre el alcance del software y los recursos disponibles dificulta sostener el trabajo.

El volumen de reportes refuerza esa preocupación: desde principios de julio, el equipo publicó 15 CVE y revisó más de 100 reportes que resultaron inválidos o duplicados. La Fundación dijo que las herramientas de inteligencia artificial pueden acelerar el hallazgo de fallas tanto para atacantes como para defensores, pero no reemplazan el criterio de ingenieros experimentados. En particular, no resuelven por sí solas cómo corregir decisiones de diseño antiguas ni cómo ponderar los costos de compatibilidad.

La entidad ya había empezado a reorganizar su respuesta antes de la divulgación de PHP2Shell. En mayo creó un Equipo de Seguridad del Ecosistema y durante el verano contrató a dos ingenieros más; además, está reemplazando el consenso por votaciones mayoritarias en las decisiones de seguridad. El cambio busca evitar que una reparación controvertida quede detenida durante meses, aunque la Fundación no presentó el nuevo mecanismo como una garantía de que desaparecerán los desacuerdos técnicos.

El equipo también recurrió a herramientas de IA para examinar el código: a comienzos de año escaneó PHP con Claude Mythos, de Anthropic, y después añadió Daybreak, de OpenAI, para validar reportes. La auditoría de Calif comenzó el 30 de julio en el programa Patch the Planet de OpenAI, y el investigador Ryan A informó la falla el 11 de agosto. La Fundación indicó que OpenAI comunicó ese mismo día, de manera independiente, la misma causa raíz.

La coincidencia entre ambos reportes muestra la rapidez con la que distintas iniciativas pueden encontrar el mismo defecto, pero también el trabajo que queda después de detectarlo: verificarlo, decidir cómo repararlo y coordinar la publicación. La Fundación dijo que ahora confía en que los problemas atrapados entre compromisos técnicos llegarán antes a sus responsables, en lugar de quedar detenidos durante meses. Su llamado a financiar la seguridad apunta a que esa capacidad de respuesta requiere tanto procesos distintos como más especialistas.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados