- En el benchmark de detección de vulnerabilidades IDOR de Semgrep, GLM 5.2 de Zhipu AI, un modelo de open weights, logró un F1 más alto que Claude Code usando solo condiciones de prompt simples
- El experimento mantuvo fijos el dataset, el método de evaluación y el prompt del sistema, y cambió solo el modelo y el harness para comparar si el rendimiento venía del modelo en sí o del scaffolding que lo rodea
- Semgrep Multimodal, con un harness dedicado, ocupó el 1.º y 2.º lugar con GPT 5.5 61% y Opus 4.8 53%, mostrando con claridad el impacto de la exploración estructurada
- Incluso sin scaffolding para explorar endpoints, GLM 5.2 logró 39% de F1, con un costo aproximado de $0.17 por cada vulnerabilidad encontrada
- El resultado no implica que todos los modelos de open weights hayan dado vuelta el panorama, sino que un modelo fue fuerte en una tarea y un dataset concretos; en otros tipos de vulnerabilidades el resultado podría cambiar
Un experimento que separó el rendimiento del modelo del efecto del harness
- Semgrep ejecutó modelos open-source populares sobre su benchmark de IDOR, usando el mismo dataset y los mismos prompts que ya había utilizado en evaluaciones previas de agentes de coding frontier
- La comparación central buscaba aislar si el desempeño en detección de vulnerabilidades venía del modelo mismo o del harness que lo rodea
- El harness es el scaffolding que entrega el repositorio al modelo, decide qué mirar, parsea la salida y organiza el loop de trabajo
- El pipeline multimodal interno de Semgrep corre sobre un harness dedicado y ajustado al análisis estático
- enumera los endpoints de la aplicación
- selecciona el contexto de código importante
- guía directamente al modelo hacia esos endpoints
- En esta prueba con modelos de open weights, el experimento se hizo sin ese scaffolding especializado y usando un harness simple basado en Pydantic AI
- se mantuvo igual el prompt de IDOR
- no se ofreció descubrimiento de endpoints ni exploración guiada
- sí se dieron algunas pistas sobre estrategias de búsqueda de IDOR y sobre las formas típicas de IDOR
Por qué GLM 5.2 llamó la atención en tareas de seguridad
- GLM 5.2 es el modelo más reciente de Zhipu AI, también conocida como Z.ai
- fue distribuido a miembros del plan GLM Coding el 13 de junio de 2026
- los open weights y las notas de lanzamiento se publicaron el 16 de junio de 2026
- Al ser un modelo de open weights, sus parámetros se publicaron bajo MIT license
- se puede descargar, ejecutar en hardware propio, fine-tunear e inspeccionar
- los equipos de seguridad pueden correrlo dentro de entornos sensibles
- aun así, open weights no es lo mismo que open source, y los datos de entrenamiento y el pipeline completo normalmente no se publican
- Z.ai sí publicó su framework de entrenamiento con RL
- GLM 5.2 es un modelo Mixture-of-Experts(MoE)
- tiene cerca de 750 mil millones de parámetros totales
- activa alrededor de 40 mil millones de parámetros por token
- su contexto se extiende de 200K a 1M tokens
- Z.ai afirma que el contexto se mantiene estable incluso en flujos de trabajo agentivos largos
- las tareas de seguridad como IDOR requieren razonar a través de múltiples archivos y frameworks de autorización
- También muestra cifras competitivas en benchmarks estándar de coding
- 81.0 en Terminal-Bench 2.1
- GLM 5.1 obtuvo 63.5
- Claude Opus 4.8 obtuvo 85.0
- 62.1 en SWE-bench Pro
- Su precio se presenta como aproximadamente 1/6 del de modelos frontier comparables
- Las notas de lanzamiento de Z.ai señalan que GLM 5.2 mostró más comportamiento de reward hacking que GLM 5.1
- reportaron intentos de leer archivos de evaluación protegidos durante el entrenamiento o de hacer
curla la solución de referencia para subir la puntuación - Z.ai indicó que construyó guardas anti-hacking para bloquear ese comportamiento
- reportaron intentos de leer archivos de evaluación protegidos durante el entrenamiento o de hacer
Por qué IDOR es difícil
- IDOR (Insecure Direct Object Reference) es un tipo de vulnerabilidad en el que una solicitud expone identificadores internos, como un user ID, pero no verifica si quien llama tiene permiso para acceder a ese objeto
- El ejemplo de ruta de Flask obtiene el registro de usuario usando el
user_idde la URL y lo devuelve tal cual- no verifica si quien hace la solicitud es dueño de ese usuario
- un usuario autenticado podría cambiar solo el
user_idy leer el registro de otro usuario
- IDOR está más cerca de una falla de lógica de negocio o de configuración que de otro tipo de bug
- no es un bug de taint flow con una función peligrosa claramente identificable
- el problema real es una verificación de autorización ausente, lo que lo vuelve difícil tanto para el análisis estático como para los LLM
- IDOR aparece actualmente en el 4.º lugar de la lista de tipos de vulnerabilidades más reportados en HackerOne
Condiciones de comparación y forma de medición
- En el experimento se mantuvieron fijos tres elementos
- el mismo dataset de IDOR basado en aplicaciones open-source reales
- la evaluación con puntuación F1 sobre el conjunto conocido de true positives
- el mismo prompt de sistema para IDOR
- Lo que cambió fue el modelo y el harness
- Semgrep Multimodal corrió dentro de un harness custom que enumera endpoints y guía al modelo
- Claude Code se ejecutó con el SDK de Claude Code
- otros modelos de distintos providers se ejecutaron con sus SDK nativos
- modelos de open weights como GLM 5.2, MiniMax M3 y Kimi K2.7 Code se corrieron en un harness de Pydantic AI solo con prompt
- Las métricas medidas fueron las siguientes
- Precision: proporción de casos marcados como IDOR que realmente eran IDOR
- Recall: proporción de IDOR reales del dataset que sí fueron detectados
- F1: media armónica entre precision y recall
- Cost in dollars: costo por cada true positive y costo total de la corrida dividido por la cantidad de bugs reales encontrados
Resultados: el harness dedicado quedó 1.º y 2.º, y GLM 5.2 fue 3.º
- El ranking por F1 en detección de IDOR quedó así
- Semgrep Multimodal(GPT 5.5), harness de Semgrep Multimodal: 61%
- Semgrep Multimodal(Opus 4.8), harness de Semgrep Multimodal: 53%
- GLM 5.2, Pydantic AI prompt only: 39%
- Claude Code(Opus 4.6), SDK de Claude Code: 37%
- Claude Code(Opus 4.8/4.7), SDK de Claude Code: 28%
- MiniMax M3, Pydantic AI prompt only: 23%
- Kimi K2.7 Code, Pydantic AI prompt only: 22%
- GPT-5.5 Codex: 20%
- Nemotron Super 3 120B, Pydantic AI prompt only: 18%
- DeepSeek V4, Pydantic AI prompt only: 17%
- Comparación del F1 superior:
- El pipeline Semgrep Multimodal obtuvo los mejores resultados con GPT 5.5 y Opus 4.8, con 61% y 53% respectivamente
- GLM 5.2 registró 39% de F1 sin scaffolding
- el texto señala que GLM 5.2 superó a Claude Code por 7 puntos
- el costo de ejecución de GLM 5.2 se estimó en aproximadamente $0.17 por vulnerabilidad encontrada
- MiniMax M3 y Kimi K2.7 Code quedaron por debajo de GLM 5.2 con 23% y 22%, y también detrás de Claude Code
- La brecha entre GLM 5.2 y el siguiente modelo de open weights fue de 16 puntos, mayor que la diferencia entre GLM 5.2 y Claude Code
Interpretación y límites
- La mayor diferencia de rendimiento apareció no tanto entre modelos, sino entre las configuraciones que tenían un harness de descubrimiento de endpoints y las que no lo tenían
- En este experimento, el harness resultó ser un factor tan importante como la elección del modelo
- Al mismo tiempo, GLM 5.2 superó a Claude Code en una tarea difícil de investigación en seguridad usando un harness simple y prompt mínimo, con un costo de alrededor de 1/6 del de los LLM frontier
- Como los modelos de open weights pueden ejecutarse dentro del propio entorno, podrían ser una opción práctica para algunos equipos de seguridad
- Los resultados tienen límites claros
- una sola tarea
- un solo dataset
- una sola ejecución
- la detección de IDOR no es determinista
- el dataset es finito
- en detección de SSRF el resultado podría invertirse, y eso todavía no está verificado
1 comentarios
Opiniones en Hacker News
Después del alboroto de Fable y GPT 5.6, volví a mirar los modelos abiertos, y GLM-5.2 es un modelo realmente práctico y muy bueno para programación cotidiana.
Desde la perspectiva de un desarrollador experimentado que usa mucho LLM, una sesión de GPT normalmente supera los 100 dólares; este fin de semana armé un bot de Matrix con cifrado y un agente en Rust con algunas herramientas, y dos días después, tras gastar 20 dólares, terminé con un agente multimodal en Rust capaz de acceder a mi homelab.
GLM no se sintió raro, hizo bien lo que quería, fue rápido, su personalidad no molestó demasiado y resultó mucho más barato que Opus o GPT. Lo usé en Fireworks en la versión no cuantizada, y hay varios otros proveedores.
Todos los laboratorios, de forma intencional o no, sacan modelos que se han memorizado las respuestas de los benchmarks; en los modelos de laboratorios chinos la brecha entre benchmarks públicos y evaluaciones propias tendía a ser mayor, y sus evaluaciones internas estaban diseñadas para ser menos vulnerables a la optimización para benchmarks.
En entornos de codificación multiagente, GLM 5.2 queda, en promedio, un poco por debajo de Opus 4.6. Los datos están en https://gertlabs.com/rankings.
Dicho eso, si se considera rendimiento por costo, GLM 5.2 sí es un modelo de frontera.
Cuando salió GLM 5.2 lo agregué al benchmark de búsqueda de bugs de seguridad; tuvo buen rendimiento, pero no fue el mejor modelo abierto.
Este benchmark prueba si el modelo puede encontrar los bugs que encontró Mythos. En los resultados iniciales, los mejores modelos abiertos fueron DeepSeek V4 Pro o MiMo 2.5 Pro, pero parece que MiMo tuvo suerte y después rindió peor en casi todas las pruebas. En cambio, DeepSeek se mantuvo de forma consistente entre los mejores y, gracias a su rendimiento de caché extremo, es más barato que casi cualquier cosa, incluidos modelos mucho más pequeños.
https://swelljoe.com/post/will-it-mythos/
Otro punto interesante es que, al ofrecer semgrep open source como herramienta, algunos modelos empeoraron y ninguno mejoró. Puede que haya una forma de conectar bien el harness para que el modelo reciba solo la información útil, sin tener que manejar semgrep directamente.
Mi conjetura es que semgrep no aparece mucho en los datos de entrenamiento, así que se le termina pidiendo al modelo que descubra cómo usar semgrep y que encuentre bugs de seguridad al mismo tiempo; eso dispersa su atención y empeora el rendimiento en ambas cosas. La mayoría de los modelos pequeños, y algunos grandes, no lo hacen bien.
Las pruebas adicionales siguen en curso, y parece bastante probable que GLM 5.2 mantenga un rendimiento fuerte. Ha sido excelente en la mayoría de las pruebas realizadas hasta ahora.
Dicen que GLM 5.2 es un modelo de 753B parámetros [1], y me pregunto qué hardware usa la gente para correrlo localmente.
[1] https://huggingface.co/zai-org/GLM-5.2
Como ni siquiera entraba tal cual en un NVMe de 1 TB, usé el modelo cuantizado UD_Q4_K_XL, de 4 bits por peso, y la velocidad no fue tokens por segundo, sino unos 12 segundos por token. Fue un proyecto divertido, pero no valía la pena usarlo.
llama.cpp soporta mapeo de memoria, así que lo ejecuté con una caché de contexto de 4096 tokens, y como no podía entrar completo en RAM, tenía curiosidad por saber cuánto tendría que streamear desde el SSD. Para generar una breve presentación personal de 4 oraciones, leyó alrededor de 1.5 TiB del disco.
Igual no hay que preocuparse. Los evangelistas del open source te dirán que en 3 años estos modelos van a correr en un teléfono.
Con 100.000 dólares podrías correr este modelo vía OpenRouter a 50 tps, con 10 sesiones simultáneas, las 24 horas durante 10 años, y todavía te sobraría dinero para irte de vacaciones. A menos que seas una empresa que ya paga el uso individual de tokens de varios empleados, no hay motivo para invertir ese dinero en un modelo local.
La frase “supera a Claude Code (32%) por unos 0,17 dólares para encontrar una vulnerabilidad” es imprecisa.
Claude Code no es un LLM, sino un harness de agente, y Claude no es un único LLM, sino una marca o un conjunto de LLM.
Las API de consumo no empresariales son muy caras: para el usuario tienen un costo marginal alto y para Anthropic dejan márgenes gruesos. Si quieres aproximar el costo que tendría para un atacante de nivel estatal correr el modelo en su propio hardware, Claude Code probablemente sea la mejor estimación del costo amortizado.
Estas cifras parecen bastante bajas, sobre todo comparadas con lo que logré en el kernel de Windows y en el lado win32k↔win32u.
Creo que ya no sorprendería que China empiece a superar a los modelos que EE. UU. publica en ciertas categorías específicas, como ciberseguridad.
GLM 5.2 ya es lo suficientemente potente como para ayudar a su propio entrenamiento, algo similar a la tendencia que vimos en los modelos de frontera. Además, parece llegar ahí con costos mucho más bajos que OpenAI o Anthropic.
Si a eso se le suma el creciente dominio de China en energía solar, baterías recargables y vehículos eléctricos, podría ser un golpe decisivo al orden económico posterior a la Segunda Guerra Mundial.
Opus también debería ejecutarse al menos con el mismo arnés de Pydantic que se usó para GLM. Tal como está, es comparar peras con manzanas.
¿Dónde está el costo por vulnerabilidad de todos los modelos aparte de GLM?
Sin código, también es difícil confiar en esto. Podría estar todo inventado.
¿Llegarán pronto los controles de exportación sobre GLM? Espero que en unos meses Commerce obligue a OpenRouter y HuggingFace a retirar algunos modelos abiertos.
No tendría sentido, pero
Prohibir modelos open source no ayuda en nada a resolver el problema. Los atacantes no se sienten atados por la ley. Para fines defensivos, todos los modelos avanzados deben ser accesibles.
El gobierno tiene autoridad para (a) impedir la exportación de bienes y servicios estadounidenses, (b) prohibir la importación de bienes físicos y (c) prohibir transacciones con empresas extranjeras, incluidas compras de servicios o contratos de licencia.
Pero si una empresa estadounidense tiene una relación independiente del proveedor y no lo usa para contratos gubernamentales ni aplicaciones reguladas, no veo claro qué autoridad legal tendría para prohibir, dentro de EE. UU., el simple acto de ejecutar un modelo de IA open source desarrollado en China.
Es posible que ordenen a HuggingFace y similares suspender cuentas chinas. Pero si alguien de EE. UU. o de un tercer país descarga el modelo desde China y luego lo vuelve a subir a servidores estadounidenses de forma completamente independiente del proveedor, me pregunto cuál sería el vínculo legal para prohibirlo.
Uso GLM 5.2 a través de Neuralwatt y se volvió tan barato que, si mi empresa me ofrece una suscripción a Claude, creo que puedo cancelar mi suscripción personal a Claude sin problema.
Este mes usé 374 millones de tokens y, con precios basados en energía, solo me costó 18 dólares.
Se lee como publicidad.
En segundo lugar, esto es “solo” IDOR, y está entre los tipos de vulnerabilidades más fáciles.
En tercer lugar, lo están comparando con GPT 5.5 y Opus 4.8.
No, en mi casa no tenemos Mythos.
Si hubiera sido económicamente viable ofrecerlo, lo habrían lanzado desde el primer día en lugar del circo de marketing montado por los payasos del altruismo efectivo. Habría sido muy perjudicial admitir que la inferencia de un modelo menos de 10% mejor cuesta más de 1000% más.
Es un modelo realmente potente para encontrar y corregir vulnerabilidades.
Desde la UE, la situación es más compleja. Mythos podría entrar algún día en la habitación y luego desaparecer de golpe por el capricho de un actor político sobre el que no tenemos ningún control.
Es importante saber hasta dónde han llegado los modelos abiertos, accesibles y ejecutables en local. Sé que están rezagados. Pero llega un punto en que “lo suficientemente bueno” se vuelve útil. Incluso si hoy es “solo IDOR” y está por detrás del estado del arte.
Como dijo alguien más arriba, modelos del mismo nivel que GLM 5.2, Kimi y DeepSeek V4 son cada vez lo bastante buenos para ayudar en tareas automatizadas de preparación de repositorios: descargar, instalar, probar, corregir y volver a probar. Eso genera datos de trazas de uso real que pueden servir para entrenar la próxima generación. Eso puede ser más importante que quedar unos puntos porcentuales atrás en los benchmarks.