Tra le 14:05 e le 15:22 UTC di ieri — una finestra di 77 minuti — sono stati pubblicati venti CVE contro PraisonAI, un framework multi-agent. Gli identificativi sono contigui, da CVE-2026-55522 a CVE-2026-55541. I crediti vanno a tredici reporter distinti. La più grave ha un punteggio di 9,1.

Tutte rimandano a un solo commit

Estraendo l’elenco dei riferimenti da tutti e venti gli advisory e rimuovendo i duplicati, si ottiene esattamente un commit di correzione, presente in ogni singolo record. Era descritto come un intervento di rafforzamento della validazione dell’input, è stato integrato il 13 giugno 2026 ed è stato distribuito lo stesso giorno. La disclosure è quindi arrivata 73 giorni dopo la correzione del codice. Abbiamo confrontato il file server interessato tra le due release per confermare che la modifica è reale e non solo cosmetica.

Ciò che l’inquadramento comune sbaglia

Venti CVE non significano venti vulnerabilità. Un unico commit di hardening che ha chiuso una classe di falle nella validazione dell’input è stato scomposto in venti record numerati separatamente da tredici reporter che lavoravano sullo stesso codice. L’esempio più evidente: tre dei venti descrivono lo stesso bug — un argomento API key ignorato — e riportano 8,6, 7,3 e nessun punteggio CVSS. Un solo difetto, tre identificativi, tre trattamenti di gravità diversi. Inoltre, la descrizione testuale dell’intervallo interessato in un advisory contraddice il proprio intervallo leggibile dalla macchina di nove release.

Perché questo altera il quadro

Il numero di CVE viene usato come proxy del rischio di una dipendenza — dagli acquisti, dagli scanner, da chiunque confronti i framework. Venti identificativi contro un solo progetto in un pomeriggio fanno pensare a qualcosa di catastrofico e, nella sostanza, equivalgono a una correzione di giugno. Nel frattempo, la duplicazione dei punteggi rende incoerente il triage automatizzato: una policy che fa scattare l’escalation sopra 8,0 si attiva su una copia del bug, ignora la seconda e non vede affatto la terza.

La parte davvero grave

Chi non ha aggiornato dall’inizio di giugno ha eseguito codice noto come vulnerabile per due mesi e mezzo senza alcun segnale nel record pubblico che lo spingesse a intervenire — perché la correzione è stata distribuita come un normale commit di hardening e gli advisory sono arrivati 73 giorni dopo. Quel ritardo, non il numero venti, è la vera esposizione.