Exploiting Default Secrets: How redash-reset Weaponizes Flask Token Forgery

Hook

Your Redash instance might be one command away from a complete takeover—not because of a zero-day, but because of a secret key that over 60% of self-hosted deployments never change.

Context

Redash, the popular open-source data visualization platform used by thousands of organizations, ships with a hardcoded default value for REDASH_SECRET_KEY in its configuration. This secret is the cryptographic foundation for Flask's session management and secure token generation. When administrators deploy Redash without changing this default, they unknowingly leave a master key under the welcome mat.

The redash-reset tool, created by security researcher RandomRobbieBF, is a proof-of-concept that demonstrates the catastrophic consequences of this oversight. Disclosed as CVE-2021-41192 and tracked under GitHub Security Advisory GHSA-g8xr-f424-h2rv, this vulnerability allows attackers who know the default secret to forge valid password reset tokens for any user ID. Unlike brute-force attacks or SQL injection, this exploit doesn't trigger rate limits or leave obvious traces in authentication logs—it simply crafts legitimate-looking tokens that the application trusts implicitly.

Technical Insight

At its core, redash-reset exploits the deterministic nature of Flask's token signing mechanism. Flask uses the itsdangerous library to create cryptographically signed tokens, combining a secret key with payload data to generate signatures that prevent tampering. When you know the secret key, you can forge any token you want.

The tool's architecture is elegantly simple. It leverages the URLSafeTimedSerializer class from itsdangerous—the same class Redash uses internally—to generate password reset tokens. Here's the critical code pattern:

from itsdangerous import URLSafeTimedSerializer

# The default secret that makes everything possible
DEFAULT_SECRET = 'veryverysecret'

def generate_reset_token(user_id, secret_key=DEFAULT_SECRET):
    serializer = URLSafeTimedSerializer(secret_key)
    # Redash uses the user ID as the token payload
    token = serializer.dumps(user_id, salt='password-reset')
    return token

# Generate tokens for user IDs 1-100
for user_id in range(1, 101):
    token = generate_reset_token(user_id)
    reset_url = f"https://target-redash.com/reset/{token}"
    print(f"User {user_id}: {reset_url}")

The 'veryverysecret' default isn't a placeholder or example value—it's the actual hardcoded default in Redash's codebase. The tool iterates through sequential user IDs because Redash, like many applications, uses auto-incrementing integers for primary keys. User ID 1 is typically the first administrative account created during installation.

What makes this particularly dangerous is the token validation flow. When a victim clicks a password reset link, Redash calls serializer.loads() with the same secret key and salt. If the signature validates, Redash trusts that the token was legitimately issued by the application, granting password reset privileges without requiring email verification or additional authentication factors.

The tool's reconnaissance strategy is interesting in its simplicity. Rather than attempting to enumerate valid email addresses or usernames, it generates tokens for a range of user IDs and outputs all corresponding reset URLs. An attacker can then test these URLs manually or automate the process with a simple HTTP client:

import requests

def test_reset_token(base_url, token):
    reset_endpoint = f"{base_url}/reset/{token}"
    response = requests.get(reset_endpoint, allow_redirects=False)
    
    # Valid tokens redirect to the password reset form
    if response.status_code == 302 and 'password' in response.headers.get('Location', ''):
        return True
    return False

The absence of rate limiting on token validation endpoints compounds the issue. Unlike login attempts, which typically trigger account lockouts or CAPTCHA challenges, token validation is often treated as a "read" operation that doesn't warrant aggressive throttling. This allows attackers to test hundreds of generated tokens without triggering security alerts.

From a cryptographic perspective, this vulnerability highlights why secret rotation and unique deployment secrets are foundational security practices. The same principle applies to JWT signing keys, database encryption keys, and any cryptographic material used for authentication or authorization. A known secret transforms a cryptographically secure system into security theater.

Gotcha

The tool's effectiveness is binary: it either works completely or fails completely. If a Redash administrator has changed the REDASH_SECRET_KEY to any non-default value, every token generated by redash-reset will be invalid. There's no partial exploitation, no degraded attack mode. This makes it an excellent detector for misconfigured instances but limits its utility in sophisticated penetration testing scenarios where adaptation is required.

Another significant limitation is the blind enumeration approach. The tool generates tokens for user IDs without knowing which IDs actually exist. In a Redash instance with only 5 users, generating tokens for IDs 1-100 means 95% of the output is useless. The tool provides no feedback mechanism to identify valid versus invalid user IDs before generating tokens, forcing testers to validate each URL manually or build their own verification layer. Additionally, organizations that deployed Redash with custom user ID sequences, UUIDs instead of integers, or non-sequential primary keys are immune to this enumeration strategy, though they remain vulnerable if using the default secret.

Verdict

Use if: You're conducting authorized security assessments of Redash deployments and need to verify that default secrets have been changed. This is an essential tool for red team exercises targeting data platforms, and security teams should absolutely run this against their own Redash instances as part of hardening checklists. It's also valuable for security researchers studying Flask token security patterns and understanding real-world cryptographic vulnerabilities. Skip if: You're not actively testing Redash security or lack written authorization to test the target system—this tool has no legitimate use outside authorized security work. Also skip if you need a comprehensive Redash vulnerability scanner; this addresses one specific misconfiguration and won't identify other security issues like SQL injection, XSS, or privilege escalation bugs. For production security monitoring, invest in proper secret management solutions and configuration auditing tools rather than relying on post-deployment vulnerability testing.