The MySQL client response parser in Apache bRPC dereferences a null pointer when the server peer sends a zero-payload-length response packet. A response packet whose declared payload length is zero is accepted by the frame-length check (is_full_package), after which the parser reads the response type byte via an unbounded 5-byte fetch that returns nullptr, and type = p[4] dereferences it, crashing the client process.
Root Cause: In brpc::policy::MysqlReply::ConsumePartialIOBuf, buf.fetch(header, 5) returns nullptr when the buffered data only holds the 4-byte header of a zero-length packet, then the code reads p[4] (and, in the fast-auth path, p2[4]) without checking for a null or zero-length packet.
Affected Scenarios: A brpc MySQL client connecting to a malicious or compromised MySQL server (or a MITM) can be crashed by a zero-length server response packet, resulting in denial of service of the client.
Fix: The fix rejects zero-length response packets (returning PARSE_ERROR_ABSOLUTELY_WRONG) both for the initial response type determination and after a fast-auth marker, before reading the type byte. Upgrade to the Apache bRPC version 1.18.0 or apply the PR patch at https://github.com/apache/brpc/pull/3536.
"}],"value":"The MySQL client response parser in Apache bRPC dereferences a null pointer when the server peer sends a zero-payload-length response packet. A response packet whose declared payload length is zero is accepted by the frame-length check (is_full_package), after which the parser reads the response type byte via an unbounded 5-byte fetch that returns nullptr, and type = p[4] dereferences it, crashing the client process.\n\n\n\nRoot Cause: In brpc::policy::MysqlReply::ConsumePartialIOBuf, buf.fetch(header, 5) returns nullptr when the buffered data only holds the 4-byte header of a zero-length packet, then the code reads p[4] (and, in the fast-auth path, p2[4]) without checking for a null or zero-length packet.\n\n\n\nAffected Scenarios: A brpc MySQL client connecting to a malicious or compromised MySQL server (or a MITM) can be crashed by a zero-length server response packet, resulting in denial of service of the client.\n\n\n\nFix: The fix rejects zero-length response packets (returning PARSE_ERROR_ABSOLUTELY_WRONG) both for the initial response type determination and after a fast-auth marker, before reading the type byte. Upgrade to the Apache bRPC version 1.18.0 or apply the PR patch at https://github.com/apache/brpc/pull/3536."}],"metrics":[{"other":{"content":{"text":"moderate"},"type":"Textual description of severity"},"scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-476","description":"CWE-476 NULL Pointer Dereference","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-21T12:19:37.796Z","orgId":"f0158376-9dc2-43b6-827c-5f631a4d8d09","shortName":"apache"},"references":[{"name":"PR 3536","url":"https://github.com/apache/brpc/pull/3536"},{"tags":["vendor-advisory"],"url":"https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"}],"source":{"discovery":"INTERNAL"},"title":"Apache bRPC: Null pointer dereference in MySQL reply parser leading to client crash","x_generator":{"engine":"Vulnogram 0.2.0"}}},"cveMetadata":{"assignerOrgId":"f0158376-9dc2-43b6-827c-5f631a4d8d09","assignerShortName":"apache","cveId":"CVE-2026-90484","datePublished":"2026-10-21T12:19:37.796Z","dateReserved":"2026-09-12T04:06:06.138Z","dateUpdated":"2026-10-21T12:19:37.796Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-21 13:20:56","lastModifiedDate":"2026-10-21 13:20:56","problem_types":["CWE-476","CWE-476 CWE-476 NULL Pointer Dereference"],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"90484","Ordinal":"1","Title":"Apache bRPC: Null pointer dereference in MySQL reply parser lead","CVE":"CVE-2026-90484","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"90484","Ordinal":"1","NoteData":"The MySQL client response parser in Apache bRPC dereferences a null pointer when the server peer sends a zero-payload-length response packet. A response packet whose declared payload length is zero is accepted by the frame-length check (is_full_package), after which the parser reads the response type byte via an unbounded 5-byte fetch that returns nullptr, and type = p[4] dereferences it, crashing the client process.\n\n\n\nRoot Cause: In brpc::policy::MysqlReply::ConsumePartialIOBuf, buf.fetch(header, 5) returns nullptr when the buffered data only holds the 4-byte header of a zero-length packet, then the code reads p[4] (and, in the fast-auth path, p2[4]) without checking for a null or zero-length packet.\n\n\n\nAffected Scenarios: A brpc MySQL client connecting to a malicious or compromised MySQL server (or a MITM) can be crashed by a zero-length server response packet, resulting in denial of service of the client.\n\n\n\nFix: The fix rejects zero-length response packets (returning PARSE_ERROR_ABSOLUTELY_WRONG) both for the initial response type determination and after a fast-auth marker, before reading the type byte. Upgrade to the Apache bRPC version 1.18.0 or apply the PR patch at https://github.com/apache/brpc/pull/3536.","Type":"Description","Title":"Apache bRPC: Null pointer dereference in MySQL reply parser lead"}]}}}