{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "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"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-80463",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-30T14:18:23.768608Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-30T14:18:35.910Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "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"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Claude"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Unbounded memory accumulation in the stream message reassembly path of Apache bRPC (version \u0026lt; 1.18.0) on all platforms allows remote attackers to exhaust the memory of a server (denial of service) by sending an endless sequence of continuation data frames.\u003cbr\u003e\u003cbr\u003eRoot Cause:\u003cbr\u003eThe streaming RPC protocol bounds every single data frame by max_body_size, but a fragmented stream message accumulates continuation frames into one buffer (_pending_buf) without any limit on the accumulated size. A malicious peer that can open a stream can therefore keep sending continuation frames to make the receiver accumulate an arbitrarily large in-memory message. Since the default flow-control settings (socket_max_streams_unconsumed_bytes=0) do not throttle the sending rate, the receiver\u0027s memory grows until the process runs out of memory and crashes or becomes unavailable.\u003cbr\u003e\u003cbr\u003eAffected Scenarios:\u003cbr\u003eServices that accept streams from untrusted clients (for example using brpc::StreamAccept or brpc::StreamCreate with the built-in streaming protocol) are affected.\u003cbr\u003e\u003cbr\u003e\u003cbr\u003eHow to Fix:\u003cbr\u003e(Choose one of the following options)\u003cbr\u003e1. Upgrade bRPC to version 1.18.0, which fixes this issue.\u003cbr\u003e2. Apply this patch: \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/apache/brpc/pull/3489\"\u003ehttps://github.com/apache/brpc/pull/3489\u003c/a\u003e\u003cbr\u003e\u003cbr\u003e\u003cbr\u003eNote:\u003cbr\u003eThe fix limits the accumulated payload of a fragmented stream message to max_body_size (default 64MB). When the accumulated payload exceeds the limit, the pending fragments are released and the stream is closed with error EMSGSIZE. After applying the fix, legitimate fragmented stream messages larger than max_body_size will be rejected; you can adjust the gflag max_body_size to change the limit."
            }
          ],
          "value": "Unbounded memory accumulation in the stream message reassembly path of Apache bRPC (version \u003c 1.18.0) on all platforms allows remote attackers to exhaust the memory of a server (denial of service) by sending an endless sequence of continuation data frames.\n\nRoot Cause:\nThe streaming RPC protocol bounds every single data frame by max_body_size, but a fragmented stream message accumulates continuation frames into one buffer (_pending_buf) without any limit on the accumulated size. A malicious peer that can open a stream can therefore keep sending continuation frames to make the receiver accumulate an arbitrarily large in-memory message. Since the default flow-control settings (socket_max_streams_unconsumed_bytes=0) do not throttle the sending rate, the receiver\u0027s memory grows until the process runs out of memory and crashes or becomes unavailable.\n\nAffected Scenarios:\nServices that accept streams from untrusted clients (for example using brpc::StreamAccept or brpc::StreamCreate with the built-in streaming protocol) are affected.\n\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/3489 \n\n\nNote:\nThe fix limits the accumulated payload of a fragmented stream message to max_body_size (default 64MB). When the accumulated payload exceeds the limit, the pending fragments are released and the stream is closed with error EMSGSIZE. After applying the fix, legitimate fragmented stream messages larger than max_body_size will be rejected; you can adjust the gflag max_body_size to change the limit."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "medium"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770 Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-21T11:57:30.211Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "Apache bRPC: Unbounded Memory Accumulation in Stream Message Reassembly",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-80463",
    "datePublished": "2026-10-21T11:57:30.211Z",
    "dateReserved": "2026-08-26T12:29:39.167Z",
    "dateUpdated": "2026-10-30T14:18:35.910Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "vulnrichment": {
      "containers": "{\"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-80463\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"yes\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-10-30T14:18:23.768608Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-10-30T14:17:48.441Z\"}}], \"cna\": {\"title\": \"Apache bRPC: Unbounded Memory Accumulation in Stream Message Reassembly\", \"source\": {\"discovery\": \"INTERNAL\"}, \"credits\": [{\"lang\": \"en\", \"type\": \"finder\", \"value\": \"Claude\"}], \"metrics\": [{\"other\": {\"type\": \"Textual description of severity\", \"content\": {\"text\": \"medium\"}}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}], \"affected\": [{\"vendor\": \"Apache Software Foundation\", \"product\": \"Apache bRPC\", \"versions\": [{\"status\": \"affected\", \"version\": \"0\", \"lessThan\": \"1.18.0\", \"versionType\": \"semver\"}], \"packageURL\": \"pkg:github/apache/brpc\", \"packageName\": \"apache/brpc\", \"collectionURL\": \"https://github.com\", \"defaultStatus\": \"unaffected\"}], \"references\": [{\"url\": \"https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb\", \"tags\": [\"vendor-advisory\"]}], \"x_generator\": {\"engine\": \"Vulnogram 0.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"Unbounded memory accumulation in the stream message reassembly path of Apache bRPC (version \u003c 1.18.0) on all platforms allows remote attackers to exhaust the memory of a server (denial of service) by sending an endless sequence of continuation data frames.\\n\\nRoot Cause:\\nThe streaming RPC protocol bounds every single data frame by max_body_size, but a fragmented stream message accumulates continuation frames into one buffer (_pending_buf) without any limit on the accumulated size. A malicious peer that can open a stream can therefore keep sending continuation frames to make the receiver accumulate an arbitrarily large in-memory message. Since the default flow-control settings (socket_max_streams_unconsumed_bytes=0) do not throttle the sending rate, the receiver\u0027s memory grows until the process runs out of memory and crashes or becomes unavailable.\\n\\nAffected Scenarios:\\nServices that accept streams from untrusted clients (for example using brpc::StreamAccept or brpc::StreamCreate with the built-in streaming protocol) are affected.\\n\\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/3489 \\n\\n\\nNote:\\nThe fix limits the accumulated payload of a fragmented stream message to max_body_size (default 64MB). When the accumulated payload exceeds the limit, the pending fragments are released and the stream is closed with error EMSGSIZE. After applying the fix, legitimate fragmented stream messages larger than max_body_size will be rejected; you can adjust the gflag max_body_size to change the limit.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"Unbounded memory accumulation in the stream message reassembly path of Apache bRPC (version \u0026lt; 1.18.0) on all platforms allows remote attackers to exhaust the memory of a server (denial of service) by sending an endless sequence of continuation data frames.\u003cbr\u003e\u003cbr\u003eRoot Cause:\u003cbr\u003eThe streaming RPC protocol bounds every single data frame by max_body_size, but a fragmented stream message accumulates continuation frames into one buffer (_pending_buf) without any limit on the accumulated size. A malicious peer that can open a stream can therefore keep sending continuation frames to make the receiver accumulate an arbitrarily large in-memory message. Since the default flow-control settings (socket_max_streams_unconsumed_bytes=0) do not throttle the sending rate, the receiver\u0027s memory grows until the process runs out of memory and crashes or becomes unavailable.\u003cbr\u003e\u003cbr\u003eAffected Scenarios:\u003cbr\u003eServices that accept streams from untrusted clients (for example using brpc::StreamAccept or brpc::StreamCreate with the built-in streaming protocol) are affected.\u003cbr\u003e\u003cbr\u003e\u003cbr\u003eHow to Fix:\u003cbr\u003e(Choose one of the following options)\u003cbr\u003e1. Upgrade bRPC to version 1.18.0, which fixes this issue.\u003cbr\u003e2. Apply this patch: \u003ca target=\\\"_blank\\\" rel=\\\"nofollow\\\" href=\\\"https://github.com/apache/brpc/pull/3489\\\"\u003ehttps://github.com/apache/brpc/pull/3489\u003c/a\u003e\u003cbr\u003e\u003cbr\u003e\u003cbr\u003eNote:\u003cbr\u003eThe fix limits the accumulated payload of a fragmented stream message to max_body_size (default 64MB). When the accumulated payload exceeds the limit, the pending fragments are released and the stream is closed with error EMSGSIZE. After applying the fix, legitimate fragmented stream messages larger than max_body_size will be rejected; you can adjust the gflag max_body_size to change the limit.\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-770\", \"description\": \"CWE-770 Allocation of Resources Without Limits or Throttling\"}]}], \"providerMetadata\": {\"orgId\": \"f0158376-9dc2-43b6-827c-5f631a4d8d09\", \"shortName\": \"apache\", \"dateUpdated\": \"2026-10-21T11:57:30.211Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-80463\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-10-30T14:18:35.910Z\", \"dateReserved\": \"2026-08-26T12:29:39.167Z\", \"assignerOrgId\": \"f0158376-9dc2-43b6-827c-5f631a4d8d09\", \"datePublished\": \"2026-10-21T11:57:30.211Z\", \"assignerShortName\": \"apache\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}