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, disclosed on May 18, 2026 with a CVSS v3.1 score of 9.8, affects all versions of amazon-redshift-python-driver prior to 2.1.14 and allows a malicious server (or a man in the middle) to execute arbitrary Python code on the client machine simply by returning 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 foundational dependency for enterprise data pipelines, ETL jobs, CI/CD runners, and developer environments worldwide. Given AWS's 28 percent share of the global cloud infrastructure market as of Q4 2025, the potential blast radius of a vulnerability in this driver is substantial.

Technical Information

Root Cause: eval() on Untrusted Server Data

The vulnerability, classified as CWE-94 (Improper Control of Generation of Code), resides in the vector_in() function inside redshift_connector/utils/type_utils.py. This function is a type handler responsible for deserializing vector data returned by the Redshift server over the PostgreSQL wire protocol.

Prior to 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 logic is straightforward: take the raw bytes from the server response, decode them as text, replace spaces with commas, wrap them in square brackets, and hand the resulting string directly to eval(). For benign input like 1 2 3, this evaluates [1,2,3], which is convenient but catastrophic from a security perspective. The server controls the content of data, and eval() will execute whatever Python expression it receives.

Attack Flow

An attacker can exploit this vulnerability through the following sequence:

1. Establish a rogue endpoint. 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. Wait for a client connection. 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. Return a malicious query response. When the client issues a query, the rogue server responds with a result set containing a vector column. Instead of legitimate numeric data, the server injects a Python expression into the vector payload, for example: __import__('os').system('echo exploited').

4. Code execution on the client. 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. This could mean command execution, file system access, credential theft, or lateral movement, depending on the environment.

No authentication is required from the attacker. No user interaction is needed. The attack complexity is low: the attacker only needs network access to the client's connection path.

Severity Metrics

The vulnerability carries critical severity scores across both CVSS frameworks:

These scores confirm complete compromise of confidentiality, integrity, and availability with no prerequisites beyond network access.

Patch Information

AWS addressed CVE-2026-8838 in amazon-redshift-python-driver version 2.1.14, released on May 18, 2026 and available via both PyPI and GitHub. The fix is targeted, surgical, and instructive.

The patched vector_in() function eliminates 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. Instead of blindly evaluating whatever the server sends, the patched code decodes the bytes into text, splits on whitespace, and converts each token to an integer using int(). If the server sends anything that is not a valid integer, including malicious Python code, the int() call raises a ValueError, stopping execution immediately. No code injection is possible.

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

Comprehensive unit tests were added in test/unit/test_type_utils.py to validate both correctness and security. The tests include explicit injection payload tests:

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))

These tests confirm that each of the 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 validate the package integrity using the official hashes:

AWS explicitly advises that organizations utilizing forked or derivative code based on the driver must manually patch their repositories to incorporate the fix. No temporary workarounds or compensating controls are documented in the official advisories; 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 prior to 2.1.14 is vulnerable. This includes environments where the driver is installed as a transitive dependency.

Vendor Security History

AWS demonstrated a mature coordinated disclosure process for this vulnerability. The security bulletin (2026-033-AWS), GitHub security advisory (GHSA-29h4-r29x-hchv), and patched release were all published simultaneously on May 18, 2026, ensuring customers had a direct remediation path available at the time of disclosure. AWS credited Kexin Chen from the Institute of Information Engineering, Chinese Academy of Sciences, for collaborating on the discovery and resolution of 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