CVE-2026-48106: Arc Enterprise cluster replication accepts unauthenticated MsgReplicateSync messages, enabling cluster-wide data injection from any TLS-trusted peer
Arc is an open, SQL-native time-series database for telemetry. Prior to version 26.06.1, Arc Enterprise's cluster replication receiver at internal/cluster/replication/receiver.go validates only the wire-format envelope (length, opcode) of inbound messages. The MsgReplicateSync payload itself is accepted without any application-layer authentication — no HMAC, no signature, no per-message nonce. The replication stream is protected at the transport layer by TLS / mTLS, but there is no protection against application-layer message tampering or replay once a peer is on the cluster network. This is fixed in 2026.06.1. Some workarounds are available. Restrict cluster network access to known-trusted peers via strict firewall rules, audit replication logs for unexpected MsgReplicateSync traffic, and/or disable cluster mode until the fix is available.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 2026.06.1 - Configuration
Disable cluster mode until the fix is available (prior to 26.06.1, the receiver validates only wire-format envelope and accepts MsgReplicateSync without application-layer authentication).
Arc Enterprise cluster mode cluster_mode = disabled - Compensating control
Restrict cluster network access to known-trusted peers via strict firewall rules (since MsgReplicateSync lacks application-layer authentication).
- Compensating control
Audit replication logs for unexpected MsgReplicateSync traffic to detect unauthorized cluster-wide data injection attempts.
Event History
Frequently Asked Questions
Which deployments are exposed?
Arc Enterprise deployments running a version prior to 2026.06.1 with cluster replication enabled are affected. The issue is reachable by a peer that can connect to the cluster replication stream and is trusted by its TLS or mTLS configuration.
What does an attacker need to exploit this?
An attacker needs access as a TLS-trusted peer on the cluster network. They can send or replay MsgReplicateSync messages without application-layer authentication, such as an HMAC, signature, or per-message nonce.
Does TLS or mTLS prevent exploitation?
No. TLS or mTLS protects the transport connection, but the affected receiver does not authenticate the MsgReplicateSync payload at the application layer; a trusted peer can tamper with or replay replication messages.
What can be done before upgrading?
Restrict cluster-network access to known trusted peers with strict firewall rules, and audit replication logs for unexpected MsgReplicateSync traffic. Disabling cluster mode is also listed as a workaround until the fix is available.
How can administrators look for possible abuse?
Review replication logs for unexpected MsgReplicateSync traffic. The provided information does not specify a more detailed indicator or log signature.