CVE-2026-81755

{
  "id": "CVE-2026-81755",
  "sourceIdentifier": "[email protected]",
  "published": "2026-10-21T12:17:24.283",
  "lastModified": "2026-10-30T15:16:55.300",
  "vulnStatus": "Deferred",
  "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) \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ón de Apache bRPC (versiones anteriores a la 1.18.0) permite a un atacante remoto agotar la memoria del servidor y provocar una denegación de servicio enviando una única solicitud RPC que declara un número excesivo de flujos.\\n\\nCausa raíz:\\nEn la funcionalidad de RPC de transmisión, un cliente puede declarar varios flujos en una sola solicitud RPC insertando identificadores de flujo adicionales en el campo repetido “stream_settings.extra_stream_ids” de los metadatos RPC. En el lado del servidor, “StreamAccept” crea un flujo de respuesta por cada identificador de flujo declarado en la solicitud, sin limitar la cantidad de flujos aceptados en una única RPC. El tamaño del cuerpo de la solicitud solo está limitado por “max_body_size” (valor predeterminado 64?MB), lo cual es suficiente para transportar millones de identificadores de flujo. Cada flujo aceptado asigna su propia cola de ejecución 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ón de servicio.\\n\\nEscenarios afectados:\\nUtilizar un servidor bRPC que ofrezca RPC de transmisión y llame a “StreamAccept” para aceptar flujos de clientes no confiables.\\n\\nCómo corregir:\\n(Elija una de las siguientes opciones)  \\n1. Actualice bRPC a la versión 1.18.0.  \\n2. Aplique este parche: https://github.com/apache/brpc/pull/3493  \\n\\nNota:\\nLa corrección añade una nueva gflag “stream_max_streams_per_request” con un valor predeterminado de 64. Las solicitudes que declaren más flujos que el límite son rechazadas antes de que se cree cualquier flujo de respuesta. Las aplicaciones que necesiten aceptar legítimamente más de 64 flujos en una sola RPC deben aumentar esta bandera; de lo contrario, esas solicitudes fallarán tras aplicar la corrección."
    }
  ],
  "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": {
    "cvssMetricV31": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary",
        "cvssData": {
          "version": "3.1",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
          "baseScore": 7.5,
          "baseSeverity": "HIGH",
          "attackVector": "NETWORK",
          "attackComplexity": "LOW",
          "privilegesRequired": "NONE",
          "userInteraction": "NONE",
          "scope": "UNCHANGED",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "availabilityImpact": "HIGH"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 3.6
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "timestamp": "2026-10-30T14:21:58.462486Z",
          "id": "CVE-2026-81755",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "version": "2.0.3"
        }
      }
    ]
  },
  "weaknesses": [
    {
      "source": "[email protected]",
      "type": "Secondary",
      "description": [
        {
          "lang": "en",
          "value": "CWE-400"
        }
      ]
    }
  ],
  "references": [
    {
      "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb",
      "source": "[email protected]"
    }
  ]
}