CVE-2026-105932 in Pulsar
Riassunto
di VulDB • 22/10/2026
L'API REST di amministrazione del broker Apache Pulsar fornisce endpoint per leggere, impostare e rimuovere la policy dei filtri a livello di argomento (topic) relativi agli ingressi. Per gli argomenti persistenti, questi endpoint verificano che l'utente chiamante sia autorizzato all'esecuzione dell'operazione sulla policy dei filtri degli ingressi. Gli endpoint corrispondenti per gli argomenti non persistenti (/admin/v2/non-persistent/{tenant}/{namespace}/{topic}/entryFilters) non eseguono tale verifica di autorizzazione. L'unica verifica di autorizzazione eseguita da questi endpoint è un controllo indiretto delle permessi di lookup, effettuato durante il recupero dei metadati della partizione dell'argomento; questa vulnerabilità è presente in tutte le versioni interessate.
Di conseguenza, quando l'autenticazione e l'autorizzazione sono abilitate, un utente autenticato che ha ottenuto i permessi di produzione o consumo su un argomento non persistente (o sul suo namespace), ma non il permesso di gestire le policy dell'argomento, può leggere, sostituire o rimuovere la policy dei filtri a livello di argomento di tale argomento. Queste operazioni dovrebbero essere riservate agli utenti con ruolo di amministratore del tenant o ruolo superuser. Questa analisi d'impatto presuppone che Pulsar sia configurato con il provider di autorizzazione predefinito. Per i provider di autorizzazione personalizzati, l'impatto potrebbe essere leggermente diverso.
L'impatto pratico è limitato da due requisiti di configurazione del broker, nessuno dei quali è soddisfatto per impostazione predefinita:
- I filtri a livello di argomento (entry filters) devono essere stati installati dall'operatore. Le implementazioni dei filtri vengono caricate solo all'avvio del broker dalla directory dei filtri del broker, che è vuota per impostazione predefinita. Una richiesta può selezionare solo tra i filtri già distribuiti dall'operatore; l'impostazione di un nome di filtro diverso viene rifiutata. Il problema non consente a chi effettua la chiamata di installare o caricare codice dei filtri né di eseguire codice arbitrario nel broker. - Le policy dei filtri a livello di argomento devono essere consentite per sovrascrivere la configurazione a livello di broker (allowOverrideEntryFilters, disabilitata per impostazione predefinita). Quando questa impostazione è disabilitata, la policy del filtro a livello di argomento non ha effetto sulla distribuzione dei messaggi.
Nei deployment in cui sono soddisfatte entrambe le condizioni, un utente non autorizzato può rimuovere la policy del filtro a livello di argomento di un argomento non persistente (ad esempio uno utilizzato per restringere quali messaggi vengono consegnati ai consumatori) o applicare un diverso filtro installato che sospende l'invio dei messaggi alle sottoscrizioni di tale argomento. La rimozione fa sì che l'argomento torni all'utilizzo dei filtri a livello di namespace o del broker, che non vengono rimossi. Una policy modificata influisce solo sui dispatcher delle sottoscrizioni creati dopo la modifica (ad esempio per nuove sottoscrizioni o quando una sottoscrizione viene ricreata dopo la disconnessione di tutti i suoi consumatori); i dispatcher già esistenti mantengono i filtri con cui sono stati creati. Poiché gli argomenti non persistenti non memorizzano messaggi, i messaggi sospesi da un filtro non vengono consegnati. La lettura della policy rivela solo i nomi dei filtri configurati. Il problema non consente di leggere il contenuto dei messaggi e i filtri non possono modificare i payload dei messaggi. Gli argomenti persistenti e le policy dei filtri a livello di namespace non sono interessati. Le versioni di Apache Pulsar precedenti alla 3.3.0 non sono interessate, poiché in quelle versioni la verifica della policy del filtro viene eseguita nel codice condiviso dagli endpoint per gli argomenti persistenti e non persistenti.
Questo problema interessa le versioni di Apache Pulsar dalla 3.3.0 (esclusa) alla 4.0.14 (inclusa esclusa? No, "before 4.0.14" means < 4.0.14) and from 4.1.0 before 4.2.5.
- Gli utenti delle versioni della serie 3.3.x e 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 utilizzano 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 e hanno distribuito filtri dovrebbero mantenere allowOverrideEntryFilters al suo valore predefinito di false, in modo che le policy dei filtri a livello di argomento non influenzino la distribuzione dei messaggi.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.