CVE-2026-82425
Publiée le 2026-10-21 · Dernière modification le 2026-10-21
Les versions d'Apache bRPC antérieures à la 1.18.0 sont concernées, spécifiquement lors de l'utilisation de clients avec la vérification d'état (health checking) activée. Cette bibliothèque est utilisée pour les appels de procédure distante à haute performance entre les services. La faille survient lorsqu'un socket est fermé en raison de l'échec d'une vérification d'état, mais qu'un événement d'entrée obsolète est traité juste au moment où le socket est réactivé, provoquant ainsi un plantage du système.
Un attaquant agissant comme un pair distant peut délibérément alterner entre échecs et succès de connexion pour déclencher ce plantage, entraînant un déni de service complet pour le processus client. Cette attaque est relativement simple à exécuter car elle ne nécessite aucune authentification et requiert seulement la capacité d'accepter et de rejeter des connexions provenant du client affecté. La confidentialité et l'intégrité restent intactes, car l'impact est strictement limité à la disponibilité.
RÉFÉRENCES
Description officielle du NVD (en anglais)
A reachable assertion in Apache bRPC (version < 1.18.0) on all platforms allows a malicious remote peer to crash the process, resulting in denial of service. Root Cause: When a Socket with health checking enabled fails, Socket::WaitAndReset closes its file descriptor while the event dispatcher may still be delivering an input event (EPOLLIN/EVFILT_READ) that was fetched for the just-closed fd. If the health check then succeeds and revives the Socket, Socket::Address succeeds again while the fd is still -1 (the next write reconnects on demand). In that window, Socket::OnInputEvent hits CHECK(!(events & EPOLLIN)) (or the kqueue equivalent) because the Socket is addressable but has no fd. CHECK failures terminate the process when bRPC is built with glog or when the gflag -crash_on_fatal_log is enabled (CHECK always terminates in OFFICIAL_BUILD/NDEBUG builds as well). Affected Scenarios: Applications using bRPC clients with health check enabled (-health_check_interval). A malicious remote peer that the client connects to can deliberately abort connections and immediately accept the health check probes, racing connection teardown against health check revival to trigger the assertion and abort the process. How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3510 Note: After applying the fix, stale input events on a Socket revived without an fd are silently dropped instead of triggering the assertion. No user-visible interface or wire protocol is changed.