OpenAI propone cinco etapas para coordinar la divulgación de fallos de PHP

OpenAI publicó el 21 de octubre de 2026 una propuesta de divulgación coordinada en cinco etapas, en el contexto de la respuesta a dos vulnerabilidades críticas de PHP. El esquema plantea cómo organizar futuras respuestas, desde la validación del fallo hasta las instrucciones públicas una vez que exista un parche. PHP publicó correcciones para ambos fallos el mismo día.

PHP es un lenguaje de programación de código abierto que se ejecuta en servidores para crear sitios web y aplicaciones. En este caso, los fallos afectan a instalaciones que atienden solicitudes web. La propuesta de OpenAI se centra en coordinar la reparación y la divulgación; el aviso de PHP detalla las vulnerabilidades y sus correcciones.

Cómo organiza OpenAI la divulgación

El marco propone una secuencia que empieza con el equipo que mantiene el software y termina con instrucciones para quienes deben instalar la corrección:

1. Validar el fallo y preparar una corrección. Mantenedores, investigadores y colaboradores técnicos confirmarían el impacto, desarrollarían y probarían el arreglo. La propuesta también contempla pruebas adversariales con modelos avanzados para buscar formas de eludir la corrección o fallos relacionados.
2. Dar tiempo a las organizaciones afectadas. Los mantenedores decidirían a quién avisar. Distribuidores podrían adaptar el parche a ramas anteriores; proveedores de alojamiento, probar medidas de protección; y equipos de seguridad, preparar detecciones o reglas de prevención.
3. Coordinarse con organismos públicos. Los gobiernos podrían ayudar a coordinar la respuesta y hacer llegar instrucciones a servicios esenciales e infraestructuras críticas. OpenAI dijo que, en la respuesta a los fallos de PHP, contactó con socios gubernamentales de Estados Unidos y de otros países.
4. Preparar actualizaciones para los productos afectados. Cuando los arreglos, las instrucciones y el calendario de divulgación estén más definidos, distribuidores, proveedores de servicios y operadores podrían preparar sus actualizaciones e identificar vacíos de cobertura.
5. Publicar instrucciones cuando exista un parche. La guía pública ayudaría a los operadores a identificar sistemas expuestos, localizar actualizaciones o medidas provisionales, comprobar que la corrección está instalada y pedir ayuda.

Cuándo plantea revisar el calendario

OpenAI propone limitar la información que recibe cada participante a la necesaria para su labor de protección y sopesar el riesgo de compartirla frente a la protección que puede facilitar. Así, quienes preparan una actualización no necesariamente necesitan conocer todos los detalles técnicos del fallo.

El marco contempla revisar los plazos si hay explotación activa, se filtra información, un parche público revela el fallo o los retrasos en la reparación aumentan el riesgo para los usuarios. OpenAI también solicita comentarios sobre la duración de los periodos de divulgación, los avisos escalonados y las salvaguardas necesarias para aplicar parches de emergencia. La búsqueda de vulnerabilidades a gran escala y el parcheo de sistemas por parte de gobiernos u operadores aparecen como cuestiones para debatir, incluidas la autorización y las protecciones necesarias.

Qué vulnerabilidades de PHP se corrigieron

PHP identificó dos fallos de ejecución remota de código, es decir, vulnerabilidades que pueden permitir ejecutar código en el servidor mediante una solicitud. A cada uno le asignó una puntuación de 9,2 en CVSS v4.0.

• CVE-2026-109618 está relacionada con la falta de memoria. PHP puede interrumpirse cuando algunos datos internos de una solicitud aún están a medio inicializar; durante la limpieza, el sistema puede tratar como válidos datos que no lo son.
• CVE-2026-109619 afecta a un estado interno asociado a una solicitud que puede persistir después de que se libere la memoria que lo respaldaba. Una solicitud posterior atendida por el mismo proceso puede reutilizar ese estado antes de que se reinicie.

PHP señala que pueden estar expuestas las instalaciones que procesan solicitudes web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El proyecto considera que el riesgo es mayor en mod_php.

Versiones corregidas y ramas anteriores

La cobertura anterior de NeoTeo sobre las versiones de PHP que corrigen los dos fallos se centró en los parches. Estas son las versiones publicadas por PHP para cada rama:

PHP 8.1 y las ramas anteriores ya no reciben actualizaciones del proyecto. PHP publicó retroportaciones mínimas del código fuente para PHP 7.4, 8.0 y 8.1; algunas distribuciones de Linux y proveedores con soporte de larga duración también ofrecen correcciones adaptadas a ramas antiguas. En esos casos, la versión del paquete puede depender del proveedor.

Qué cubren las medidas provisionales

PHP describe medidas distintas para cada ruta del fallo. Para CVE-2026-109618, enumera memory_limit=-1, límites para el tamaño de las solicitudes y el uso de contenedores o cgroups como barrera para limitar el impacto sobre la disponibilidad. Para CVE-2026-109619, indica desactivar session.upload_progress.enabled antes de analizar las solicitudes y reiniciar todos los procesos de trabajo. En PHP 8.5, fatal_error_backtraces=0 bloquea la ruta confirmada relacionada con las trazas de errores fatales.

PHP advierte que estas medidas reducen la exposición a rutas concretas, pero no dejan segura una instalación. La actualización a una versión corregida es la solución completa.