CVE-2026-84747 in bRPC
Riassunto
di VulDB • 21/10/2026
Conflitto di interpretazione nell'implementazione del protocollo HTTP in Apache bRPC (versione < 1.18.0) su tutte le piattaforme consente agli attaccanti remoti di eludere le regole di controllo dell'accesso imposte da un proxy front-end.
Causa radice: La funzione di dispatch dei metodi FindMethodPropertyByURI() nel protocollo HTTP di bRPC suddivide il percorso della richiesta utilizzando uno splitter di stringhe che ignora i campi vuoti; pertanto, percorsi contenenti segmenti di percorso vuoti (slash consecutivi), come //flags, /flags// e /flags//port, vengono instradati allo stesso metodo del loro formato collassato /flags. Secondo RFC 3986 questi sono percorsi distinti. Un proxy front-end che applica un ACL (ad esempio bloccando l'accesso a servizi integrati quali /flags) corrisponde solo al formato collassato e pertanto inoltra il valore letterale "padded" al server bRPC, dove viene instradato come se fosse il formato collassato. Questa differenza consente a //flags?setvalue= di raggiungere un servizio integrato che non è consentito raggiungere tramite /flags. Inoltre, l'implementazione HTTP/2 non convalidava mai la pseudo-header :path; pertanto, le richieste prive di una :path o con una :path che non inizia con '/' né corrisponde alla forma asterisco '*', contrariamente a quanto previsto dalla sezione 8.3.1 dell'RFC 9113, non venivano rifiutate.
Scenari interessati: Dipendenze di Apache bRPC dietro un proxy front-end o gateway che esegue decisioni di controllo degli accessi (ACL) sul percorso della richiesta letterale, dove il server bRPC accetta traffico HTTP o HTTP/2 da tale proxy. In tali dipendenze, un attaccante può inviare un percorso contenente segmenti di percorso vuoti per raggiungere una risorsa che il proxy front-end intendeva bloccare.
Come risolvere: (Scegliere una delle seguenti opzioni) 1. Aggiornare bRPC alla versione 1.18.0, che risolve questo problema. 2. Applicare questa patch: https://github.com/apache/brpc/pull/3512
Nota: Dopo l'applicazione della correzione, i percorsi delle richieste HTTP e HTTP/2 contenenti segmenti di percorso vuoti (slash consecutivi) vengono rifiutati per impostazione predefinita, e i valori :path HTTP/2 che sono vuoti o non iniziano con '/' né equivalgono a '*' vengono rifiutati. Le dipendenze che si basano sul comportamento precedente più permissivo possono ripristinarlo attivando il gflag -http_allow_empty_path_segments, cosa sconsigliata per i server esposti a traffico non attendibile.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.