GHSA-j9gf-vw2f-9hrw Appsmith: Configuration-dependent origin validation bypass in password reset and email verification link generation

• Maven com.appsmith:server: < 2.0 → fixed in 2.0

Summary A configuration-dependent origin validation bypass was identified in Appsmith’s password reset and email verification flows on current `release`. Both flows derive the email-link base URL from the request `Origin` header. The current validation only enforces a trusted base URL when `APPSMITH_BASE_URL` is configured. If that setting is unset, the application accepts the caller-supplied origin and uses it to generate token-bearing reset and verification links. On deployments with email delivery enabled and `APPSMITH_BASE_URL` unset, this can cause Appsmith to send security-sensitive links whose clickable host is attacker-controlled, which can plausibly lead to account takeover after victim interaction. Details The current `release` head at commit `e77639eca4974469c1e676904851ffdaedd38111` was reviewed. The relevant routes are publicly reachable in `SecurityConfig.java`: • `POST /forgotPassword` is permitted without authentication at line `209` • `POST /resendEmailVerification` is permitted without authentication at line `228` In `UserControllerCE.java`, both flows copy the request `Origin` header into the DTO field used as the email-link base URL: • `forgotPasswordRequest(...)` at lines `91-94` • `resendEmailVerification(...)` at lines `189-193` In `UserServiceCEImpl.java`, base URL validation is conditional: • `@Value("${APPSMITH_BASE_URL:}")` at line `113` • `resolveSecureBaseUrl(...)` at lines `132-145` That method explicitly documents and implements this behavior: • if `APPSMITH_BASE_URL` is configured, the provided URL must match it • if `APPSMITH_BASE_URL` is unset, the provided URL is accepted for backward compatibility The resulting base URL is then used to construct token-bearing links: • `FORGOT_PASSWORD_CLIENT_URL_FORMAT` at line `149` • reset URL generation at lines `282-289` • `EMAIL_VERIFICATION_CLIENT_URL_FORMAT` at line `152` • verification URL generation at lines `931-940` This means the base URL is not only used for branding or display purposes. It directly controls the clickable host of security-sensitive reset and verification links. Note that the admin UI describes APPSMITH_BASE_URL as required for password reset and email verification links in: • `app/client/src/ce/pages/AdminSettings/config/configuration.tsx` at lines `41-49` The reviewed self-host material indicates this protection is not fail-closed by default, which makes the vulnerable condition realistic on existing deployments where operators have not set `APPSMITH_BASE_URL`. PoC These steps were designed for validation on an Appsmith deployment that I own or am explicitly authorized to test. 1. Deploy a non-production Appsmith instance from current `release`, or any build containing the affected code. 2. Enable outbound email delivery. 3. Leave `APPSMITH_BASE_URL` unset or blank. 4. Use a test mailbox account you control, for example `[email protected]`. 5. Send a password reset request with a forged `Origin` header: ```bash curl -i -X POST 'https://YOUR-INSTANCE/api/v1/users/forgotPassword' \ -H 'Content-Type: application/json' \ -H 'Origin: https://attacker.example' \ --data '{"email":"[email protected]"}' ``` 6. Inspect the delivered email. If affected, the clickable reset link is generated under `https://attacker.example/...` instead of the legitimate Appsmith host. 7. Repeat the same validation for resend email verification using an unverified test account: ```bash curl -i -X POST 'https://YOUR-INSTANCE/api/v1/users/resendEmailVerification' \ -H 'Content-Type: application/json' \ -H 'Origin: https://attacker.example' \ --data '{"email":"[email protected]"}' ``` 8. Inspect the delivered verification email. If affected, the clickable verification link is generated under `https://attacker.example/....` 9. Set `APPSMITH_BASE_URL=https://YOUR-INSTANCE`, restart the server, and repeat the same requests. 10. The expected secure behavior is that mismatched `Origin` is rejected, or the generated links no longer follow the forged request header. Live tokens, third-party data, or unsafe exploitation material was not included in this report. The attached archive contains source excerpts, data-flow proof, safe validation notes, and supporting evidence collected from the reviewed current branch. Impact This is a trust-boundary failure in token-bearing email authentication flows. Affected deployments are those where: • `APPSMITH_BASE_URL` is unset or blank • outbound email is enabled • password reset and/or email verification flows are enabled Attacker requirements are low: • no prior authentication is required to reach the relevant endpoints • the attacker only needs to trigger an email flow toward a target account Security impact: • Appsmith can generate password reset or verification emails whose clickable host is attacker-controlled • victim interaction can expose security-sensitive token material • this can plausibly result in account takeover • at minimum, it enables trusted-email abuse and phishing through the application itself mitigation 1. Remove the fallback behavior in `resolveSecureBaseUrl(...)` that accepts caller-supplied origin data when `APPSMITH_BASE_URL` is unset. 2. Fail closed for all token-bearing email flows when no trusted base URL is configured. 3. Use a single trusted-base-url helper across: • password reset • resend email verification • invite flows • instance admin invite flows 4. Add regression tests for the unset-configuration case. 5. Add startup or admin-level validation so security-sensitive email flows cannot operate until a trusted base URL is configured. Attachment appsmith-email-link-origin-validation-bypass-20260321.zip