CVE-2026-81755

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-81755", "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09", "state": "PUBLISHED", "assignerShortName": "apache", "dateReserved": "2026-08-27T12:21:32.957Z", "datePublished": "2026-10-21T11:58:26.104Z", "dateUpdated": "2026-10-30T14:22:06.684Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09", "shortName": "apache", "dateUpdated": "2026-10-21T11:58:26.104Z"}, "title": "Apache bRPC: Uncontrolled Resource Consumption via Excessive Streams in a Single RPC Request", "problemTypes": [{"descriptions": [{"description": "CWE-400 Uncontrolled Resource Consumption", "lang": "en", "cweId": "CWE-400", "type": "CWE"}]}], "source": {"discovery": "INTERNAL"}, "affected": [{"vendor": "Apache Software Foundation", "product": "Apache bRPC", "packageURL": "pkg:github/apache/brpc", "versions": [{"status": "affected", "version": "0", "lessThan": "1.18.0", "versionType": "semver"}], "defaultStatus": "unaffected", "collectionURL": "https://github.com", "packageName": "apache/brpc"}], "descriptions": [{"value": "Uncontrolled resource consumption in the streaming RPC component of Apache bRPC (version < 1.18.0) allows a remote attacker to exhaust server memory and cause denial of service by sending a single RPC request that declares an excessive number of streams.\n\nRoot Cause:\nIn the streaming RPC feature, a client can declare multiple streams in one RPC request by putting extra stream identifiers into the repeated field `stream_settings.extra_stream_ids` of the RPC meta. On the server side, `StreamAccept` creates one response stream for every stream identifier declared by the request, without limiting the number of streams accepted in a single RPC. The request body size is only bounded by `max_body_size` (default 64MB), which is enough to carry millions of stream identifiers. Each accepted stream allocates its own bthread execution queue and associated resources, so a single crafted request can make the server create a huge number of streams and exhaust memory, leading to denial of service.\n\nAffected Scenarios:\nUse a bRPC server that serves streaming RPC and calls `StreamAccept` to accept streams from untrusted clients.\n\nHow to Fix: \n(Choose one of the following options)\u00a0\n1. Upgrade bRPC to the 1.18.0 version.\n2. Apply this patch: https://github.com/apache/brpc/pull/3493 \n\n\nNote:\nThe fix adds a new gflag `stream_max_streams_per_request` with a default value of 64. Requests declaring more streams than the limit are rejected before any response stream is created. Applications that legitimately need to accept more than 64 streams in one RPC must raise this flag; otherwise such requests will fail after applying the fix.", "lang": "en", "supportingMedia": [{"type": "text/html", "base64": false, "value": "Uncontrolled resource consumption in the streaming RPC component of Apache bRPC (version &lt; 1.18.0) allows a remote attacker to exhaust server memory and cause denial of service by sending a single RPC request that declares an excessive number of streams.<br><br>Root Cause:<br>In the streaming RPC feature, a client can declare multiple streams in one RPC request by putting extra stream identifiers into the repeated field <span>`stream_settings.extra_stream_ids`</span> of the RPC meta. On the server side, <span>`StreamAccept`</span> creates one response stream for every stream identifier declared by the request, without limiting the number of streams accepted in a single RPC. The request body size is only bounded by <span>`max_body_size`</span> (default 64MB), which is enough to carry millions of stream identifiers. Each accepted stream allocates its own bthread execution queue and associated resources, so a single crafted request can make the server create a huge number of streams and exhaust memory, leading to denial of service.<br><br>Affected Scenarios:<br>Use a bRPC server that serves streaming RPC and calls <span>`StreamAccept`</span> to accept streams from untrusted clients.<br><br>How to Fix: <br>(<span>Choose one of the following options)&nbsp;</span><br>1. Upgrade bRPC to the 1.18.0 version.<br><span>2. Apply this patch: </span><a target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/apache/brpc/pull/3493\">https://github.com/apache/brpc/pull/3493</a>\n<br><br>Note:<br>The fix adds a new gflag <span>`stream_max_streams_per_request`</span> with a default value of 64. Requests declaring more streams than the limit are rejected before any response stream is created. Applications that legitimately need to accept more than 64 streams in one RPC must raise this flag; otherwise such requests will fail after applying the fix."}]}], "references": [{"url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb", "tags": ["vendor-advisory"]}], "metrics": [{"other": {"type": "Textual description of severity", "content": {"text": "medium"}}, "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "credits": [{"lang": "en", "value": "Claude", "type": "finder"}], "x_generator": {"engine": "Vulnogram 0.2.0"}}, "adp": [{"metrics": [{"cvssV3_1": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.5, "attackVector": "NETWORK", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "NONE", "confidentialityImpact": "NONE"}}, {"other": {"type": "ssvc", "content": {"timestamp": "2026-10-30T14:21:58.462486Z", "id": "CVE-2026-81755", "options": [{"Exploitation": "none"}, {"Automatable": "yes"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-10-30T14:22:06.684Z"}}]}}

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-81755", "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09", "state": "PUBLISHED", "assignerShortName": "apache", "dateReserved": "2026-08-27T12:21:32.957Z", "datePublished": "2026-10-21T11:58:26.104Z", "dateUpdated": "2026-10-30T14:22:06.684Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09", "shortName": "apache", "dateUpdated": "2026-10-21T11:58:26.104Z"}, "title": "Apache bRPC: Uncontrolled Resource Consumption via Excessive Streams in a Single RPC Request", "problemTypes": [{"descriptions": [{"description": "CWE-400 Uncontrolled Resource Consumption", "lang": "en", "cweId": "CWE-400", "type": "CWE"}]}], "source": {"discovery": "INTERNAL"}, "affected": [{"vendor": "Apache Software Foundation", "product": "Apache bRPC", "packageURL": "pkg:github/apache/brpc", "versions": [{"status": "affected", "version": "0", "lessThan": "1.18.0", "versionType": "semver"}], "defaultStatus": "unaffected", "collectionURL": "https://github.com", "packageName": "apache/brpc"}], "descriptions": [{"value": "Uncontrolled resource consumption in the streaming RPC component of Apache bRPC (version < 1.18.0) allows a remote attacker to exhaust server memory and cause denial of service by sending a single RPC request that declares an excessive number of streams.\n\nRoot Cause:\nIn the streaming RPC feature, a client can declare multiple streams in one RPC request by putting extra stream identifiers into the repeated field `stream_settings.extra_stream_ids` of the RPC meta. On the server side, `StreamAccept` creates one response stream for every stream identifier declared by the request, without limiting the number of streams accepted in a single RPC. The request body size is only bounded by `max_body_size` (default 64MB), which is enough to carry millions of stream identifiers. Each accepted stream allocates its own bthread execution queue and associated resources, so a single crafted request can make the server create a huge number of streams and exhaust memory, leading to denial of service.\n\nAffected Scenarios:\nUse a bRPC server that serves streaming RPC and calls `StreamAccept` to accept streams from untrusted clients.\n\nHow to Fix: \n(Choose one of the following options)\u00a0\n1. Upgrade bRPC to the 1.18.0 version.\n2. Apply this patch: https://github.com/apache/brpc/pull/3493 \n\n\nNote:\nThe fix adds a new gflag `stream_max_streams_per_request` with a default value of 64. Requests declaring more streams than the limit are rejected before any response stream is created. Applications that legitimately need to accept more than 64 streams in one RPC must raise this flag; otherwise such requests will fail after applying the fix.", "lang": "en", "supportingMedia": [{"type": "text/html", "base64": false, "value": "Uncontrolled resource consumption in the streaming RPC component of Apache bRPC (version &lt; 1.18.0) allows a remote attacker to exhaust server memory and cause denial of service by sending a single RPC request that declares an excessive number of streams.<br><br>Root Cause:<br>In the streaming RPC feature, a client can declare multiple streams in one RPC request by putting extra stream identifiers into the repeated field <span>`stream_settings.extra_stream_ids`</span> of the RPC meta. On the server side, <span>`StreamAccept`</span> creates one response stream for every stream identifier declared by the request, without limiting the number of streams accepted in a single RPC. The request body size is only bounded by <span>`max_body_size`</span> (default 64MB), which is enough to carry millions of stream identifiers. Each accepted stream allocates its own bthread execution queue and associated resources, so a single crafted request can make the server create a huge number of streams and exhaust memory, leading to denial of service.<br><br>Affected Scenarios:<br>Use a bRPC server that serves streaming RPC and calls <span>`StreamAccept`</span> to accept streams from untrusted clients.<br><br>How to Fix: <br>(<span>Choose one of the following options)&nbsp;</span><br>1. Upgrade bRPC to the 1.18.0 version.<br><span>2. Apply this patch: </span><a target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/apache/brpc/pull/3493\">https://github.com/apache/brpc/pull/3493</a>\n<br><br>Note:<br>The fix adds a new gflag <span>`stream_max_streams_per_request`</span> with a default value of 64. Requests declaring more streams than the limit are rejected before any response stream is created. Applications that legitimately need to accept more than 64 streams in one RPC must raise this flag; otherwise such requests will fail after applying the fix."}]}], "references": [{"url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb", "tags": ["vendor-advisory"]}], "metrics": [{"other": {"type": "Textual description of severity", "content": {"text": "medium"}}, "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "credits": [{"lang": "en", "value": "Claude", "type": "finder"}], "x_generator": {"engine": "Vulnogram 0.2.0"}}, "adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"cvssV3_1": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.5, "attackVector": "NETWORK", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "NONE", "confidentialityImpact": "NONE"}}, {"other": {"type": "ssvc", "content": {"id": "CVE-2026-81755", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "yes"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2026-10-30T14:21:58.462486Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-10-30T14:20:46.423Z"}}]}}

