Amazon Redshift Python Driver CVE-2026-8838: Brief Summary of a Critical eval() Injection Leading to Client RCE

Introduction

A single call to Python's eval() in the official Amazon Redshift Python driver turned every client connecting to a rogue or compromised server into a remote code execution target. CVE-2026-8838 was disclosed on May 18, 2026 with a CVSS v3.1 score of 9.8. It affects all versions of amazon-redshift-python-driver before 2.1.14, and it lets a malicious server (or a man in the middle) execute arbitrary Python code on the client machine with nothing more than crafted query results.

Amazon Redshift is AWS's fully managed cloud data warehouse, deeply integrated with services like S3, SageMaker, and Kinesis. The official Python connector (redshift-connector on PyPI) is a core dependency for enterprise data pipelines, ETL jobs, CI/CD runners, and developer environments worldwide. With AWS holding a 28 percent share of the global cloud infrastructure market as of Q4 2025, a vulnerability in this driver has a substantial potential blast radius.

Technical Information

Root Cause: eval() on Untrusted Server Data

The vulnerability, classified as CWE-94 (Improper Control of Generation of Code), is in the vector_in() function in redshift_connector/utils/type_utils.py. The function is a type handler that deserializes vector data the Redshift server returns over the PostgreSQL wire protocol.

Before the fix, the function looked like this:

# BEFORE (vulnerable)
def vector_in(data: bytes, idx: int, length: int) -> typing.List:
    return eval("[" + data[idx : idx + length].decode(_client_encoding).replace(" ", ",") + "]")

The function takes the raw bytes from the server response, decodes them as text, replaces spaces with commas, wraps the result in square brackets, and hands the string directly to eval(). For benign input like 1 2 3, this evaluates [1,2,3]. That is convenient, and it is also catastrophic for security, because the server controls the content of data and eval() will execute whatever Python expression it receives.

Attack Flow

The attack runs in four steps:

1. The attacker sets up a server that implements the PostgreSQL wire protocol (which Redshift uses), or positions themselves as a man in the middle on the network path between a legitimate client and a Redshift cluster.

2. The attacker waits for a client to connect. Any application, data pipeline, or developer tool using amazon-redshift-python-driver versions 0 through 2.1.13 that connects to the attacker's endpoint (or has its connection intercepted) becomes a target.

3. When the client issues a query, the rogue server responds with a result set containing a vector column. In place of legitimate numeric data, the server injects a Python expression into the vector payload, for example __import__('os').system('echo exploited').

4. The vector_in() function receives the malicious bytes, decodes them, and passes the result to eval(). The injected Python code executes with the full privileges of the client process. Depending on the environment, that could mean command execution, file system access, credential theft, or lateral movement.

The attacker needs no authentication and no user interaction. Attack complexity is low, because network access to the client's connection path is the only requirement.

Severity Metrics

Both CVSS frameworks rate the vulnerability critical:

Both vectors describe a complete compromise of confidentiality, integrity, and availability, with no prerequisite beyond network access.

Patch Information

AWS fixed CVE-2026-8838 in amazon-redshift-python-driver version 2.1.14, released on May 18, 2026 on both PyPI and GitHub. The fix is narrow and worth reading closely.

The patched vector_in() function removes eval() entirely and replaces it with explicit, safe integer parsing:

# AFTER (patched)
def vector_in(data: bytes, idx: int, length: int) -> typing.List:
    text = data[idx : idx + length].decode(_client_encoding).strip()
    if not text:
        return []
    return [int(x) for x in text.split()]

This is a textbook remediation. The patched code no longer evaluates whatever the server sends. It decodes the bytes into text, splits on whitespace, and converts each token with int(). If the server sends anything that is not a valid integer, malicious Python code included, the int() call raises a ValueError and execution stops immediately. No code injection is possible.

The patch (commit 69a69df) also removed related dead code: a glbls dictionary containing {"Decimal": Decimal}, a trans_tab translation table used for bracket substitution, and a large block of commented-out code for a similar array_in() function that also relied on eval(). Removing this code reduces the attack surface and takes away the temptation for future developers to re-enable the unsafe pattern.

New unit tests in test/unit/test_type_utils.py check both correctness and security, including explicit injection payloads:

vector_in_injection_payloads: typing.List[bytes] = [
    b"__import__('os').system('echo exploited')",
    b"__import__('os').uname().sysname",
    b"__import__('subprocess').check_output(['whoami'])",
    b"open('/etc/passwd').read()",
    b"exec('import os')",
]

@pytest.mark.parametrize("payload", vector_in_injection_payloads)
def test_vector_in_rejects_code_injection(payload) -> None:
    with pytest.raises((ValueError, TypeError)):
        type_utils.vector_in(payload, 0, len(payload))

The tests confirm that each of these classic eval() exploitation patterns now raises an exception instead of executing.

To upgrade:

pip install redshift-connector==2.1.14

For supply chain verification, security teams should check the package integrity against the official hashes:

AWS advises that organizations using forked or derivative code based on the driver must patch their repositories manually to incorporate the fix. The official advisories document no temporary workarounds or compensating controls, so upgrading is the only confirmed remediation.

Affected Systems and Versions

Any application, data pipeline, CI/CD runner, or developer environment using a version of redshift-connector before 2.1.14 is vulnerable, including environments where the driver is installed as a transitive dependency.

Vendor Security History

AWS ran a mature coordinated disclosure process for this vulnerability. The security bulletin (2026-033-AWS), the GitHub security advisory (GHSA-29h4-r29x-hchv), and the patched release all went out together on May 18, 2026, so customers had a direct remediation path the moment the issue became public. AWS credited Kexin Chen of the Institute of Information Engineering, Chinese Academy of Sciences, for collaborating on discovering and resolving the issue.

References

• AWS Security Bulletin 2026-033-AWS
• GitHub Security Advisory GHSA-29h4-r29x-hchv
• CVE-2026-8838 CVE Record
• Release v2.1.14 on GitHub
• redshift-connector 2.1.14 on PyPI
• Diff between v2.1.13 and v2.1.14
• CWE-94: Improper Control of Generation of Code