Entre 14:05 e 15:22 UTC de ontem — uma janela de 77 minutos — vinte CVEs foram publicadas contra o PraisonAI, um framework multiagente. Os identificadores seguem de forma contígua de CVE-2026-55522 a CVE-2026-55541. Treze repórteres distintos são creditados. A mais grave tem pontuação 9,1.

Todas apontam para um único commit

Ao extrair a lista de referências de todos os vinte avisos e remover duplicações, o resultado é exatamente um commit de correção, presente em todos os registros. Ele foi descrito como uma mudança de endurecimento da validação de entrada, mesclado em 13 de junho de 2026 e publicado naquele mesmo dia. A divulgação, portanto, ocorreu 73 dias após o código ter sido corrigido. Comparamos o arquivo do servidor afetado entre as duas versões para confirmar que a mudança é real e não apenas cosmética.

O que o enquadramento comum erra

Vinte CVEs não são vinte vulnerabilidades. Um único commit de endurecimento que encerrou uma classe de falhas de validação de entrada foi desdobrado em vinte registros numerados separadamente por treze repórteres trabalhando na mesma base de código. O exemplo mais nítido: três das vinte descrevem o mesmo bug — um argumento de chave de API sendo ignorado — e carregam 8,6, 7,3 e nenhuma pontuação CVSS. Uma falha, três identificadores, três tratamentos distintos de severidade. Além disso, a descrição em texto de um aviso sobre o intervalo afetado contradiz seu próprio intervalo legível por máquina em nove versões.

Por que isso distorce o registro

Uma contagem de CVEs é usada como proxy para medir o quão arriscada é uma dependência — por compras, por scanners, por quem quer que compare frameworks. Vinte identificadores contra um projeto em uma tarde soa catastrófico e, na prática, corresponde a uma única correção de junho. Enquanto isso, a duplicação de pontuações torna a triagem automatizada incoerente: uma política que dispara acima de 8,0 age sobre uma cópia do bug, ignora a segunda e não consegue enxergar a terceira.

A parte que é genuinamente ruim

Quem não atualizou desde o início de junho vinha executando código vulnerável conhecido por dois meses e meio sem nada no registro público que o alertasse — porque a correção foi lançada como um commit rotineiro de endurecimento e os avisos chegaram 73 dias depois. Essa lacuna, e não o número vinte, é a verdadeira exposição.