monetr: Server-side request forgery in Lunch Flow link creation and refresh
Date: 2026-04
Affected: go/github.com/monetr/monetr
Attack vector: ssrf
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2026-41644
CWE: CWE-209
CWE-770
CWE-918

### Impact A server-side request forgery (SSRF) vulnerability in monetr's Lunch Flow integration allowed any authenticated user on a self-hosted instance to cause the monetr server to issue HTTP GET requests to arbitrary URLs supplied by the caller, with the response body from non-200 upstream responses reflected back in the API error message. The URL validator on `POST /api/lunch_flow/link` only checked the URL scheme and rejected query parameters; it did not filter loopback, RFC1918, link-local, or cloud-provider metadata addresses. The outbound HTTP client read the response body via an unbounded `io.ReadAll`, and the controller intentionally surfaced the resulting error (which contained the upstream body) as the JSON `error` field of the API response. **Who is affected:** self-hosted monetr deployments running the default configuration. Out of the box, `LunchFlow.Enabled=true`, `AllowSignUp=true`, and billing is not enforced, so any user who can register on the instance can reach the vulnerable endpoint. Deployments running in a cloud environment where instance metadata is reachable from the pod (e.g. AWS EC2 without IMDSv2 enforced) expand the impact to include potential exposure of instance metadata through the reflected error body. **Who is NOT affected:** the hosted `my.monetr.app` service, which runs with `LunchFlow.Enabled=false`. Self-hosted operators who had already disabled public sign-up (`MONETR_ALLOW_SIGN_UP=false`) substantially reduce their exposure since


Mitigations:

Architectural layers (MAESTRO):