Default-block the public-unicast cloud metadata endpoints (Azure WireServer, Equinix Metal) #245

New Issue

clawbot · 2026-08-20T10:05:03+02:00

clawbot commented

2026-08-20 10:05:03 +02:00

Split out of #217 by scope ruling. Not milestoned for 1.0.

168.63.129.16 (Azure WireServer) and 147.75.207.243 (Equinix Metal) are cloud metadata endpoints that serve credentials, but unlike 169.254.169.254 they are public unicast — they fall in no private or reserved range, so the SSRF guard currently permits them.

They were added to alwaysBlockedNetworks during the rework of #217 and have been removed again, for two reasons:

alwaysBlockedNetworks is unrecoverable by design — no allowlist entry can restore it. That is correct for link-local metadata, which is never a legitimate delivery destination. It is not correct for public unicast addresses: an operator who genuinely needs to reach one has no escape hatch at all, which is the exact condition #204 exists to remove.
It broke the property that an unset ALLOWED_EGRESS_CIDRS is a provable no-op. That property is what makes the allowlist PR's blast radius zero for every existing deployment, and it is worth more than folding an unrelated blocklist change into the same commit.

Definition of done:

Both addresses are added to blockedNetworks (the default blocklist), NOT alwaysBlockedNetworks, so the guard refuses them by default and an operator can deliberately allowlist them back.
A test asserts each is refused with ALLOWED_EGRESS_CIDRS unset, and permitted when explicitly allowlisted.
README documents that the default blocklist covers public-unicast metadata endpoints in addition to the private and reserved ranges.
Vendor sourcing for both addresses is cited in the commit body, so the pinned set has a provenance record.

Split out of https://git.eeqj.de/sneak/webhooker/pulls/217 by scope ruling. Not milestoned for 1.0. `168.63.129.16` (Azure WireServer) and `147.75.207.243` (Equinix Metal) are cloud metadata endpoints that serve credentials, but unlike `169.254.169.254` they are **public unicast** — they fall in no private or reserved range, so the SSRF guard currently permits them. They were added to `alwaysBlockedNetworks` during the rework of https://git.eeqj.de/sneak/webhooker/pulls/217 and have been removed again, for two reasons: 1. `alwaysBlockedNetworks` is unrecoverable by design — no allowlist entry can restore it. That is correct for link-local metadata, which is never a legitimate delivery destination. It is not correct for public unicast addresses: an operator who genuinely needs to reach one has no escape hatch at all, which is the exact condition https://git.eeqj.de/sneak/webhooker/issues/204 exists to remove. 2. It broke the property that an unset `ALLOWED_EGRESS_CIDRS` is a provable no-op. That property is what makes the allowlist PR's blast radius zero for every existing deployment, and it is worth more than folding an unrelated blocklist change into the same commit. Definition of done: - Both addresses are added to `blockedNetworks` (the default blocklist), NOT `alwaysBlockedNetworks`, so the guard refuses them by default and an operator can deliberately allowlist them back. - A test asserts each is refused with `ALLOWED_EGRESS_CIDRS` unset, and permitted when explicitly allowlisted. - README documents that the default blocklist covers public-unicast metadata endpoints in addition to the private and reserved ranges. - Vendor sourcing for both addresses is cited in the commit body, so the pinned set has a provenance record.

clawbot referenced this issue

2026-08-20 10:17:37 +02:00

Add an egress CIDR allowlist to the SSRF guard (closes #204) #217

clawbot referenced this issue

2026-08-20 10:17:55 +02:00

Add an egress CIDR allowlist to the SSRF guard (closes #204) #217

clawbot referenced this issue

2026-08-20 11:07:50 +02:00

Milestone 1.0.0: internet-facing readiness #111

Sign in to join this conversation.