CVE-2025-54472 (GCVE-0-2025-54472)
Vulnerability from cvelistv5
Published
2025-08-14 09:05
Modified
2025-08-14 14:49
Severity ?
CWE
  • CWE-400 - Uncontrolled Resource Consumption
  • CWE-190 - Integer Overflow or Wraparound
Summary
Unlimited memory allocation in redis protocol parser in Apache bRPC (all versions < 1.14.1) on all platforms allows attackers to crash the service via network. Root Cause: In the bRPC Redis protocol parser code, memory for arrays or strings of corresponding sizes is allocated based on the integers read from the network. If the integer read from the network is too large, it may cause a bad alloc error and lead to the program crashing. Attackers can exploit this feature by sending special data packets to the bRPC service to carry out a denial-of-service attack on it. The bRPC 1.14.0 version tried to fix this issue by limited the memory allocation size, however, the limitation checking code is not well implemented that may cause integer overflow and evade such limitation. So the 1.14.0 version is also vulnerable, although the integer range that affect version 1.14.0 is different from that affect version < 1.14.0. Affected scenarios: Using bRPC as a Redis server to provide network services to untrusted clients, or using bRPC as a Redis client to call untrusted Redis services. How to Fix: we provide two methods, you can choose one of them: 1. Upgrade bRPC to version 1.14.1. 2. Apply this patch ( https://github.com/apache/brpc/pull/3050 ) manually. No matter you choose which method, you should note that the patch limits the maximum length of memory allocated for each time in the bRPC Redis parser. The default limit is 64M. If some of you redis request or response have a size larger than 64M, you might encounter error after upgrade. For such case, you can modify the gflag redis_max_allocation_size to set a larger limit.
References
Impacted products
Show details on NVD website


{
  "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-2025-54472",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-08-14T13:37:18.746439Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-08-14T14:49:23.869Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Apache bRPC",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "1.14.1",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Tyler Zars"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Unlimited memory allocation in redis protocol parser in Apache bRPC (all versions \u0026lt; 1.14.1) on all platforms allows attackers to crash the service via network.\u003cbr\u003e\u003cbr\u003e\n\n\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eRoot Cause: In the bRPC Redis protocol parser code, memory for arrays or strings of corresponding sizes is allocated based on the integers read from the network. If the integer read from the network is too large, it may cause a bad alloc error and lead to the program crashing. Attackers can exploit this feature by sending special data packets to the bRPC service to carry out a denial-of-service attack on it.\u003cbr\u003e\u003c/span\u003eThe bRPC 1.14.0 version tried to fix this issue by limited the memory allocation size, however, the limitation checking code is not well implemented that may cause integer overflow and evade such limitation. So the\u0026nbsp;1.14.0 version is also vulnerable, although the integer range that affect version 1.14.0 is different from that affect version \u0026lt; 1.14.0.\u003cbr\u003e\u003cbr\u003e\n\n\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eAffected scenarios: Using bRPC as a Redis server to provide network services to untrusted clients, or using bRPC as a Redis client to call untrusted Redis services.\u003c/span\u003e\n\n\u003cbr\u003e\u003cbr\u003eHow to Fix: we provide two methods, you can choose one of them:\u003cbr\u003e\u003cbr\u003e1. Upgrade bRPC to version 1.14.1.\u003cbr\u003e2. Apply this patch (\u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/apache/brpc/pull/3050\"\u003ehttps://github.com/apache/brpc/pull/3050\u003c/a\u003e) manually.\u003cbr\u003e\u003cbr\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eNo matter you choose which method, you should note that the patch limits the maximum length of memory allocated for each time in the bRPC Redis parser. The default limit is 64M. If some of you redis request or response have a size larger than 64M, you might encounter error after upgrade. For such case, you can modify the gflag\u0026nbsp;\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eredis_max_allocation_size to set a larger limit.\u003c/span\u003e\u003c/span\u003e\u003cbr\u003e\u003cbr\u003e"
            }
          ],
          "value": "Unlimited memory allocation in redis protocol parser in Apache bRPC (all versions \u003c 1.14.1) on all platforms allows attackers to crash the service via network.\n\n\n\nRoot Cause: In the bRPC Redis protocol parser code, memory for arrays or strings of corresponding sizes is allocated based on the integers read from the network. If the integer read from the network is too large, it may cause a bad alloc error and lead to the program crashing. Attackers can exploit this feature by sending special data packets to the bRPC service to carry out a denial-of-service attack on it.\nThe bRPC 1.14.0 version tried to fix this issue by limited the memory allocation size, however, the limitation checking code is not well implemented that may cause integer overflow and evade such limitation. So the\u00a01.14.0 version is also vulnerable, although the integer range that affect version 1.14.0 is different from that affect version \u003c 1.14.0.\n\n\n\nAffected scenarios: Using bRPC as a Redis server to provide network services to untrusted clients, or using bRPC as a Redis client to call untrusted Redis services.\n\n\n\nHow to Fix: we provide two methods, you can choose one of them:\n\n1. Upgrade bRPC to version 1.14.1.\n2. Apply this patch ( https://github.com/apache/brpc/pull/3050 ) manually.\n\nNo matter you choose which method, you should note that the patch limits the maximum length of memory allocated for each time in the bRPC Redis parser. The default limit is 64M. If some of you redis request or response have a size larger than 64M, you might encounter error after upgrade. For such case, you can modify the gflag\u00a0redis_max_allocation_size to set a larger limit."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400 Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-190",
              "description": "CWE-190 Integer Overflow or Wraparound",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-08-14T09:05:38.944Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/r3xsy3wvs4kmfhc281173k5b6ll1xt2m"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache bRPC: Redis Parser Remote Denial of Service",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2025-54472",
    "datePublished": "2025-08-14T09:05:38.944Z",
    "dateReserved": "2025-07-23T09:19:43.081Z",
    "dateUpdated": "2025-08-14T14:49:23.869Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-54472\",\"sourceIdentifier\":\"security@apache.org\",\"published\":\"2025-08-14T09:15:26.683\",\"lastModified\":\"2025-08-18T18:35:46.417\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"Unlimited memory allocation in redis protocol parser in Apache bRPC (all versions \u003c 1.14.1) on all platforms allows attackers to crash the service via network.\\n\\n\\n\\nRoot Cause: In the bRPC Redis protocol parser code, memory for arrays or strings of corresponding sizes is allocated based on the integers read from the network. If the integer read from the network is too large, it may cause a bad alloc error and lead to the program crashing. Attackers can exploit this feature by sending special data packets to the bRPC service to carry out a denial-of-service attack on it.\\nThe bRPC 1.14.0 version tried to fix this issue by limited the memory allocation size, however, the limitation checking code is not well implemented that may cause integer overflow and evade such limitation. So the\u00a01.14.0 version is also vulnerable, although the integer range that affect version 1.14.0 is different from that affect version \u003c 1.14.0.\\n\\n\\n\\nAffected scenarios: Using bRPC as a Redis server to provide network services to untrusted clients, or using bRPC as a Redis client to call untrusted Redis services.\\n\\n\\n\\nHow to Fix: we provide two methods, you can choose one of them:\\n\\n1. Upgrade bRPC to version 1.14.1.\\n2. Apply this patch ( https://github.com/apache/brpc/pull/3050 ) manually.\\n\\nNo matter you choose which method, you should note that the patch limits the maximum length of memory allocated for each time in the bRPC Redis parser. The default limit is 64M. If some of you redis request or response have a size larger than 64M, you might encounter error after upgrade. For such case, you can modify the gflag\u00a0redis_max_allocation_size to set a larger limit.\"},{\"lang\":\"es\",\"value\":\"La asignaci\u00f3n ilimitada de memoria en el analizador de protocolo Redis de Apache bRPC (todas las versiones anteriores a la 1.14.1) en todas las plataformas permite a los atacantes bloquear el servicio a trav\u00e9s de la red. Causa ra\u00edz: En el c\u00f3digo del analizador de protocolo Redis de bRPC, la memoria para matrices o cadenas de tama\u00f1os correspondientes se asigna en funci\u00f3n de los enteros le\u00eddos de la red. Si el entero le\u00eddo de la red es demasiado grande, puede causar un error de asignaci\u00f3n incorrecta y provocar el bloqueo del programa. Los atacantes pueden explotar esta caracter\u00edstica enviando paquetes de datos especiales al servicio bRPC para llevar a cabo un ataque de denegaci\u00f3n de servicio. La versi\u00f3n bRPC 1.14.0 intent\u00f3 solucionar este problema limitando el tama\u00f1o de la asignaci\u00f3n de memoria; sin embargo, el c\u00f3digo de comprobaci\u00f3n de limitaciones no est\u00e1 bien implementado, lo que puede causar un desbordamiento de enteros y evadir dicha limitaci\u00f3n. Por lo tanto, la versi\u00f3n 1.14.0 tambi\u00e9n es vulnerable, aunque el rango de enteros que afecta a la versi\u00f3n 1.14.0 es diferente al que afecta a la versi\u00f3n anterior. Escenarios afectados: Usar bRPC como servidor Redis para proporcionar servicios de red a clientes no confiables, o usar bRPC como cliente Redis para llamar a servicios Redis no confiables. C\u00f3mo solucionarlo: ofrecemos dos m\u00e9todos, puede elegir uno de ellos: 1. Actualice bRPC a la versi\u00f3n 1.14.1. 2. Aplique este parche (https://github.com/apache/brpc/pull/3050) manualmente. Independientemente del m\u00e9todo que elija, debe tener en cuenta que el parche limita la longitud m\u00e1xima de memoria asignada para cada vez en el analizador Redis de bRPC. El l\u00edmite predeterminado es 64M. Si alguna de sus solicitudes o respuestas de Redis tiene un tama\u00f1o mayor a 64M, podr\u00eda encontrar un error despu\u00e9s de la actualizaci\u00f3n. Para tal caso, puede modificar el gflag redis_max_allocation_size para establecer un l\u00edmite mayor.\"}],\"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}]},\"weaknesses\":[{\"source\":\"security@apache.org\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-190\"},{\"lang\":\"en\",\"value\":\"CWE-400\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:apache:brpc:*:*:*:*:*:*:*:*\",\"versionEndExcluding\":\"1.14.1\",\"matchCriteriaId\":\"6ACE2C20-D9A0-4BD4-A011-F61D65B8FBC0\"}]}]}],\"references\":[{\"url\":\"https://lists.apache.org/thread/r3xsy3wvs4kmfhc281173k5b6ll1xt2m\",\"source\":\"security@apache.org\",\"tags\":[\"Mailing List\",\"Vendor Advisory\",\"Patch\"]}]}}",
    "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-2025-54472\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"yes\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-08-14T13:37:18.746439Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-08-14T13:37:22.283Z\"}}], \"cna\": {\"title\": \"Apache bRPC: Redis Parser Remote Denial of Service\", \"source\": {\"discovery\": \"EXTERNAL\"}, \"credits\": [{\"lang\": \"en\", \"type\": \"reporter\", \"value\": \"Tyler Zars\"}], \"metrics\": [{\"other\": {\"type\": \"Textual description of severity\", \"content\": {\"text\": \"important\"}}}], \"affected\": [{\"vendor\": \"Apache Software Foundation\", \"product\": \"Apache bRPC\", \"versions\": [{\"status\": \"affected\", \"version\": \"0\", \"lessThan\": \"1.14.1\", \"versionType\": \"semver\"}], \"defaultStatus\": \"unaffected\"}], \"references\": [{\"url\": \"https://lists.apache.org/thread/r3xsy3wvs4kmfhc281173k5b6ll1xt2m\", \"tags\": [\"vendor-advisory\"]}], \"x_generator\": {\"engine\": \"Vulnogram 0.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"Unlimited memory allocation in redis protocol parser in Apache bRPC (all versions \u003c 1.14.1) on all platforms allows attackers to crash the service via network.\\n\\n\\n\\nRoot Cause: In the bRPC Redis protocol parser code, memory for arrays or strings of corresponding sizes is allocated based on the integers read from the network. If the integer read from the network is too large, it may cause a bad alloc error and lead to the program crashing. Attackers can exploit this feature by sending special data packets to the bRPC service to carry out a denial-of-service attack on it.\\nThe bRPC 1.14.0 version tried to fix this issue by limited the memory allocation size, however, the limitation checking code is not well implemented that may cause integer overflow and evade such limitation. So the\\u00a01.14.0 version is also vulnerable, although the integer range that affect version 1.14.0 is different from that affect version \u003c 1.14.0.\\n\\n\\n\\nAffected scenarios: Using bRPC as a Redis server to provide network services to untrusted clients, or using bRPC as a Redis client to call untrusted Redis services.\\n\\n\\n\\nHow to Fix: we provide two methods, you can choose one of them:\\n\\n1. Upgrade bRPC to version 1.14.1.\\n2. Apply this patch ( https://github.com/apache/brpc/pull/3050 ) manually.\\n\\nNo matter you choose which method, you should note that the patch limits the maximum length of memory allocated for each time in the bRPC Redis parser. The default limit is 64M. If some of you redis request or response have a size larger than 64M, you might encounter error after upgrade. For such case, you can modify the gflag\\u00a0redis_max_allocation_size to set a larger limit.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"Unlimited memory allocation in redis protocol parser in Apache bRPC (all versions \u0026lt; 1.14.1) on all platforms allows attackers to crash the service via network.\u003cbr\u003e\u003cbr\u003e\\n\\n\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003eRoot Cause: In the bRPC Redis protocol parser code, memory for arrays or strings of corresponding sizes is allocated based on the integers read from the network. If the integer read from the network is too large, it may cause a bad alloc error and lead to the program crashing. Attackers can exploit this feature by sending special data packets to the bRPC service to carry out a denial-of-service attack on it.\u003cbr\u003e\u003c/span\u003eThe bRPC 1.14.0 version tried to fix this issue by limited the memory allocation size, however, the limitation checking code is not well implemented that may cause integer overflow and evade such limitation. So the\u0026nbsp;1.14.0 version is also vulnerable, although the integer range that affect version 1.14.0 is different from that affect version \u0026lt; 1.14.0.\u003cbr\u003e\u003cbr\u003e\\n\\n\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003eAffected scenarios: Using bRPC as a Redis server to provide network services to untrusted clients, or using bRPC as a Redis client to call untrusted Redis services.\u003c/span\u003e\\n\\n\u003cbr\u003e\u003cbr\u003eHow to Fix: we provide two methods, you can choose one of them:\u003cbr\u003e\u003cbr\u003e1. Upgrade bRPC to version 1.14.1.\u003cbr\u003e2. Apply this patch (\u003ca target=\\\"_blank\\\" rel=\\\"nofollow\\\" href=\\\"https://github.com/apache/brpc/pull/3050\\\"\u003ehttps://github.com/apache/brpc/pull/3050\u003c/a\u003e) manually.\u003cbr\u003e\u003cbr\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003eNo matter you choose which method, you should note that the patch limits the maximum length of memory allocated for each time in the bRPC Redis parser. The default limit is 64M. If some of you redis request or response have a size larger than 64M, you might encounter error after upgrade. For such case, you can modify the gflag\u0026nbsp;\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003eredis_max_allocation_size to set a larger limit.\u003c/span\u003e\u003c/span\u003e\u003cbr\u003e\u003cbr\u003e\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-400\", \"description\": \"CWE-400 Uncontrolled Resource Consumption\"}]}, {\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-190\", \"description\": \"CWE-190 Integer Overflow or Wraparound\"}]}], \"providerMetadata\": {\"orgId\": \"f0158376-9dc2-43b6-827c-5f631a4d8d09\", \"shortName\": \"apache\", \"dateUpdated\": \"2025-08-14T09:05:38.944Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2025-54472\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-08-14T14:49:23.869Z\", \"dateReserved\": \"2025-07-23T09:19:43.081Z\", \"assignerOrgId\": \"f0158376-9dc2-43b6-827c-5f631a4d8d09\", \"datePublished\": \"2025-08-14T09:05:38.944Z\", \"assignerShortName\": \"apache\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…