Monetr Lunch Flow SSRF Vulnerability
A server-side request forgery (SSRF) vulnerability in Monetr's Lunch Flow integration allows authenticated users on self-hosted instances to send HTTP GET requests to arbitrary URLs, potentially exposing sensitive information.
A server-side request forgery (SSRF) vulnerability was identified in the Lunch Flow integration of Monetr, affecting self-hosted instances. This vulnerability allows any authenticated user to cause the Monetr server to issue HTTP GET requests to arbitrary URLs, with the response body from non-200 upstream responses reflected back in the API error message. The URL validator on the POST /api/lunch_flow/link endpoint lacked sufficient filtering, failing to block loopback, RFC1918, link-local, or cloud-provider metadata addresses. This allows attackers to potentially access internal resources or cloud instance metadata. The vulnerability was addressed in Monetr version 1.12.5. The hosted my.monetr.app service is not affected because LunchFlow.Enabled is set to false.
Attack Chain
- An attacker registers an account on a vulnerable self-hosted Monetr instance where public sign-up is enabled (
AllowSignUp=true). - The attacker authenticates to the Monetr instance.
- The attacker crafts a malicious
POSTrequest to the/api/lunch_flow/linkendpoint, providing a URL pointing to an internal resource, such as a cloud metadata endpoint (e.g.,http://169.254.169.254/latest/meta-data/). - The Monetr server, due to insufficient URL validation, accepts the malicious URL.
- The Monetr server issues an HTTP GET request to the attacker-supplied URL.
- The external service or internal resource responds to the Monetr server.
- If the response is not a 200 OK, the Monetr server reflects the response body in the API error message within the JSON response to the attacker.
- The attacker observes the reflected response body, potentially revealing sensitive information like cloud instance metadata or internal service details.
Impact
Successful exploitation of this SSRF vulnerability can lead to the exposure of sensitive information, such as cloud instance metadata (e.g., AWS EC2 IMDS). This could allow an attacker to gain unauthorized access to other cloud resources or internal systems. The vulnerable instances are self-hosted Monetr deployments running the default configuration with LunchFlow.Enabled=true and AllowSignUp=true. An attacker could also cause a denial-of-service by providing a URL that returns a very large response body, exhausting the server’s memory.
Recommendation
- Upgrade to Monetr version
v1.12.5or later to patch the SSRF vulnerability. This version introduces a new config fieldLunchFlow.AllowedApiUrlsand caps response body reads at 10 MiB. - For operators who cannot upgrade immediately, set
MONETR_ALLOW_SIGN_UP=falseto disable public sign-up, limiting access to the vulnerable endpoint to trusted users. - Alternatively, disable Lunch Flow entirely by setting
lunchFlow.enabled: falsein your config file. This will cause the vulnerable endpoints to return 404. - Implement network-level egress restrictions to limit outbound HTTP traffic from the Monetr pod/container to only
lunchflow.app(or other legitimate Lunch Flow hosts), mitigating the SSRF primitive.
Detection coverage 2
Detect Monetr Lunch Flow Link Creation with Suspicious URL
highDetects attempts to create Lunch Flow links with URLs pointing to private IP addresses or cloud metadata endpoints, indicative of SSRF attempts.
Detect Monetr Warning Log for Rejected Lunch Flow API URL
mediumDetects warning logs indicating that a Lunch Flow API URL was rejected because it's not in the configured allowlist.
Detection queries are kept inside the platform. Get full rules →
Indicators of compromise
1
url
| Type | Value |
|---|---|
| url | https://lunchflow.app/api/v1 |