From eval() to ast.literal_eval(): Closing a Code Injection Door in Slack Data Processing

Introduction

There's a function in Python that experienced developers have learned to fear: eval(). It's powerful, it's flexible, and in the wrong hands — or in the wrong context — it's a loaded weapon pointed at your own infrastructure. This week, we're examining a real-world fix that replaced a dangerous eval() call with its safe counterpart, ast.literal_eval(), in a Slack data processing component.

The vulnerability, catalogued under CVE-2025-3933, is classified as a Regular Expression Denial of Service (ReDoS) issue in the huggingface/transformers ecosystem, but the specific code fix addresses something arguably more dangerous: unsafe code execution via eval(). Whether you're a junior developer writing your first Python script or a seasoned engineer reviewing production code, this is a pattern you need to recognize and eliminate.

The Vulnerability Explained

What Is eval() and Why Is It Dangerous?

Python's eval() function takes a string and executes it as Python code. It's often used as a shortcut to parse data structures from strings — like turning "{'key': 'value'}" into an actual Python dictionary. On the surface, this seems harmless. But consider what happens when the string being evaluated isn't under your control.

# What the developer intended:
eval("{'error': 'not_found'}")
# Returns: {'error': 'not_found'} ✅

# What an attacker could inject:
eval("__import__('os').system('rm -rf /')")
# Executes: Deletes your entire filesystem ❌

eval() doesn't distinguish between "safe data" and "executable code." If an attacker can influence the string passed to eval(), they can execute any Python expression in the context of your application — with all the permissions and access your application has.

Where Was the Vulnerability?

The vulnerable code lived in apps/slack_data/slack_mcp_reader.py, specifically in the error handling logic of a SlackMCPReader class. When the Slack API returned an error, the code attempted to parse the error payload from the exception message using a regular expression, then passed the matched string directly to eval():

# BEFORE (Vulnerable Code)
match = re.search(r"'error':\s*(\{[^}]+\})", str(e))
if match:
    try:
        error_dict = eval(match.group(1))  # ⚠️ DANGEROUS
    except (ValueError, SyntaxError, NameError):
        pass

And again, a few lines below:

# BEFORE (Second Vulnerable Instance)
match = re.search(r"Failed to fetch messages:\s*(\{[^}]+\})", str(e))
if match:
    try:
        error_dict = eval(match.group(1))  # ⚠️ DANGEROUS
    except (ValueError, SyntaxError, NameError):
        pass

How Could This Be Exploited?

The attack surface here is the Slack API error response. If an attacker could influence what error messages the Slack API returns — or if the application connects to a malicious or compromised Slack-like endpoint — they could craft an error payload that, when parsed by the regex and passed to eval(), executes arbitrary code on the server.

Attack Scenario:

1. An attacker identifies that the application uses a Slack integration and processes error messages.
2. The attacker crafts a malicious error response that embeds Python code within the error dictionary string:
   Failed to fetch messages: {'error': __import__('subprocess').check_output(['whoami'])}
3. The regex extracts the "dictionary" portion of the string.
4. eval() executes the injected code in the application's runtime context.
5. The attacker now has Remote Code Execution (RCE) on the server.

What's the Real-World Impact?

The consequences of successful exploitation depend on the application's runtime permissions, but could include:

• Data exfiltration: Reading sensitive files, environment variables, API keys, or database credentials.
• Lateral movement: Using the compromised server as a pivot point to attack internal infrastructure.
• Service disruption: Crashing the application or consuming resources.
• Persistent backdoors: Writing malicious files or modifying existing code.
• Supply chain compromise: In an ML pipeline context (this is a transformers-adjacent project), corrupting model outputs or training data.

The Fix

Replacing eval() with ast.literal_eval()

The fix is elegant in its simplicity: replace eval() with ast.literal_eval() from Python's standard library.

# AFTER (Safe Code)
import ast  # Added at the top of the file

match = re.search(r"'error':\s*(\{[^}]+\})", str(e))
if match:
    try:
        error_dict = ast.literal_eval(match.group(1))  # ✅ SAFE
    except (ValueError, SyntaxError, NameError):
        pass

# AFTER (Second Instance Fixed)
match = re.search(r"Failed to fetch messages:\s*(\{[^}]+\})", str(e))
if match:
    try:
        error_dict = ast.literal_eval(match.group(1))  # ✅ SAFE
    except (ValueError, SyntaxError, NameError):
        pass

Why Is ast.literal_eval() Safe?

ast.literal_eval() is part of Python's Abstract Syntax Tree (AST) module. Unlike eval(), it only evaluates Python literals — strings, bytes, numbers, tuples, lists, dicts, sets, booleans, and None. It explicitly refuses to evaluate any expression that contains function calls, attribute access, or other executable constructs.

import ast

# Safe usage — parses data structures only
ast.literal_eval("{'error': 'not_found'}")
# Returns: {'error': 'not_found'} ✅

# Blocked — cannot execute function calls
ast.literal_eval("__import__('os').system('rm -rf /')")
# Raises: ValueError: malformed node or string ✅ (Attack neutralized)

# Blocked — cannot access attributes
ast.literal_eval("os.environ")
# Raises: ValueError ✅

The function works by parsing the string into an AST first, then inspecting the tree to ensure it contains only safe literal nodes before evaluating them. If anything unsafe is detected, it raises a ValueError — which is already caught by the existing exception handler in the code.

Before vs. After: Side-by-Side Comparison

The change is a drop-in replacement for this use case — the functionality is identical for safe inputs, but the attack surface is completely eliminated.

Conclusion

This fix is a perfect example of how a single function substitution can eliminate a serious security vulnerability. The developer who originally wrote eval(match.group(1)) was almost certainly focused on functionality — "I need to parse this dictionary string" — rather than security implications. This is completely understandable, and it's exactly why automated security scanning tools like Semgrep are invaluable in modern development workflows.

The key takeaways from this vulnerability:

1. eval() is almost never the right answer for parsing data. Use json.loads() for JSON, ast.literal_eval() for Python literals, or purpose-built parsers for structured formats.
2. Error handling code is attack surface too. It's easy to overlook security in exception handlers, but attackers specifically target edge cases and error paths.
3. Automated scanning catches what code review misses. This fix was triggered by Semgrep detection, demonstrating the value of integrating security tools into your CI/CD pipeline.
4. The fix was simple, safe, and non-breaking. ast.literal_eval() is a drop-in replacement for eval() when parsing literals — there's no excuse not to use it.

Security isn't about writing perfect code the first time. It's about building systems — including tooling, processes, and culture — that catch and fix these issues before they can be exploited. This fix is that system working exactly as intended.

Stay curious, stay secure, and audit your eval() calls today.

This vulnerability was automatically detected and fixed as part of an ongoing security improvement initiative. The fix was validated and is now live in production.