Summary
The relay's unauthenticated root response includes its configured internal address in a push.origin field. When the relay is fronted by a reverse proxy on a public hostname, that internal address becomes visible to anyone who can reach the public endpoint.
Detail
Relay image ghcr.io/block/buzz:sha-318fbf8, self-hosted via deploy/compose behind Caddy.
GET / requires no authentication and returns relay metadata. In our deployment the response body contains the relay's internal network address (the one it was configured with) in push.origin.
The same address also appears in the NIP-98 error message on a failed authenticated request:
NIP-98 HTTP Auth verification failed: URL mismatch:
event has `https://public.example.com/query`,
expected `http://10.0.0.1:3001/query`
That error is returned to unauthenticated callers as well, since it fires during verification.
Impact
Low, but non-zero. In our case the leaked value is a private-range address that is not routable from the internet, so it is not directly actionable for an attacker. It does disclose internal network topology — that the relay sits behind a proxy, and on what address and port — to anyone who can reach the public endpoint.
For deployments where the origin is on a routable address, this would be more meaningful: it hands out the origin address to unauthenticated callers, which undermines a fronting proxy whose purpose is to keep the origin from being contacted directly.
Suggestion
Either derive push.origin from the configured public base URL rather than the bind address, or make the NIP-98 mismatch message generic for unauthenticated callers (log the detail server-side, return only "URL mismatch" to the client).
Not urgent from our side — filing it because it seems like something you would want to know about rather than something we need fixed.
Summary
The relay's unauthenticated root response includes its configured internal address in a
push.originfield. When the relay is fronted by a reverse proxy on a public hostname, that internal address becomes visible to anyone who can reach the public endpoint.Detail
Relay image
ghcr.io/block/buzz:sha-318fbf8, self-hosted viadeploy/composebehind Caddy.GET /requires no authentication and returns relay metadata. In our deployment the response body contains the relay's internal network address (the one it was configured with) inpush.origin.The same address also appears in the NIP-98 error message on a failed authenticated request:
That error is returned to unauthenticated callers as well, since it fires during verification.
Impact
Low, but non-zero. In our case the leaked value is a private-range address that is not routable from the internet, so it is not directly actionable for an attacker. It does disclose internal network topology — that the relay sits behind a proxy, and on what address and port — to anyone who can reach the public endpoint.
For deployments where the origin is on a routable address, this would be more meaningful: it hands out the origin address to unauthenticated callers, which undermines a fronting proxy whose purpose is to keep the origin from being contacted directly.
Suggestion
Either derive
push.originfrom the configured public base URL rather than the bind address, or make the NIP-98 mismatch message generic for unauthenticated callers (log the detail server-side, return only "URL mismatch" to the client).Not urgent from our side — filing it because it seems like something you would want to know about rather than something we need fixed.