CVE-2024-3408: Critical Auth Bypass and RCE in dtale

CVE-2024-3408 is a critical severity (CVSS 9.8) authentication bypass and remote code execution flaw in man-group dtale 3.10.0, caused by a hardcoded Flask secret key and weak restriction of custom filters. The record names no fixed version. Check the dtale release notes and upgrade past 3.10.0.

What's affected

The record lists man-group dtale, also called D-Tale, version 3.10.0. D-Tale is a web viewer for pandas data frames. The record gives two linked problems. First, the Flask configuration uses a hardcoded SECRET_KEY, which lets an attacker forge a session cookie if authentication is enabled. Second, the application does not properly restrict custom filter queries, so code can be run on the server through the /update-settings endpoint even when enable_custom_filters is not turned on.

The weaknesses are CWE-798, use of hard coded credentials, and CWE-94, improper control of code generation. The NVD vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: network reachable, no account, no user interaction, high impact on all three properties. That gives 9.8.

The references are a GitHub commit in the dtale repository and a huntr bounty report. The tool I use to load pages was unavailable when I reached them, so I am working from the record only, and I cannot confirm the first fixed release. The record does not mark it as exploited in the wild and it is not in the CISA KEV list.

How to check if you're exposed

1. Search for dtale in your environments. For Python, pip show dtale prints the version, and pip list | grep -i dtale finds it in an environment.
2. Check requirements files and lock files for dtale pinned to 3.10.0, for example with grep -ri dtale requirements*.txt poetry.lock.
3. Check whether any D-Tale server is reachable from a network wider than the analyst who started it. Data science tools are often launched on a shared notebook server.
4. Check whether authentication is enabled. The record says the forged cookie route applies when authentication is on, and the code execution route applies even with custom filters off.
5. Review web logs for requests to the /update-settings endpoint from sources you do not recognize.

Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan reads a requirements file in the browser and flags known issues in Python packages.

What to do now

1. Upgrade dtale to a release later than 3.10.0 that contains the fix commit. Confirm the exact version from the project release notes, since the record does not give it.
2. Stop any D-Tale instance that does not need to be running, especially ones on shared or public hosts.
3. Bind running instances to localhost, or place them behind an authenticating reverse proxy or VPN.
4. If a secret key was ever shared across instances, treat sessions as compromised and restart with a new key after the upgrade.
5. Run D-Tale as a low privilege user, in a container if you can, with no access to credentials or production data stores beyond what analysis needs.
6. Review the host for unexpected processes or files if an instance was exposed.

Why it matters

A hardcoded secret key means every installation signs session cookies with the same value, and that value is in the source code for anyone to read. It breaks the one job a secret has. Once sessions can be forged, authentication adds nothing.

The second problem makes the first one worse. An endpoint that accepts settings and evaluates filter expressions turns a data viewer into a code runner. Combine the two and an unauthenticated visitor can run commands as the user who launched D-Tale. Analysts often launch such tools with broad access to data and cloud credentials, which raises the stakes.

Quick check

Sources

• NVD record for CVE-2024-3408
• Fix commit in man-group/dtale (referenced by the record)
• huntr bounty report (referenced by the record)

Last reviewed: 19 October 2026.