CVE-2026-82425
Full vulnerability record from the local CVENow database.
Description
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.
View original CVE JSON
{
"id": "CVE-2026-82425",
"sourceIdentifier": "[email protected]",
"published": "2026-10-21T13:20:03.247",
"lastModified": "2026-10-26T21:10:00.170",
"vulnStatus": "Deferred",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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.\n\nRoot Cause:\nWhen 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).\n\nAffected Scenarios:\nApplications 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.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3510 \n\nNote:\nAfter 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."
},
{
"lang": "es",
"value": "Una aserción alcanzable en Apache bRPC (versiones anteriores a la 1.18.0) en todas las plataformas permite que un par remoto malicioso provoque el bloqueo del proceso, lo que resulta en una denegación de servicio.\\n\\nCausa raíz:\\nCuando un Socket con comprobación de salud habilitada falla, Socket::WaitAndReset cierra su descriptor de archivo mientras el despachador de eventos aún puede estar entregando un evento de entrada (EPOLLIN/EVFILT_READ) que se obtuvo para el descriptor recién cerrado. Si la comprobación de salud entonces tiene éxito y revive el Socket, Socket::Address vuelve a tener éxito mientras el descriptor sigue siendo -1 (la siguiente escritura vuelve a conectar bajo demanda). En esa ventana, Socket::OnInputEvent ejecuta CHECK(!(events & EPOLLIN)) (o el equivalente kqueue) porque el Socket es direccionable pero no tiene descriptor. Las fallas de CHECK terminan el proceso cuando bRPC se compila con glog o cuando la gflag -crash_on_fatal_log está habilitada (CHECK siempre termina en compilaciones OFFICIAL_BUILD/NDEBUG también).\\n\\nEscenarios afectados:\\nAplicaciones que usan clientes bRPC con la comprobación de salud habilitada (-health_check_interval). Un par remoto malicioso al que el cliente se conecta puede abortar deliberadamente las conexiones y aceptar inmediatamente las sondas de comprobación de salud, compitiendo el desmontaje de la conexión contra la reactivación de la comprobación de salud para desencadenar la aserción y abortar el proceso.\\n\\nCómo corregir:\\n(Elija una de las siguientes opciones)\\n1. Actualice bRPC a la versión 1.18.0, que corrige este problema.\\n2. Aplique este parche: https://github.com/apache/brpc/pull/3510\\n\\nNota:\\nDespués de aplicar la corrección, los eventos de entrada obsoletos en un Socket revivido sin descriptor se descartan silenciosamente en lugar de activar la aserción. No se modifica ninguna interfaz visible para el usuario ni el protocolo de red."
}
],
"affected": [
{
"source": "[email protected]",
"affectedData": [
{
"vendor": "Apache Software Foundation",
"product": "Apache bRPC",
"defaultStatus": "unaffected",
"collectionURL": "https://github.com",
"packageName": "apache/brpc",
"packageURL": "pkg:github/apache/brpc",
"versions": [
{
"version": "0",
"lessThan": "1.18.0",
"versionType": "semver",
"status": "affected"
}
]
}
]
}
],
"metrics": {},
"weaknesses": [
{
"source": "[email protected]",
"type": "Primary",
"description": [
{
"lang": "en",
"value": "CWE-617"
}
]
}
],
"references": [
{
"url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb",
"source": "[email protected]"
}
]
}