CVE-2026-105869 in Pulsar
Riassunto
di VulDB • 21/10/2026
Il MultiRolesTokenAuthorizationProvider di Apache Pulsar autorizza un client con tutti i ruoli elencati nelle claim del suo JSON Web Token (JWT). Il provider è destinato all'uso con l'autenticazione tramite token, che verifica il token prima dell'autorizzazione. Tuttavia, il provider non verificava la firma del token stesso: analizzava le claim del token rimuovendo la firma e si fidava che l'autenticazione avesse già effettuato tale controllo.
Quando autenticazione e autorizzazione sono abilitate con un'impostazione anonymousUserRole non vuota, alcune richieste HTTP le cui credenziali falliscono l'autenticazione non vengono rifiutate, ma gestite come richieste del ruolo utente anonimo (anonymous user role). Per gli endpoint HTTP del broker, come la REST API di amministrazione, questo fallback si applica alle richieste che non specificano un metodo di autenticazione e richiede che strictAuthMethod sia impostato su false (il valore predefinito) laddove tale impostazione è disponibile. Per l'API WebSocket, le credenziali non valide possono inoltre fare fallback sul ruolo utente anonimo; questo percorso non applica il controllo strictAuthMethod. I dati di autenticazione mantenuti per una tale richiesta contengono ancora l'intestazione Authorization della richiesta. MultiRolesTokenAuthorizationProvider legge quindi il token bearer da quell'intestazione senza verificarne la firma e autorizza la richiesta con i ruoli presenti nella claim dei ruoli del token.
Di conseguenza, nelle distribuzioni che utilizzano MultiRolesTokenAuthorizationProvider insieme a un anonymousUserRole non vuoto e che permettono questo fallback, un client non autenticato può inviare una richiesta HTTP, ad esempio alla REST API di amministrazione o all'API WebSocket, con un token falsificato o privo di firma che elenca ruoli arbitrari, venendo autorizzato con tali ruoli. L'impatto può includere l'accesso super-user quando il token elenca un ruolo configurato in superUserRoles, consentendo al client di leggere e modificare tenant, namespace, argomenti (topics), permessi e configurazione del broker. Non sono richieste credenziali valide.
Le distribuzioni non sono interessate se utilizzano il provider di autorizzazione predefinito (PulsarAuthorizationProvider) o un altro provider di autorizzazione, oppure se anonymousUserRole non è impostato (il valore predefinito). Le richieste che si autenticano con successo tramite un token valido non sono influenzate, poiché il token letto da MultiRolesTokenAuthorizationProvider è quello verificato dall'autenticazione. Le connessioni che utilizzano il protocollo binario di Pulsar non sono interessate da questo problema, perché il broker non mantiene i dati di autenticazione del client per le connessioni assegnate al ruolo utente anonimo.
Nelle versioni corrette, MultiRolesTokenAuthorizationProvider ottiene i ruoli solo dai token verificati dal provider di autenticazione tramite token configurato, utilizzando le chiavi e le impostazioni di convalida configurate. Le richieste HTTP del broker assegnate al ruolo utente anonimo sono autorizzate esclusivamente come tale ruolo, e i token non validi non possono fornire ruoli aggiuntivi alle richieste WebSocket. Il broker fallisce l'avvio se MultiRolesTokenAuthorizationProvider è configurato con l'autorizzazione abilitata ma senza un provider di autenticazione tramite token.
Questo problema interessa le versioni di Apache Pulsar dalla 2.8.1 alla 4.0.13 (esclusa) e dalla 4.1.0 alla 4.2.4 (esclusa).
- Gli utenti delle versioni della serie 4.0.x dovrebbero effettuare l'upgrade almeno alla versione 4.0.14. - Gli utenti delle versioni della serie 4.1.x e 4.2.x dovrebbero effettuare l'upgrade almeno alla versione 4.2.5.
Gli utenti che operano con versioni precedenti a quelle elencate sopra dovrebbero effettuare l'upgrade alle suddette versioni patchate o a versioni successive.
Le linee di rilascio attualmente supportate di Apache Pulsar sono la 4.0.x e la 5.0.x. Il calendario delle versioni supportate è disponibile all'indirizzo https://pulsar.apache.org/contribute/release-policy/.
Gli utenti che non possono effettuare l'upgrade immediatamente possono rimuovere l'impostazione anonymousUserRole dalle configurazioni del broker e dei servizi WebSocket, oppure restringere l'accesso di rete agli endpoint HTTP di questi servizi ai client attendibili.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.