Description

PikiwiDB (Pika) v3.5.7 exposes an internal protobuf replication server on a port derived from the client port plus 2000 (e.g. 11221 when the default client port 9221 is used) that does not authenticate incoming requests. Although requirepass is intended to gate replication — a slave presents it as masterauth inside its MetaSync request — only the MetaSync handler (HandleMetaSyncRequest) validates it; the frame dispatcher (DealMessage) does not require a completed or attempted MetaSync before routing other message types to their handlers. As a result, an unauthenticated remote attacker can connect directly to the replication port and issue TrySync, DBSync, BinlogSync, and RemoveSlaveNode requests, obtaining the full-sync snapshot and live write stream and removing replica nodes, even when requirepass is configured.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.6",
  "pubDate": "2026-09-02T01:17:25.137Z",
  "pubdate": "2026-09-02T01:17:25.137Z",
  "executiveSummary": "PikiwiDB (Pika) version 3.5.7 contains a critical authentication bypass vulnerability within its protobuf-based replication protocol. The flaw resides in the architectural decoupling of the message dispatcher from the mandatory authentication handler.\nAlthough the configuration parameter 'requirepass' is designed to enforce access control, the implementation fails to enforce a state-based validation before processing arbitrary replication commands. An unauthenticated remote attacker can connect to the replication port—which defaults to the client port plus 2000—and execute administrative operations without providing valid credentials.\nThis vulnerability allows an attacker to perform unauthorized data exfiltration through full-sync snapshots, intercept live write streams via binlog synchronization, and perform disruptive actions such as the removal of existing replica nodes.\nThe risk is severe, as it grants full access to the underlying data store regardless of configured authentication settings. Successful exploitation requires network connectivity to the replication port but bypasses all internal authorization logic. Given the exposure of the replication port, environments relying on 'requirepass' for security are fully susceptible to unauthorized administrative control and data leakage.",
  "technicalDetails": "The root cause of this vulnerability is a flawed design in the network message processing flow, specifically within the frame dispatcher (DealMessage) component. While the PikiwiDB replication protocol includes a 'HandleMetaSyncRequest' function designed to validate 'requirepass' via the 'masterauth' parameter, the architecture allows for the routing of message types directly to their respective handlers without verifying the session state.\nIn PikiwiDB v3.5.7, the replication server listens on a secondary port derived from the primary client port (defaulting to 11221). Because the frame dispatcher does not implement an authentication check or enforce that a MetaSync has been successfully negotiated before handling requests, an attacker can bypass the intended security gate entirely.\nThe attack flow proceeds as follows: First, the attacker identifies the replication port by incrementing the target server's client port by 2000. Second, the attacker establishes a raw TCP connection to this port. Third, the attacker crafts and sends protobuf-encoded requests such as 'TrySync', 'DBSync', 'BinlogSync', or 'RemoveSlaveNode'.\nBecause 'DealMessage' routes these requests to their designated function handlers immediately upon receipt, the handlers execute their tasks as if they were interacting with a legitimate, authenticated slave node. The 'HandleMetaSyncRequest' function, which correctly checks the 'masterauth' field against the 'requirepass' setting, is effectively circumvented for all other replication protocol commands. This creates an environment where the authentication layer is optional rather than mandatory.\nThe impact of this vulnerability is high-integrity and high-confidentiality loss. An attacker can initiate a 'DBSync' request to force the server to provide a full snapshot of the database, or subscribe to the 'BinlogSync' stream to monitor live database updates. Furthermore, the ability to issue 'RemoveSlaveNode' requests allows an attacker to disrupt high-availability configurations and cluster stability. The vulnerability affects the entire replication communication stack, permitting administrative actions through the unauthenticated replication port despite the active configuration of 'requirepass'."
}