Critical RCE Flaw Discovered in D-Tale Data Visualization Tool

By Admin 2 Min Read 0 Follow on Google News Add to Preferred Source

A critical security vulnerability has been discovered in D-Tale, a popular data visualization tool, allowing attackers to execute arbitrary system commands remotely without authentication. The vulnerability, initially designated CVE-2025-0655 before being reclassified as a duplicate of CVE-2024-55890, affects version 3.15.1 and carries a maximum CVSS score of 9.8.

The vulnerability stems from how D-Tale handles its global configuration settings in the backend. At its core, the issue involves an exposed API endpoint that allows attackers to toggle the enable_custom_filters flag through a specially crafted POST request to /dtale/global_state. This flag, originally designed for controlled environments, becomes a gateway for exploitation when enabled.

Once this setting is activated, attackers gain access to the /dtale/test-filter endpoint, which processes user-supplied filter expressions. The critical flaw lies in how this endpoint evaluates Python expressions using unsafe methods, like eval(), creating a direct pathway for code injection.

Exploitation Process

The attack unfolds in three straightforward steps. First, attackers send a POST request to enable the custom filters functionality. Next, they craft malicious payloads containing embedded system commands, such as "__import__('os').system('id')", and submit them to the test-filter endpoint. Finally, the server evaluates these expressions, executing the attacker’s code with the privileges of the web server.

This vulnerability is particularly concerning because it requires no authentication and can be exploited remotely when D-Tale servers are exposed to external networks. Security researchers have even developed dedicated Metasploit modules to automate the exploitation process.

Protection and Remediation

Organizations using D-Tale should immediately upgrade to version 3.16.1 or newer, where this vulnerability has been patched. 

Additional protective measures include restricting network exposure to trusted internal networks, avoiding dangerous configuration settings in production environments, and implementing Web Application Firewalls to detect malicious API calls targeting these endpoints.

Community Discussion

Join the conversation. Ask questions, share solutions, and help others.

0 Comments

Be the first to start the discussion!

Leave a Comment

Your email address will not be published. Required fields are marked *

We respect your privacy, your information is safe with us.

Latest Articles

View all