{"affected": [{"affectedData": [{"collectionURL": "https://github.com", "defaultStatus": "unaffected", "packageName": "apache/brpc", "packageURL": "pkg:github/apache/brpc", "product": "Apache bRPC", "vendor": "Apache Software Foundation", "versions": [{"lessThan": "1.18.0", "status": "affected", "version": "0", "versionType": "semver"}]}], "source": "security@apache.org"}], "cveTags": [], "descriptions": [{"lang": "en", "value": "Uncontrolled resource consumption in the streaming RPC component of Apache bRPC (version < 1.18.0) allows a remote attacker to exhaust server memory and cause denial of service by sending a single RPC request that declares an excessive number of streams.\n\nRoot Cause:\nIn the streaming RPC feature, a client can declare multiple streams in one RPC request by putting extra stream identifiers into the repeated field `stream_settings.extra_stream_ids` of the RPC meta. On the server side, `StreamAccept` creates one response stream for every stream identifier declared by the request, without limiting the number of streams accepted in a single RPC. The request body size is only bounded by `max_body_size` (default 64MB), which is enough to carry millions of stream identifiers. Each accepted stream allocates its own bthread execution queue and associated resources, so a single crafted request can make the server create a huge number of streams and exhaust memory, leading to denial of service.\n\nAffected Scenarios:\nUse a bRPC server that serves streaming RPC and calls `StreamAccept` to accept streams from untrusted clients.\n\nHow to Fix: \n(Choose one of the following options)\u00a0\n1. Upgrade bRPC to the 1.18.0 version.\n2. Apply this patch: https://github.com/apache/brpc/pull/3493 \n\n\nNote:\nThe fix adds a new gflag `stream_max_streams_per_request` with a default value of 64. Requests declaring more streams than the limit are rejected before any response stream is created. Applications that legitimately need to accept more than 64 streams in one RPC must raise this flag; otherwise such requests will fail after applying the fix."}, {"lang": "es", "value": "Consumo descontrolado de recursos en el componente de RPC de transmisi\u00f3n de Apache bRPC (versiones anteriores a la 1.18.0) permite a un atacante remoto agotar la memoria del servidor y provocar una denegaci\u00f3n de servicio enviando una \u00fanica solicitud RPC que declara un n\u00famero excesivo de flujos.\\n\\nCausa ra\u00edz:\\nEn la funcionalidad de RPC de transmisi\u00f3n, un cliente puede declarar varios flujos en una sola solicitud RPC insertando identificadores de flujo adicionales en el campo repetido \u201cstream_settings.extra_stream_ids\u201d de los metadatos RPC. En el lado del servidor, \u201cStreamAccept\u201d crea un flujo de respuesta por cada identificador de flujo declarado en la solicitud, sin limitar la cantidad de flujos aceptados en una \u00fanica RPC. El tama\u00f1o del cuerpo de la solicitud solo est\u00e1 limitado por \u201cmax_body_size\u201d (valor predeterminado 64?MB), lo cual es suficiente para transportar millones de identificadores de flujo. Cada flujo aceptado asigna su propia cola de ejecuci\u00f3n bthread y los recursos asociados, de modo que una sola solicitud manipulada puede hacer que el servidor cree una gran cantidad de flujos y agote la memoria, provocando una denegaci\u00f3n de servicio.\\n\\nEscenarios afectados:\\nUtilizar un servidor bRPC que ofrezca RPC de transmisi\u00f3n y llame a \u201cStreamAccept\u201d para aceptar flujos de clientes no confiables.\\n\\nC\u00f3mo corregir:\\n(Elija una de las siguientes opciones) \\n1. Actualice bRPC a la versi\u00f3n 1.18.0. \\n2. Aplique este parche: https://github.com/apache/brpc/pull/3493 \\n\\nNota:\\nLa correcci\u00f3n a\u00f1ade una nueva gflag \u201cstream_max_streams_per_request\u201d con un valor predeterminado de 64. Las solicitudes que declaren m\u00e1s flujos que el l\u00edmite son rechazadas antes de que se cree cualquier flujo de respuesta. Las aplicaciones que necesiten aceptar leg\u00edtimamente m\u00e1s de 64 flujos en una sola RPC deben aumentar esta bandera; de lo contrario, esas solicitudes fallar\u00e1n tras aplicar la correcci\u00f3n."}], "id": "CVE-2026-81755", "lastModified": "2026-10-30T15:16:55.300", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 7.5, "baseSeverity": "HIGH", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 3.9, "impactScore": 3.6, "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "type": "Secondary"}], "ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-81755", "options": [{"exploitation": "none"}, {"automatable": "yes"}, {"technicalImpact": "partial"}], "role": "CISA Coordinator", "timestamp": "2026-10-30T14:21:58.462486Z", "version": "2.0.3"}}]}, "published": "2026-10-21T12:17:24.283", "references": [{"source": "security@apache.org", "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"}], "sourceIdentifier": "security@apache.org", "vulnStatus": "Deferred", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-400"}], "source": "security@apache.org", "type": "Secondary"}]}

{}

{"affected": [{"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "semver", "value": "[0,1.18.0)"}}], "enrichment": {"confidence": 100.0, "confidence_source": "manual", "scores": [{"score": 100.0, "source": "manual"}]}, "original": {"product": "Apache bRPC", "source": "cna", "vendor": "Apache Software Foundation"}, "product": "brpc", "vendor": "apache"}], "created": "2026-10-21T18:30:14.170104+00:00", "updated": "2026-10-30T17:00:20.548132+00:00", "vendors": ["apache", "apache$PRODUCT$brpc"]}