CVE-2026-84700 in PikiwiDB
Summary
by MITRE • 09/02/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability in PikiwiDB version 3.5.7 represents a critical authentication bypass within its internal replication subsystem, specifically affecting the protobuf-based replication server that operates on a port derived from the primary client listening port by adding two thousand. This architectural design exposes an administrative interface to potential attackers who can discover this secondary endpoint through simple network enumeration or by calculating the expected port number based on known default configurations such as 11221 when the standard client port is set to 9221. The core technical flaw lies in a misconfiguration of access control logic within the message handling pipeline, where the system fails to enforce authentication requirements uniformly across all replication-related operations despite the presence of password-based security controls intended for this purpose.
From a technical perspective, the defect originates from an inconsistent implementation of the requirepass directive which is designed to gate replication traffic by requiring slaves to present credentials via masterauth within their MetaSync request messages. While the HandleMetaSyncRequest function correctly validates these credentials before allowing synchronization procedures to proceed, the broader frame dispatcher known as DealMessage lacks this same verification step for other message types. This architectural oversight means that once a connection is established on the replication port, any client can bypass the authentication check by skipping the MetaSync phase and directly issuing subsequent commands such as TrySync, DBSync, BinlogSync, or RemoveSlaveNode requests. The system processes these messages without verifying whether an authenticated session was previously established, effectively treating unauthenticated connections with the same privilege level as fully authorized replica nodes.
The operational impact of this vulnerability is severe due to the sensitive nature of replication traffic which contains full database snapshots and live write streams essential for maintaining data consistency across distributed clusters. An unauthenticated remote attacker can exploit this flaw to extract complete copies of the database contents through DBSync or BinlogSync requests, leading to a total compromise of data confidentiality. Furthermore, the ability to issue RemoveSlaveNode commands allows an adversary to disrupt cluster availability by forcibly ejecting legitimate replica nodes from the replication topology, resulting in denial of service conditions and potential data loss if quorum requirements are not met. This dual capability for both information disclosure and service disruption significantly elevates the risk profile beyond a simple authentication bypass.
This vulnerability aligns with CWE-287 which describes Improper Authentication where an entity claims to have a given identity but is not actually that entity, specifically manifesting here as a failure to enforce authentication on specific API endpoints or message handlers within the same service interface. In terms of attack vectors and tactics, this behavior corresponds to ATT&CK technique T1078 which involves Valid Accounts being used for unauthorized access, although in this case the account is implicitly created by the protocol state machine rather than a traditional user credential set. The exploitation path also reflects aspects of T1530 Data from Local System Backup as the attacker retrieves full-sync snapshots that are functionally equivalent to system backups containing all persistent data.
Mitigation strategies must prioritize immediate patching to version 3.5.8 or later where this logic gap has been addressed by ensuring that DealMessage enforces authentication checks for all replication message types regardless of whether a prior MetaSync handshake occurred. In environments where upgrading is not immediately feasible, network-level controls should be implemented to restrict access to the derived replication port using firewall rules or security groups, allowing connections only from known replica node IP addresses. Additionally, administrators should consider changing the default client port configuration to obscure the calculated replication port number through obscurity as a secondary defense layer while acknowledging that this does not replace proper authentication enforcement. Regular auditing of network traffic on database ports can also help detect unauthorized attempts to interact with these internal services before they result in data exfiltration or cluster disruption.