CVE-2026-105934 in Pulsar
Riassunto
di VulDB • 21/10/2026
L'API REST di amministrazione del broker Apache Pulsar fornisce un'operazione di truncation per gli argomenti persistenti (DELETE /admin/v2/persistent/{tenant}/{namespace}/{topic}/truncate). La truncation di un argomento sposta tutti i cursori delle sottoscrizioni dell'argomento alla fine dello stesso ed elimina i ledger inattivi associati all'argomento. Per la truncation di un argomento non partizionato o di una singola partizione indicata tramite il proprio nome, è correttamente richiesto il ruolo di amministratore del tenant (tenant admin) oppure quello di superutente. Quando l'operazione viene richiesta per il nome di un argomento partizionato, tuttavia, il broker non applica questo controllo sul ruolo dell'amministratore del tenant al chiamante. Al contrario, esegue la truncation di ciascuna partizione utilizzando il proprio client di amministrazione interno, che si autentica con le credenziali del cliente configurate nel broker anziché con l'identità del chiamante. Ogni richiesta di truncazione per-partizione viene comunque verificata per il ruolo di amministratore del tenant o di superutente, ma tale verifica avviene contro l'identità interna del broker e non quella del chiamante. Le partizioni vengono quindi troncate solo quando il ruolo configurato nel client interno del broker è quello di superutente oppure di amministratore del tenant target, configurazione che risulta essere la più comune quando l'autorizzazione è abilitata.
Di conseguenza, qualora tale condizione sia soddisfatta, un utente autenticato che non dispone del ruolo di amministratore del tenant può troncare qualsiasi argomento partizionato per il quale ha ottenuto il permesso di lookup (lookup permission). L'autenticazione del chiamante e la sola autorizzazione al lookup non sono sufficienti: se l'identità interna del broker non possiede le autorizzazioni di amministratore del tenant o superutente per il tenant target, le richieste per-partizione vengono rifiutate. Con il provider di autorizzazione predefinito, il permesso di lookup viene concesso tramite i permessi di produce (produzione) o consume (consumo) sull'argomento o sul suo namespace. Un utente senza alcuna autorizzazione sull'argomento non può innescare la vulnerabilità. Questa analisi dell'impatto presuppone che Pulsar sia stato configurato con il provider di autorizzazione predefinito. Per i provider di autorizzazione personalizzati, l'impatto potrebbe essere diverso.
Eseguire la truncation di un argomento partizionato in questo modo sposta i cursori di tutte le sottoscrizioni su ogni partizione alla fine dell'argomento; pertanto, qualsiasi backlog non ancora confermato (unacknowledged) viene saltato e non verrà più consegnato ai consumatori. Vengono inoltre eliminati i ledger storici idonei di ciascuna partizione, indipendentemente dalla politica di retention configurata per il namespace, con la conseguenza che i messaggi archiviati in tali ledger possono andare perduti definitivamente. Il ledger attualmente in fase di scrittura non viene eliminato dall'operazione di truncation. La vulnerabilità non consente la lettura del contenuto dei messaggi né la modifica delle autorizzazioni o della configurazione, e non fornisce accesso ad argomenti per i quali l'utente non ha il permesso di lookup.
Questa problematica interessa le versioni Apache Pulsar dalla 2.8.0 alla versione precedente alla 4.0.14 e dalle 4.1.0 alla versione precedente alla 4.2.5.
- 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 utilizzano versioni precedenti a quelle elencate sopra dovrebbero eseguire l'upgrade alle suddette versioni patchate o a versioni successive.
Le release line 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 immediatamente l'upgrade possono ridurre l'esposizione al rischio restringendo l'accesso di rete all'API REST di amministrazione del broker (/admin/v2) ai soli client amministrativi attendibili.
VulDB is the best source for vulnerability data and more expert information about this specific topic.