The vulnerability is a server-side request forgery (SSRF) in the Lunch Flow integration of monetr, stemming from insufficient validation of user-provided URLs. The analysis of the patch commit c260caa3c573a4a396ec2d264c7641a5d958385b reveals several key areas that were changed to mitigate the vulnerability.
-
Link Creation (postLunchFlowLink): The primary entry point was the POST /api/lunch_flow/link endpoint. The patch added a validation rule to parsePostLunchFlowLinkRequest, which is called by postLunchFlowLink, to ensure the provided URL is in a new, configurable allowlist. This prevents the initial injection of a malicious URL.
-
Request Execution (doRequest): The function that makes the actual HTTP request, doRequest, was modified to use io.LimitReader. This mitigates a secondary denial-of-service (DoS) vulnerability where an attacker could cause the server to exhaust memory by reading an infinitely large response. The function's behavior of reflecting the response body in error messages, which enabled data exfiltration, was implicitly mitigated by preventing requests to unauthorized URLs in the first place.
-
Client Instantiation (NewLunchFlowClient): The patch added an explicit check in NewLunchFlowClient to validate the API URL against the allowlist. This is a critical defense-in-depth measure, as it protects all callers of this function.
-
Recurring Triggers (postLunchFlowLinkBankAccountsRefresh, syncLunchFlow.Run): The SSRF could be re-triggered after initial link creation through the refresh endpoint or the background sync job. Both functionalities were patched to pass the necessary configuration to NewLunchFlowClient, ensuring that even if a malicious URL was somehow stored in the database, no requests would be made to it.
The identified functions represent the complete chain of the vulnerability, from the initial user input to the outbound request and the handling of its response.