CVE-2026-44338: scanner su PraisonAI in meno di 4 ore

CVE-2026-44338: scanner su PraisonAI in meno di 4 ore

Uno scanner identificato come CVE-Detector/1.0 ha colpito istanze esposte di PraisonAI alle 17:40:55 UTC dell’11 maggio 2026, ovvero meno di quattro ore dopo la pubblicazione dell’advisory. Il probe ha confermato il bypass dell’autenticazione nel legacy Flask API server, aprendo l’accesso a workflow agentici preconfigurati. La rapidità dell’azione segnala che l’ecosistema degli agenti autonomi open-source è già nel mirino: non servono zero-day, basta una CVE pubblica per trasformare un default insicuro in rischio operativo concreto.

Come funziona il bypass nel legacy Flask API server

Il PraisonAI legacy API server è implementato in Flask e gestisce le richieste verso gli agenti configurati dall’operatore. Nelle versioni affette, il controllo di autenticazione è disattivato per impostazione predefinita: il codice imposta AUTH_ENABLED a False e AUTH_TOKEN a None, rendendo superflua qualsiasi verifica su header o cookie di sessione.

Quando un client effettua una richiesta GET all’endpoint /agents, il server risponde con stato HTTP 200 OK e un payload JSON che include il campo agent_file valorizzato come agents.yaml e l’elenco degli agenti disponibili. Il metodo POST su /chat, invece, richiama direttamente PraisonAI(agent_file='agents.yaml').run() senza analizzare o filtrare il contenuto del campo message.

Questo significa che chiunque possa raggiungere l’endpoint ha la capacità di innescare workflow predefiniti, indipendentemente dalle intenzioni del proprietario del sistema. Il difetto interessa le versioni dalla 2.5.6 alla 4.6.33 inclusa e ha ricevuto un punteggio CVSS v3.1 di 7.3, classificato HIGH. Il vettore di attacco è di tipo rete, non richiede autenticazione, privilegi speciali o interazione da parte dell’utente finale.

Dalle 13:56 alle 17:40 UTC: la corsa dello scanner CVE-Detector/1.0

L’advisory relativo a CVE-2026-44338 è diventato pubblico alle 13:56:16 UTC dell’11 maggio 2026. Alle 17:40:55 UTC dello stesso giorno, la piattaforma di threat intelligence di Sysdig ha registrato il primo contatto sospetto. Lo strumento si identificava con lo User-Agent CVE-Detector/1.0 e operava dall’indirizzo IP 146.190.133.49, allocato all’interno della rete DigitalOcean con numero di sistema autonomo AS14061 negli Stati Uniti.

L’attività non è stata casuale: si è articolata in due passate ben distinte, separate da un intervallo di circa otto minuti l’una dall’altra. Ciascuna passata ha generato un volume di circa settanta richieste, un ritmo compatibile con uno scanner automatico piuttosto che con un attaccante manuale.

La prima sequenza ha preso di mira percorsi generici per mappare la superficie, mentre la seconda ha colpito direttamente gli endpoint AI-agent di PraisonAI. Il confronto tra orari dimostra che l’intervallo tra disclosure e primo probe confermato è rimasto sotto la soglia delle quattro ore, un tempo che rende impraticabile qualsiasi approccio di patching basato su cicli settimanali o anche giornalieri.

"Within three hours and 44 minutes of the advisory becoming public, a scanner identifying itself as CVE-Detector/1.0 was probing the exact vulnerable endpoint on internet-exposed instances."

— Sysdig Threat Research Team

Impatto potenziale: cosa rischia chi usa PraisonAI esposto

Il bypass dell’autenticazione non equivale a un’esecuzione remota arbitraria di codice nel senso classico del termine. Tuttavia, il pericolo è funzionale al design del framework: l’endpoint /chat agisce da grilletto per workflow che gli operatori hanno deliberatamente costruito per svolgere compiti utili. Senza barriera di autenticazione, chiunque possa raggiungere il server eredita i permessi di quei workflow.

Sysdig ha elencato tra gli impatti osservabili in produzione il consumo indesiderato di quota API dei modelli linguistici, con costi diretti e imprevedibili per chi paga l’utilizzo dei LLM. È inoltre possibile l’esecuzione non autorizzata di tool agent configurati in agents.yaml, che possono includere interpreter di codice, accesso shell o operazioni di input-output su file.

Non va trascurata la disclosure della configurazione stessa: la risposta a GET /agents espone la struttura degli agenti e il riferimento al file di configurazione, fornendo informazioni preziose per eventuali attacchi successivi. Allo stato attuale, non sono state osservate richieste POST a /chat, il che suggerisce una fase di ricognizione e validazione piuttosto che exploitation interattiva.

