blockedNetworks does not cover in-cloud provider service networks on public unicast, e.g. IBM Cloud 161.26.0.0/16 and 166.8.0.0/14 #244

New Issue

clawbot · 2026-08-20T08:35:40+02:00

clawbot commented

2026-08-20 08:35:40 +02:00

Flagged twice as out of scope during the reviews of #217, correctly — it is a gap in the DEFAULT BLOCKLIST, not in alwaysBlockedNetworks, and it predates that PR.

blockedNetworks in internal/delivery/ssrf.go covers private and IANA-reserved space. It does not cover provider service networks that live on PUBLIC unicast addresses. IBM Cloud is the concrete case: 161.26.0.0/16 and 166.8.0.0/14 are IBM-owned public ranges carrying in-cloud VPC DNS, NTP and package mirrors, reachable from a delivery target today with no allowlist set at all.

These are deliberately NOT candidates for alwaysBlockedNetworks, under the criterion that PR records above that variable: they are the operator's own in-cloud service network, and reaching operator infrastructure is the feature ALLOWED_EGRESS_CIDRS exists to provide. They also fail the "cannot collide with anything the operator runs" property that makes a host route free.

So the question this issue exists to answer is narrower and genuinely open: should the default blocklist refuse an operator's own in-cloud service network?

Arguments for: a webhook destination has no business resolving to your VPC's DNS resolver or package mirror, and an SSRF guard that stops at RFC1918 gives a false sense of coverage on any cloud that uses public space internally. Arguments against: these are not credential-vending, blocking them by default breaks a legitimate forward to a service the operator does run there, and the list is unbounded — every cloud has some version of this, so a partial list invites exactly the over-promising that has already been corrected twice on #217.

Also reported, and NOT accepted, in the same reviews: a GKE Services range 34.118.224.0/20. The prefix is unverified and it is a Kubernetes Service CIDR rather than a provider metadata network — do not add it without evidence.

Definition of done:

a decision recorded here on whether in-cloud provider service networks belong in the default blocklist
if yes: the entries added with each one's provider and purpose named, and the README stating plainly that the default blocklist now refuses some public addresses so an operator is not surprised
if no: the README says the default blocklist covers private and reserved space only, so nobody infers coverage it does not have
either way, the reasoning is recorded so a future sweep can refuse or accept candidates with a stated rule, as alwaysBlockedNetworks now does

Flagged twice as out of scope during the reviews of https://git.eeqj.de/sneak/webhooker/pulls/217, correctly — it is a gap in the DEFAULT BLOCKLIST, not in `alwaysBlockedNetworks`, and it predates that PR. `blockedNetworks` in `internal/delivery/ssrf.go` covers private and IANA-reserved space. It does not cover provider service networks that live on PUBLIC unicast addresses. IBM Cloud is the concrete case: `161.26.0.0/16` and `166.8.0.0/14` are IBM-owned public ranges carrying in-cloud VPC DNS, NTP and package mirrors, reachable from a delivery target today with no allowlist set at all. These are deliberately NOT candidates for `alwaysBlockedNetworks`, under the criterion that PR records above that variable: they are the operator's own in-cloud service network, and reaching operator infrastructure is the feature `ALLOWED_EGRESS_CIDRS` exists to provide. They also fail the "cannot collide with anything the operator runs" property that makes a host route free. So the question this issue exists to answer is narrower and genuinely open: **should the default blocklist refuse an operator's own in-cloud service network?** Arguments for: a webhook destination has no business resolving to your VPC's DNS resolver or package mirror, and an SSRF guard that stops at RFC1918 gives a false sense of coverage on any cloud that uses public space internally. Arguments against: these are not credential-vending, blocking them by default breaks a legitimate forward to a service the operator does run there, and the list is unbounded — every cloud has some version of this, so a partial list invites exactly the over-promising that has already been corrected twice on https://git.eeqj.de/sneak/webhooker/pulls/217. Also reported, and NOT accepted, in the same reviews: a GKE Services range `34.118.224.0/20`. The prefix is unverified and it is a Kubernetes Service CIDR rather than a provider metadata network — do not add it without evidence. Definition of done: - a decision recorded here on whether in-cloud provider service networks belong in the default blocklist - if yes: the entries added with each one's provider and purpose named, and the README stating plainly that the default blocklist now refuses some public addresses so an operator is not surprised - if no: the README says the default blocklist covers private and reserved space only, so nobody infers coverage it does not have - either way, the reasoning is recorded so a future sweep can refuse or accept candidates with a stated rule, as `alwaysBlockedNetworks` now does

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/webhooker#244