Entre las 14:05 y las 15:22 UTC de ayer —una ventana de 77 minutos— se publicaron veinte CVE contra PraisonAI, un framework multiagente. Los identificadores van de forma contigua desde CVE-2026-55522 hasta CVE-2026-55541. Se atribuye el trabajo a trece redactores distintos. El más grave tiene una puntuación de 9,1.

Todos apuntan a un mismo commit

Al extraer la lista de referencias de los veinte avisos y eliminar duplicados, el resultado es exactamente un commit de corrección, presente en todos y cada uno de los registros. Se titulaba como un cambio de refuerzo de la validación de entradas, se integró el 13 de junio de 2026 y se publicó ese mismo día. La divulgación, por tanto, llegó 73 días después de que el código fuera corregido. Comparamos el archivo del servidor afectado entre las dos versiones para confirmar que el cambio es real y no meramente cosmético.

En qué falla el marco común

Veinte CVE no son veinte vulnerabilidades. Un único commit de endurecimiento que cerró una clase de fallos de validación de entradas se descompuso en veinte registros numerados por separado por trece redactores que trabajaban sobre la misma base de código. La ilustración más clara: tres de los veinte describen el mismo fallo —que se ignora un argumento de clave de API— y reciben 8,6, 7,3 y sin puntuación CVSS. Un único fallo, tres identificadores, tres tratamientos distintos de la gravedad. Además, la descripción en prosa del rango afectado de un aviso contradice su propio rango legible por máquina por nueve versiones.

Por qué esto distorsiona el registro

El recuento de CVE se usa como proxy del riesgo que supone una dependencia: por parte de compras, por parte de los escáneres, por cualquiera que compare frameworks. Veinte identificadores contra un único proyecto en una tarde suena catastrófico y, en la práctica, equivale a una única corrección de junio. Mientras tanto, la duplicidad de puntuaciones vuelve incoherente la clasificación automatizada: una política que escala por encima de 8,0 salta con una copia del fallo, ignora la segunda y no puede ver la tercera en absoluto.

La parte que sí es realmente grave

Cualquiera que no haya actualizado desde principios de junio ha estado ejecutando código con vulnerabilidades conocidas durante dos meses y medio sin nada en el registro público que le alertara —porque la corrección se publicó como un commit rutinario de endurecimiento y los avisos llegaron 73 días después. Esa brecha, no el número veinte, es la verdadera exposición.