Refuse [::], 0.0.0.0, IPv6 multicast and documentation space (closes #341)
check / check (push) Waiting to run

On Linux a connection to the unspecified address [::] or 0.0.0.0
reaches the host's own loopback, and the SSRF guard let [::] through.
Both unspecified addresses now sit in alwaysBlockedNetworks, so an
allowlist reaches loopback only through an entry that covers a
loopback address, never through one that covers only 0.0.0.0 or ::;
::/128 joins the default blocklist beside 0.0.0.0/8. IPv6 multicast
(ff00::/8) and documentation space (2001:db8::/32) are refused by
default. Every default blocklist entry gets a one-line comment, and the
README, the rules above each list, the two pinning tests and the
allowlist refusal test follow.

Model: opus-5-5
This commit is contained in:
2026-10-02 08:15:55 +00:00
parent b78abdc9da
commit 3699f37b76
6 changed files with 179 additions and 57 deletions
+5 -4
View File
@@ -196,10 +196,11 @@ type Config struct {
// otherwise refuse. The guard itself is always on: there is no
// setting that disables SSRF protection, and delivery's
// alwaysBlockedNetworks stays blocked no matter what is listed
// here. That set is link-local plus the cloud metadata
// endpoints outside it that disclose credentials or user data
// at a provider-fixed, non-public address; it is not
// exhaustive of every cloud's metadata address. See
// here. That set is link-local, the unspecified addresses
// 0.0.0.0 and ::, and the cloud metadata endpoints outside
// link-local that disclose credentials or user data at a
// provider-fixed, non-public address; it is not exhaustive of
// every cloud's metadata address. See
// alwaysBlockedNetworks for the authoritative list and the
// criterion it is built from.
AllowedEgressCIDRs []netip.Prefix