Unsafe use of Python's eval

In amazon-redshift-python-driver / redshift_connector, versions <= 2.1.13 process certain server-returned values in vector_in() with Python eval(). If the client talks to a malicious Redshift-compatible endpoint, or an attacker can tamper with server responses in transit, that untrusted data can become code execution inside the Python client process. The fix is 2.1.14, published on 2026-05-18 by AWS and GitHub.

The vendor's 9.8 CRITICAL score overstates enterprise reality. The impact is absolutely severe *once the attacker controls the server side of the conversation*, but that prerequisite is the whole story: most shops connect this driver to legitimate Redshift over TLS, usually inside AWS/VPC controls, so this is not an internet-wormable pre-auth server exploit. It's a trust-boundary failure on the client, not a direct compromise path into Redshift itself.

Why this verdict

• Downward pressure: attacker must own the trust path. The exploit is not 'send a packet to any Redshift server'; it requires a rogue server or MITM. That implies either prior compromise, configuration hijack, DNS/control-plane abuse, or a broken TLS/trust setup.
• Downward pressure: reachable population is narrow. redshift_connector lives inside Python apps, notebooks, ETL jobs, and services. There is no mass-scannable listener population comparable to an internet-exposed appliance or portal.
• Downward pressure: modern deployment defaults help. AWS states Redshift requires TLS 1.2+, clusters are locked down by default, and the driver supports sslmode verification. Good VPC and certificate hygiene kills the cleanest attack path.
• Upward pressure: impact on the client is full code execution. If the prerequisite trust boundary is broken, the attacker gets arbitrary Python execution in a process that often has data access, local secrets, and possibly AWS credentials.
• Upward pressure: data-platform blast radius can be meaningful. Analytics runners, schedulers, and notebooks frequently hold broad read paths into sensitive datasets, so a single exploited client can still become a high-value foothold.

Why not higher?

I am not scoring this HIGH or CRITICAL because the attack chain starts with a major prerequisite the vendor CVSS does not really price in: the attacker must become the server, or break the network trust path well enough to impersonate it. In a normal enterprise Redshift deployment with TLS, VPC scoping, and stable connection configuration, that sharply limits reachable victims and pushes this out of the 'drop everything' bucket.

Why not lower?

I am not pushing this to LOW because the flaw is genuine arbitrary code execution in the client process, not a theoretical parser crash. Many affected workloads are exactly the kind of Python jobs that carry useful data access, secrets, and cloud credentials, so compromise can still hurt badly if the trust precondition is met.

1. Enforce trusted Redshift endpoints — Restrict outbound database connections from affected workloads so they can only reach known Redshift hostnames/IPs or approved private endpoints. Do this as the primary mitigation within the noisgate mitigation SLA equivalent for a MEDIUM issue: there is no mitigation SLA — go straight to the 365-day remediation window, but high-value analytics tiers should still harden this immediately.
2. Require certificate validation — Audit connection settings and ensure the driver runs with TLS enabled and strict verification (ssl=True, sslmode=verify-full where operationally possible). This specifically cuts off the MITM branch of the attack chain; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, though this is worth fixing now if you find weak TLS settings.
3. Hunt for package copies — Inventory redshift_connector across hosts, containers, notebooks, CI images, and embedded virtual environments so you know where <=2.1.13 exists. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but you cannot remediate what you cannot enumerate.
4. Constrain workload identity — Reduce IAM role scope, local secret exposure, and filesystem privileges on analytics/ETL workers using this package. That does not remove the bug, but it limits blast radius if a client process is compromised during the remediation window.

Run this on the target host, container, notebook kernel image, or CI artifact where Python workloads may import redshift_connector. Invoke it with python3 check_redshift_connector_cve_2026_8838.py or python check_redshift_connector_cve_2026_8838.py; no elevated privileges are required unless you need them to access a restricted runtime environment.

#!/usr/bin/env python3
# check_redshift_connector_cve_2026_8838.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import sys

MIN_SAFE = (2, 1, 14)
PKG_NAMES = ["redshift_connector", "amazon-redshift-python-driver"]


def parse_version(v):
    if not v:
        return None
    out = []
    for part in str(v).split('.'):
        num = ''
        for ch in part:
            if ch.isdigit():
                num += ch
            else:
                break
        if num == '':
            return None
        out.append(int(num))
    while len(out) < 3:
        out.append(0)
    return tuple(out[:3])


def get_installed_version():
    try:
        try:
            from importlib import metadata as importlib_metadata
        except ImportError:
            import importlib_metadata  # type: ignore

        for name in PKG_NAMES:
            try:
                return name, importlib_metadata.version(name)
            except Exception:
                pass
    except Exception:
        pass

    try:
        import redshift_connector  # type: ignore
        v = getattr(redshift_connector, "__version__", None)
        return "redshift_connector", v
    except Exception:
        return None, None


if __name__ == "__main__":
    pkg, version = get_installed_version()

    if not pkg or not version:
        print("UNKNOWN: redshift_connector not found in current Python environment")
        sys.exit(2)

    parsed = parse_version(version)
    if parsed is None:
        print(f"UNKNOWN: found {pkg} version '{version}' but could not parse it")
        sys.exit(2)

    if parsed >= MIN_SAFE:
        print(f"PATCHED: found {pkg} version {version} (>= 2.1.14)")
        sys.exit(0)

    print(f"VULNERABLE: found {pkg} version {version} (< 2.1.14)")
    sys.exit(1)

Sources

1. AWS Security Bulletin 2026-033-AWS
2. GitHub Security Advisory GHSA-29h4-r29x-hchv
3. NVD CVE-2026-8838
4. PyPI redshift-connector release history
5. amazon-redshift-python-driver README / connection parameters
6. AWS Redshift infrastructure security
7. CISA Known Exploited Vulnerabilities Catalog
8. EPSS mirror for CVE-2026-8838 percentile view