monetr is a budgeting application for recurring expenses. Prior to version 1.12.5, 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. This issue has been patched in version 1.12.5.

Affected: Go: github.com/monetr/monetr

### 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 sinc…