CVE-2026-22794: One-Click Account Takeover via Poisoned Password Reset Links

CVE: CVE-2026-22794
Severity: Critical
CVSS v3.1: 9.6 (High Impact, Easy to Exploit)
Exploitability: High — can be done without authentication; attacker only needs to send crafted HTTP requests.
Exploit Available: Yes — demonstrated with simple proof-of-concept steps.

What is this vulnerability?

This issue is what’s commonly called a password-reset poisoning flaw. It arises when an application builds a sensitive link—like a password-reset or email-verification link—based solely on what the client tells it about the target hostname.

In Appsmith versions prior to 1.93, when a user requested to reset their password or verify their email, the server trusted the Origin header provided by the HTTP request and used that value to construct the reset/verification URLs that get emailed out.

The problem is that Origin is something the client can control. An attacker doesn’t have to be inside your network to send a request with a fake Origin header—they just craft it and send it to the application. If the server blindly trusts this value and embeds it in URLs sent by email, an attacker can poison those links to point at a domain they control.

Why this is dangerous

A password-reset token is essentially a one-time key that allows the holder to change a user’s password without knowing the original one. In a secure system, only the legitimate user should see this token.

But if that token gets sent in a URL pointing to a server the attacker controls, they can capture the token when the victim clicks the link and then use it to take over the user’s account.

Here’s the worst part:

You don’t need to be authenticated.
You don’t need prior access to the victim’s email.
All you need is to get them to click a link sent by the real application.

When the victim actually clicks the poisoned link in their inbox, the token is passed to the attacker’s domain. From there, the attacker completes the reset process and sets a new password of their choosing.

That’s complete account takeover.

How the exploit works — in clear steps

Attacker sends a fake password-reset request for a legitimate user’s email address. Instead of letting the system derive the reset URL on its own, the attacker includes a manipulated Origin header pointing at an attacker-controlled domain like https://evildomain.com.
Because the server doesn’t validate the Origin and simply concatenates it into the reset link, the application sends an email to the user that contains a reset URL like: https://evildomain[.]com/user/resetPassword?token=<VALID_TOKEN> Even though the token is valid, the domain part of the URL has been poisoned.
The victim receives the email and clicks on the reset link—thinking it’s legitimate. But because the domain is evildomain.com, the token is sent directly to the attacker’s server first.
The attacker captures the token when the victim opens the link and then uses that token against the real Appsmith endpoint to finalize the password reset and set a new password.
Now the attacker has fully taken over the user’s account.

Why this happened

Appsmith derived sensitive URLs based on untrusted HTTP headers. The application assumed that whatever the browser sends as Origin could be safely used as the base of a link. This is fundamentally unsafe because:

HTTP headers like Origin, Host, and Referer can be spoofed by anyone who can send an HTTP request.
The server never checks whether the header actually points at its legitimate domain.
This trust boundary was never enforced properly.

A secure design should always use a configured base URL—one defined by the server’s configuration, not by whatever the client sends.

Walkthrough of a realistic Proof of Concept

Note: The following outlines the logical steps; do not use this to attack systems you are not authorized to test. This is for educational understanding on how attackers think.

Use a tool like cURL, Burp Suite, or any HTTP client to send a POST request to the Appsmith password reset endpoint.
Include headers like the following: POST /api/v1/users/forgotPassword HTTP/1.1 Host: app.yourcompany.com Origin: https://evildomain.com Content-Type: application/json { "email": "[email protected]" }
The server generates a password reset token and builds a URL using the Origin you supplied.
That URL gets emailed to [email protected].
When the victim clicks the email link, the token goes to evildomain.com, where the attacker records it.
The attacker then uses that token to call the actual reset endpoint and sets a new password for the victim.

Signs of possible exploitation

Detecting potential exploitation requires monitoring a few different things in your environment. These are the main areas where clues would show up:

1. Web access logs

Look for unusual Origin header values on requests made to password-reset endpoints.

Example suspicious pattern:

POST /api/v1/users/forgotPassword HTTP/1.1
Origin: https://ngrok-random-subdomain[.]com

This should never happen in production unless you are intentionally using that domain.

Even worse if you see:

Origin: https://127.0.0.1:8080

or custom domains not associated with your app.

2. Application logs

Search for email Sends where the reset link’s base URL doesn’t match your expected domains:

Reset link generated for user: [email protected] — link used origin: https://evildomain[.]com

That’s a direct signal you’ve seen an attempt or a real exploit.

3. Outbound email logs

If you log full reset links before sending emails, you might spot reset URLs that contain domains other than your app’s official host.

Example:

To: [email protected]
Reset link: https://attacker[.]server/user/resetPassword?token=...

Any domain not in your known list is a red flag.

4. SIEM correlation

Correlate:

Password reset requests
Unusual Origin values
Follow-up token use
Final password-update requests from unknown IPs

If you see a reset request from one IP with a weird Origin, followed shortly by a reset confirmation from a completely different IP, that’s suspicious.

5. Email recipients complaining about odd URLs

Users might forward the email to IT help with questions like “Why is this link pointing at a weird domain?” That’s a manual detection signal.

How to detect if the vulnerability is being probed or exploited

You can build rules in your logs/SIEM to catch patterns such as:

Requests to password reset endpoints with an Origin that doesn’t match the official domain.
Mismatched Host and Origin headers.
Outgoing email bodies containing domains outside your approved list.

In real environments, attackers often test with common tunneling services (like temporary ngrok or similar domains) so seeing those in production logs on sensitive endpoints is a clear indicator of malicious activity.

Indicators of compromise (IoCs)

Look for:

Reset links in logs pointing to unexpected domains.
Tokens used from IPs/geographies not associated with the legitimate user.
Multiple password resets for the same account within a short period, especially followed by a login from a new location.

How attackers could pivot after exploiting this

Once an attacker gains control of an account:

They might access internal dashboards or data the victim has access to.
They could create API keys or tokens in the victim’s name.
If the victim had elevated privileges, they could escalate further within the system.
They could use the account to send phishing or further malicious messages within the organization.

This isn’t just a password reset problem—compromise of a trusted user identity is a foothold that can lead to much larger breaches.

Defensive actions you should take right now

Upgrade Appsmith to version 1.93 or higher.
This release fixes the issue by enforcing the configured base URL and no longer trusting the unvalidated Origin header.
Official patch/upgrade link:
https://github.com/appsmithorg/appsmith/security/advisories/GHSA-7hf5-mc28-xmcv
Ensure your application is configured with a fixed base URL setting so it never depends on incoming headers to build security-critical links.
Harden logging so that sensitive tokens are not logged in cleartext unless necessary.
Monitor reset and verification traffic for anomalies.

Final Takeaway

This flaw is caused by trusting unvalidated Origin headers when building reset links.
It lets attackers craft links that send real, one-time password reset tokens to attacker machines.
Bad actors only need to get a victim to click the poisoned email link.
Detection revolves around watching for unusual origins in reset requests and unexpected domains in generated links.
Patch by upgrading to Appsmith 1.93 and enforce static base URL configurations.