CVE-2026-45307: Speakr Open Redirect Vulnerability in Post-Login Redirects

Technical summary

The is_safe_url() helper in affected versions applies urljoin(request.host_url, target) before validation, which resolves a scheme-relative input like ////evil.com to a same-host URL, passing the safety check. However, the controller then passes the raw, unvalidated target string directly to the redirect() function. Browsers interpret scheme-relative URLs (network-path-relative references) literally in the Location header, causing navigation to the attacker-supplied host despite the validator's approval. This is a classic open redirect stemming from inconsistent parsing logic between validation and action layers. The CWE-601 classification confirms the open redirect nature of the issue.

Business impact

Open redirects in authentication flows pose a credential theft and phishing risk. An attacker can combine this flaw with social engineering to redirect legitimate users to a spoofed login page after they authenticate with Speakr, harvesting passwords or session tokens. Even if users notice the redirect, trust in the application is eroded. For organizations deploying Speakr internally, this becomes a post-authentication attack vector that undermines security awareness—users may assume a redirect from the app is legitimate. The medium CVSS score reflects the requirement for user interaction and the fact that no confidentiality, integrity, or availability of the application itself is directly compromised; the attack targets downstream user trust.

Affected systems

Speakr versions prior to 0.8.20-alpha are affected. The vulnerability is present in self-hosted deployments of this audio transcription tool. Since Speakr is designed as a personal, self-hosted application, exposure depends on how widely it has been adopted in organizational or shared hosting environments. No vendor product entries are specified in the advisory, indicating a niche or early-stage project. Administrators running Speakr should verify their installed version immediately.

Exploitability

Exploitation requires user interaction—an attacker must social-engineer a victim into clicking a link containing the malicious scheme-relative payload (e.g., ////evil.com) after the victim has authenticated. The attack surface is the post-login redirect mechanism, typically used by applications to send users to a referrer page or dashboard. No authentication bypass is needed; the attacker relies on the user's existing session. The low barrier to crafting the malicious URL and the common practice of clicking links in emails or messages make this practical to exploit at scale. However, the attack does not grant automatic compromise; it depends on victim behavior post-redirect.

Remediation

Upgrade to Speakr version 0.8.20-alpha or later, which corrects the parsing mismatch between validation and redirect logic. Organizations deploying Speakr should prioritize this patch to eliminate the post-login redirect vector. If immediate patching is not feasible, consider implementing network-level controls to restrict outbound redirects or deploy a Web Application Firewall (WAF) rule to detect and block scheme-relative URLs in Location headers. User education on phishing and suspicious redirects provides a complementary control.

Patch guidance

Apply Speakr version 0.8.20-alpha or any subsequent stable release. Verify patch application by checking the application version in the settings or logs. If you are running Speakr in a containerized environment, rebuild your image with the patched version and redeploy. Test the post-login redirect behavior after patching to confirm the fix is in place. Check release notes for any breaking changes or additional configuration steps. If you maintain a fork or custom deployment of Speakr, review the fix in the upstream repository and backport if necessary.

Detection guidance

Monitor HTTP access logs and security event logs for anomalous Location header values, particularly those containing scheme-relative URLs or unexpected external hosts in redirect responses. Look for requests with payloads like ////evil.com or //evil.com in query parameters tied to redirect or referrer functionality. If you have endpoint detection and response (EDR) or SIEM integration, create alerts for outbound HTTPS connections initiated by users immediately after POST requests to login or authentication endpoints—this pattern may indicate a successful open redirect exploitation. Web application firewalls can be tuned to flag or block responses with suspicious Location headers. Code review of any custom Speakr extensions or integrations should verify that redirect logic properly validates and canonicalizes URLs.

Why prioritize this

While the CVSS score is medium (6.1) and the attack requires user interaction, open redirects in authentication flows warrant prompt attention because they directly enable credential theft and phishing—attacks that often precede larger security incidents. The simplicity of exploitation and the trust relationship users have with post-login redirects amplify business risk despite moderate technical severity. Speakr is self-hosted, so exposure is limited to organizations that have adopted it, but those that have should treat this as a near-term patch priority. The fix is available and straightforward; delaying creates unnecessary risk for a relatively easy remediation.

Risk score, explained

The CVSS 3.1 score of 6.1 (MEDIUM) reflects: a network-accessible attack vector, low attack complexity (the payload is simple to craft), no privilege requirement, user interaction dependency (victim must click the link), changed scope (the attack affects trust boundary between app and user), and low impact to confidentiality and integrity of the application itself. The score does not fully capture the downstream credential theft risk, which is contextual and organization-dependent. In environments where users are highly susceptible to phishing or where Speakr serves sensitive audio content, the real-world risk may exceed the base score; conversely, in security-aware organizations with MFA and user education, the risk may be lower.

Frequently asked questions