Description

The rpcap client code that processes a RPCAP_MSG_PACKET message received from the server incorrectly validates its headers. A malicious server can send a crafted message and cause the client to treat up to 20 bytes of the client process memory beyond the end of the buffer as if it was a part of the captured packet.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.0",
  "pubDate": "2026-09-05T19:16:55.477Z",
  "pubdate": "2026-09-05T19:16:55.477Z",
  "executiveSummary": "This vulnerability is an out-of-bounds (OOB) read flaw affecting the RPCAP client implementation. It arises due to improper validation of the RPCAP_MSG_PACKET message headers received from a remote server.\nThe vulnerability allows a malicious or compromised RPCAP server to manipulate packet header metadata, forcing the client process to read beyond the legitimate bounds of the allocated packet buffer. An attacker can cause the client to process up to 20 bytes of sensitive adjacent process memory as if it were part of the captured packet payload.\nThe risk implication is primarily related to information disclosure, where an attacker may be able to leak sensitive data stored in the memory space of the client application. Exploitation requires an attacker to successfully position themselves as an RPCAP server or perform a man-in-the-middle (MITM) attack to inject the crafted malicious message into the communication stream. Successful exploitation allows for the unauthorized retrieval of heap or stack contents, potentially leading to the compromise of sensitive data, such as credentials, pointers, or internal application state, depending on the memory layout and the nature of the information leaked.",
  "technicalDetails": "The vulnerability resides in the RPCAP client's packet processing logic, specifically in the handling of the RPCAP_MSG_PACKET message type. The RPCAP protocol, used for remote packet capture, relies on the client to parse fixed-length headers and variable-length payloads provided by the server. The flaw occurs during the validation phase of the packet header, where the client fails to adequately ensure that the size attributes specified in the message header align with the actual data received within the network buffer.\nThe attack flow begins when the client establishes a connection with a malicious RPCAP server. Once the connection is active, the attacker sends a crafted RPCAP_MSG_PACKET message. In this malicious message, the header contains a length field that is inconsistent with the actual bytes provided in the packet payload. Because the client performs insufficient bounds checking before processing the data, it treats the declared length as authoritative rather than verifying it against the actual buffer boundaries.\nBy inflating the length parameter within the message header, the attacker forces the client's packet processing routine to perform read operations beyond the allocated memory segment. This triggers an OOB read condition where the client copies subsequent memory segments into its processing pipeline. Specifically, the client is tricked into reading up to 20 bytes of adjacent heap or stack memory located immediately after the intended packet buffer. This leaked memory is then treated as part of the packet data, which may be subsequently logged, transmitted, or displayed by the client depending on its internal functionality.\nThe root cause is a failure in the trust boundary between the server-provided metadata and the client's memory management. There is no cryptographic or integrity-based validation of the packet length field at the application layer, allowing the server to define the bounds of the read operation. Because the RPCAP client operates in a network-exposed environment, it is susceptible to any attacker who can intercept or spoof server responses. The impact is determined by the contents of the memory adjacent to the buffer; if the client process contains sensitive information, such as keys, pointers, or user data, these could be exfiltrated by the attacker observing the output generated by the client from the malformed packet."
}