Rodauth CVE-2026-82467

Exploitation requires that the Rodauth application has enabled at least one of the three affected features: confirm_password, login_return_to_requested_location, or two_factor_auth_return_to_requested_location. The attacker must be able to deliver a crafted URL to a victim user - typically via phishing - where the URL path or query parameter encodes a protocol-relative return destination beginning with //. User interaction is required: the victim must click the link and complete the authentication or password-confirmation flow on the legitimate application. The redirect only occurs post-authentication, so unauthenticated visitors are not subject to the redirect. Non-default configurations that disable all three of the above features are not exploitable.

The CVSS 4.0 score of 4.9 with vector AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N accurately captures the real-world risk profile. AT:P (attack requirements present) acknowledges that the attacker must first direct the victim to a crafted URL on the legitimate application - requiring a social engineering step (phishing email, malicious link). UI:P reflects that the victim must complete the authentication or password-confirmation flow. The SC:H rating reflects that subsequent-system confidentiality (the attacker-controlled site) can be fully compromised through credential harvesting or session phishing, even though the vulnerable application itself suffers no direct confidentiality loss (VC:N). No EPSS score was provided, and the vulnerability is not listed in CISA KEV. No public POC has been identified. While the attack vector is network-accessible and requires no privileges, the AT:P and UI:P constraints meaningfully reduce exploitability compared to a trivially unauthenticated remote code execution. Organizations using any of the three affected features in public-facing applications should treat this as a meaningful but non-emergency risk.

An attacker sends a phishing message containing a legitimate-looking link to the target application with a crafted return-to path - for example, https://app.example.com/login?return_to=//attacker.com/harvest. When the victim clicks the link, completes login or password confirmation, Rodauth reads the stored //attacker.com path from the session cookie and issues a redirect; the browser resolves this as https://attacker.com/harvest, where the attacker may present a credential-harvesting page. No public POC exists at time of analysis, but the attack is trivially constructible from the public advisory and commit diff.