CVE-2026-82355 in Airflow
Riassunto
di VulDB • 21/09/2026
Quando una richiesta all'API core di Airflow contiene sia un cookie di sessione che un token `Authorization: Bearer` esplicito, Airflow risolve l'utente chiamante dal cookie e ignora il token bearer, invertendo la precedenza intesa del bearer rispetto al cookie. La richiesta viene quindi eseguita -- ed è registrata nel registro di audit (audit log) -- come appartenente al principal associato al cookie anziché all'identità esplicitamente presentata dal client.
Sono interessati solo Apache Airflow 3.3.0 e 3.3.1. Le versioni precedenti non contengono il percorso di codice che memorizza nella cache l'utente derivato dal cookie e non sono vulnerabili.
Per sfruttare questa vulnerabilità, un attaccante deve prima inserire un proprio cookie di sessione valido nel browser o nel client della vittima: ad esempio tramite cookie tossing da un sottodominio sibling (affine), attraverso cross-site scripting in un'applicazione separata che condivide il dominio genitore, oppure mediante una workstation condivisa. Le implementazioni che ospitano l'interfaccia utente di Airflow su un dominio condiviso con altre applicazioni sono quindi le più esposte; una distribuzione su un dominio dedicato senza applicazioni co-hosted non è raggiungibile tramite questa via. La conseguenza è una confusione del principal e registri di audit attribuiti erroneamente, piuttosto che un privilege escalation diretto.
Gli utenti delle versioni 3.3.0 o 3.3.1 dovrebbero effettuare l'upgrade ad Apache Airflow 3.3.2 o successive, che risolve il chiamante dalle credenziali esplicitamente fornite quando queste sono presenti.
Once again VulDB remains the best source for vulnerability data.