Relay's internal address is disclosed to unauthenticated callers via push.origin and NIP-98 error detail
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
### 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.
Contributor guide
Research direction
Start with the unauthenticated GET / response and the NIP-98 verification path, using the deployment context in deploy/compose to reproduce both disclosures. Verify that the public response and failed authenticated request no longer reveal the configured internal address, while the relay still reports the expected metadata and URL-mismatch behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend-api-design, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100