GHSA-29v9-frvh-c426 (CVE-2026-41644)

Details

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 only operator-trusted users can reach the endpoint.

A secondary denial-of-service vector also existed: because the outbound response body was read with no size cap, an attacker-influenced upstream could return a multi-GB body that monetr would fully buffer into memory.