CVE-2026-70462

The signed integer overflow in rsync's MSG_IO_TIMEOUT handling (CVE-2026-70462) is being treated as a resource exhaustion issue, but the real analytical question is how an attacker gains the ability to inject these messages into a running rsync connection in the first place. That precondition — not the CVSS score — should drive your prioritization. The overflow itself is straightforward: a signed integer wraps when a non-positive timeout value is sent, permanently latching the timeout to a disabled state for that connection. But the attack path matters enormously. If MSG_IO_TIMEOUT injection requires an authenticated rsync session, exposure is limited to insiders or compromised accounts. If an unauthenticated attacker can inject these messages via network-level manipulation of rsyncd traffic — a man-in-the-middle scenario against unencrypted rsyncd over TCP — the exposure profile changes completely. The CVE description says attackers can 'inject' messages but doesn't clarify the authentication requirement. That ambiguity is the first thing to resolve in your environment. The downstream risk extends beyond connection handling. In deployments where I/O timeouts serve as a heartbeat or detection signal for hung or hijacked sessions, permanently disabling them blinds every security control that depends on timeout-based anomaly detection. One latched connection holding a daemon slot becomes a persistent blind spot — not a loud denial-of-service, but a quiet detection evasion that could sustain a foothold indefinitely. The blast radius isn't measured in exhausted connections; it's measured in invalidated monitoring assumptions. From a protocol design standpoint, the deeper failure is that MSG_IO_TIMEOUT exists as an externally-sendable message at all. The fix should question whether legitimate use cases require dynamic timeout adjustment mid-connection, and whether that capability justifies the attack surface. Hard-coded or configuration-derived timeouts would eliminate this entire vulnerability class. Practically, audit whether your rsync traffic traverses untrusted networks, whether daemon slots are a constrained resource in your deployment, and whether any security instrumentation relies on timeout-based detection that could now be bypassed. The low EPSS (0.00259) likely reflects assumptions about authenticated-only access — verify those assumptions hold in your environment before accepting the score at face value.

Reviewed through automated stages and approved by a human before publication.