ARC Prize rechazó el 99,9% de GPT-6 Astra y lo midió en 62,7% con su arnés estándar — mientras PHP2Shell suma millones de intentos de explotación y 884.000 servidores sin parche disponible

Dos noticias de hoy muestran la misma lección en dominios distintos: los números sin contexto de cómo se midieron no son resultados. En benchmarks de IA, OpenAI publicó 99,9% bajo condiciones que no comparte con nadie. En seguridad, PHP2Shell escaló de "sin exploits confirmados" a millones de intentos en cuestión de días. En ambos casos el número de titulares fue real y el contexto cambió todo lo que significaba.

ARC Prize: GPT-6 Astra marcó 62,7%, no 99,9%

El 3 de septiembre, OpenAI lanzó GPT-6 Astra con una puntuación de 99,9% en ARC-AGI-3. Tres días después, Jensen Huang lo citó en X para declarar que la AGI había llegado.

El 25 de octubre, ARC Prize publicó los resultados de su propia ejecución del mismo modelo con su arnés estándar, el mismo que usan todos los demás laboratorios: 62,7%. La fundación calificó el 99,9% de OpenAI como "no válido".

La diferencia no está en el modelo — está en el arnés. La cifra de OpenAI salió de su configuración propia con herramientas habilitadas, que cuesta casi US$19.000 correr y bajo la cual ningún otro laboratorio es evaluado. En el arnés neutro, dos variantes de menor cómputo de Astra marcaron 59,3% y 54,8%, respectivamente. GPT-6 Astra sigue siendo el resultado más alto en el benchmark — pero 62,7% es un tipo de número completamente diferente a 99,9%.

Hay dos detalles adicionales que lo convierten en un patrón en lugar de un error aislado: OpenAI reportadamente revisó varias cifras de benchmarks publicadas después de su post de lanzamiento, y una investigación independiente de esta misma semana encontró que la elección del arnés en agentes de código puede aumentar fuertemente el costo sin ganar precisión. Un número de benchmark sin su arnés no es un resultado.

ARC Prize también declaró que el progreso de Astra no califica como AGI.

PHP2Shell: de "sin exploits" a millones de intentos en días

El 21 de octubre, cuando PHP publicó los parches de emergencia para CVE-2026-109618 y CVE-2026-109619, Huntress reportó que en sus entornos asociados no había explotación confirmada, sin código de prueba de concepto público y sin exploits disponibles. El mismo día CISA emitió una alerta urgiendo a parchear de inmediato.

Al 25 de octubre, la situación es radicalmente diferente:

• El botnet Mirai se sumó a los ataques activos
• Aparecieron exploits con bypass de ASLR
• Los intentos de explotación se cuentan en millones
• Australia cerró cyber.gov.au; cientos de sitios gubernamentales en Europa también fueron tomados fuera de línea
• Los fallos tienen varios años de antigüedad en el motor PHP

El estado de los parches es el problema central. PHP publicó una versión fuera de ciclo el 21 de octubre que cubre solo las ramas 8.2 a 8.5. PHP 8.1 y anteriores no reciben parche y no existe ningún workaround publicado. Estimaciones basadas en escaneos de internet calculan unos 884.000 hosts con acceso a internet cuyos banners reportan PHP 8.1 o anterior — un conteo de banners, no de hosts confirmados vulnerables, pero representa la población sin solución disponible a ningún precio.

El problema se profundiza en cinco semanas: PHP 8.2 llega al fin de vida el 30 de noviembre, lo que moverá otro cohort de instalaciones a la categoría sin soporte.

Hay también una historia sobre la divulgación: los identificadores CVE y una puntuación CVSS reclamada de 10,0 llegaron de una publicación filtrada antes del aviso oficial de PHP, que nunca llegó a nombrarlos. PHP todavía no ha descrito públicamente cómo funcionan los fallos.

Si tenés PHP 8.1 o anterior en producción, la única opción disponible es migrar a PHP 8.2+ e instalar los parches del 21 de octubre. No hay workaround para versiones sin soporte.