CVE-2026-54510 in Speakr
Summary
by MITRE • 09/18/2026
Speakr is a personal, self-hosted web application designed for transcribing audio recordings. Prior to 0.8.21-alpha, the csrf_exempt_for_api_tokens() before_request hook in src/app.py calls csrf.exempt(view_func), permanently adding the selected view to Flask-WTF's process-global exemption set. The is_token_authenticated() function in src/utils/token_auth.py calls extract_token_from_request() and treats any present token, including request.args.get('token'), as authenticated without hashing the token, querying the database, or checking validity. A network-reachable attacker can therefore send a false token to disable CSRF protection for the targeted view for the worker lifetime. Because the exemption applies to the view function across HTTP methods, a cross-origin GET to /account with a query token can poison CSRF state for a later state-changing POST without triggering CORS preflight. This browser sequence requires attacker-controlled content on a sibling subdomain under the documented cookie conditions. The bypass can modify profile data, custom prompts, transcription settings, preferences, and administrative status through routes such as admin_toggle_admin. The change_password route also skips current-password verification when current_user.password is empty, allowing the chain to set a local password on an SSO-only account and bypass SSO. This issue is fixed in version 0.8.21-alpha.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in Speakr versions prior to 0.8.21-alpha represents a critical failure in session management and cross-site request forgery protections, stemming from two distinct but compounding implementation flaws within the application's authentication and security middleware layers. The first flaw resides in the csrf_exempt_for_api_tokens() function located in src/app.py, which serves as a before_request hook intended to exempt specific API endpoints from CSRF validation when valid tokens are present. However, this function incorrectly invokes csrf.exempt(view_func) without verifying that the provided token is actually valid or associated with an active session. This action permanently adds the targeted view function to Flask-WTF's process-global exemption set for the duration of the worker lifetime. Consequently, any subsequent request to these endpoints bypasses CSRF checks entirely, regardless of whether a legitimate user initiated them, effectively neutralizing one of the primary defenses against cross-site attacks for those specific routes.
The second flaw is located in src/utils/token_auth.py within the is_token_authenticated() function, which handles token validation logic. This function calls extract_token_from_request() and treats any present token string as authenticated without performing essential security checks such as hashing verification, database queries to validate existence, or checking for expiration and validity status. By accepting any non-empty token value found in request parameters, including those passed via query strings through GET requests, the application grants administrative-level authentication privileges to unauthenticated actors who can supply arbitrary tokens. This lack of rigorous validation allows attackers to trivially bypass access controls by simply appending a dummy or malicious token to HTTP requests, thereby tricking the system into believing that an authenticated session is active when none exists.
The operational impact of these vulnerabilities is severe, enabling network-reachable attackers to execute cross-origin request forgery attacks against state-changing operations with minimal prerequisites. Because the CSRF exemption applies across all HTTP methods and persists for the worker lifetime, an attacker can poison the CSRF protection state by sending a simple GET request containing a malicious token in the query string. This action disables CSRF checks for subsequent requests to the affected views without triggering CORS preflight options, which typically alert users or block such cross-origin interactions. To exploit this chain effectively, particularly against routes like /account that involve sensitive profile modifications, an attacker must have control over content on a sibling subdomain under specific cookie conditions defined by Speakr's security policy. This setup allows the browser to automatically include cookies in requests made from the malicious page, facilitating the forgery of actions such as modifying user profiles, altering custom prompts, changing transcription settings, adjusting preferences, and even toggling administrative status via routes like admin_toggle_admin.
Furthermore, this vulnerability chain extends beyond standard privilege escalation into authentication bypass mechanisms that compromise account security integrity. The change_password route exhibits a critical logic error where it skips the verification of the current password if the current_user.password field is empty. This design flaw allows an attacker to set a local password on accounts that are otherwise restricted to Single Sign-On (SSO) authentication only. By combining this bypass with the CSRF exemption, an adversary can force a victim user's browser to change their account credentials without consent, effectively locking out legitimate users or gaining persistent access through newly created local credentials even if SSO remains enabled for other aspects of the system. This undermines the security model intended by administrators who rely on centralized identity management and exposes sensitive data stored within the application to unauthorized modification and exfiltration potential.
From a classification perspective, this vulnerability aligns with CWE-352 Cross-Site Request Forgery due to the improper neutralization of request parameters for CSRF prevention mechanisms. The authentication bypass component corresponds closely to CWE-287 Improper Authentication, as the system fails to adequately verify identity before granting access or performing sensitive actions. In terms of offensive security frameworks such as MITRE ATT&CK, this exploit leverages techniques associated with T1556 Modifying Authenticators and T1098 Account Manipulation, specifically focusing on altering account properties and credentials to maintain persistence or escalate privileges. The use of query parameters for token transmission also highlights issues related to CWE-20 Improper Input Validation, where the application accepts input without sufficient sanitization or verification against a trusted source.
Mitigation strategies must address both the architectural flaw in CSRF exemption handling and the logical error in password change validation. For Speakr administrators, upgrading immediately to version 0.8.21-alpha is the primary remediation step as it resolves these specific code defects. In environments where immediate patching is not feasible, temporary mitigations should include disabling any routes that are susceptible to this CSRF bypass if they do not require public access or ensuring that strict origin validation and token verification mechanisms are implemented at a reverse proxy level before requests reach the application server. Additionally, developers must ensure that authentication functions always perform rigorous checks against a secure database store rather than relying on the mere presence of input parameters. Implementing consistent use of POST methods for state-changing operations and validating Content-Type headers can further reduce the risk of CSRF exploitation by preventing simple GET-based attacks from succeeding even if other controls are bypassed.