Rimane però ignota l’identità e l’obiettivo finale degli operatori dietro l’IP 146.190.133.49, così come il numero effettivo di istanze esposte su Internet o già compromesse. Non è inoltre provato che questo scanner specifico utilizzasse tooling generato tramite intelligenza artificiale, anche se Sysdig segnala un trend generale di accelerazione verso l’ecosistema AI.

Perché l’ecosistema AI-agent è già nel mirino

L’incidente non è un’anomalia isolata, ma il segnale di una transizione più ampia nel comportamento degli attori delle minacce. Come ha osservato Sysdig, gli strumenti avversari hanno scalato all’intero ecosistema AI e degli agenti, senza distinzione di notorietà o dimensione del progetto. PraisonAI non gode dello stesso rilievo pubblico di piattaforme cloud mainstream, eppure uno scanner automatico lo ha preso di mira entro poche ore dalla pubblicazione dell’advisory.

Questo implica che i motori di ricognizione non attendono che una tecnologia diventi dominante prima di integrarla nei propri target list. Il default insicuro di un framework open-source, combinato con un’istanza esposta su Internet, genera una finestra di esposizione misurabile in ore, non in giorni.

Per i team di sicurezza, il cambiamento è di natura quantitativa e qualitativa: il tempo tra la divulgazione di una CVE e il primo tentativo di exploit è sceso al di sotto di una singola tornata di lavoro. I cicli di remediation tradizionali, fondati su scansioni periodiche, approvazioni change management e finestre di manutenzione programmata, diventano così strutturalmente insufficienti a contenere il rischio.

Cosa fare adesso

Le azioni da intraprendere sono quattro e prioritarie. In primo luogo, è necessario aggiornare PraisonAI alla versione 4.6.34, che risolve il difetto. In secondo luogo, chi non ha già provveduto deve verificare se il legacy API server sia esposto su Internet e, ove possibile, rimuoverlo dalla superficie pubblica o limitarlo a reti fidate.

In terzo luogo, i log di accesso devono essere ispezionati per rilevare la presenza dello User-Agent CVE-Detector/1.0 o connessioni provenienti dall’indirizzo IP 146.190.133.49, eventi che indicano almeno una scansione di ricognizione. Infine, è indispensabile condurre un audit del file agents.yaml per limitare i tool wired e i permessi associati ai workflow agentici: ridurre ciò che un agente può fare autonomamente diminuisce il danno massimo in caso di accesso non autorizzato.

La sottile linea che separa una scansione di vulnerabilità da un attacco in corso si misura oggi in minuti, non in giorni. Il caso PraisonAI dimostra che il problema non è più la scarsità di exploit disponibili, ma la latenza strutturale delle difese organizzative.

Per chi gestisce infrastrutture AI, la domanda pertinente non è se un agente autonomo verrà preso di mira, ma se i propri processi di patching e hardening reggeranno una finestra di esposizione che ormai si chiude in meno di quattro ore.

Domande frequenti

Perché il legacy API server aveva l’autenticazione disabilitata?

Il codice sorgente di PraisonAI, nel file src/praisonai/api_server.py, includeva i valori hard-coded AUTH_ENABLED = False e AUTH_TOKEN = None. Questa scelta progettuale nelle versioni affette costituiva un default insicuro che rendeva accessibili senza credenziali gli endpoint /agents e /chat, permettendo a chiunque di interrogare la lista agenti e innescare workflow.

Se non sono state osservate richieste POST, qual è il rischio concreto?

L’assenza di richieste POST a /chat indica che l’attività rilevata si è limitata a una fase di ricognizione e validazione del bypass. Tuttavia, la conferma che l’endpoint risponde senza autenticazione espone workflow agentici preconfigurati in grado di consumare quota LLM, eseguire tool locali o esfiltrare dati. Il rischio operativo rimane quindi reale per ogni istanza non aggiornata.

Cosa cambia per chi non utilizza PraisonAI?

La velocità dell’exploit, inferiore alle quattro ore dalla disclosure, indica che gli strumenti di attacco monitorano sistematicamente l’ecosistema AI-agent anche al di fuori dei progetti più noti. Qualsiasi framework con default insicuri e superficie esposta su Internet rischia di diventare bersaglio nel lasso di tempo di una singola mattinata lavorativa, rendendo urgente la revisione dei tempi di remediation.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://thehackernews.com/2026/05/praisonai-cve-2026-44338-auth-bypass.html
• https://nvd.nist.gov/vuln/detail/CVE-2026-44338
• https://webflow.sysdig.com/blog/cve-2026-44338-praisonai-authentication-bypass-in-under-4-hours-and-the-growing-trend-of-rapid-exploitation
• https://www.securityweek.com/hackers-targeted-praisonai-vulnerability-hours-after-disclosure/
• https://vulnerability.circl.lu/vuln/cve-2026-44338