CVE-2026-65321: Inyección SQL en PyAthena mediante el escape de comillas con barra invertida para sentencias que no son SELECT

Gravedad: Crítica, CVSS v4.0 9.3 / CVSS v3.1 9.8 (asignada por VulnCheck, la CNA)

Vector (v4.0): CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Vector (v3.1): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Afectado: PyAthena <= 3.35.3 (todas las versiones hasta la 3.35.3)

Corregido en: 3.35.4

CWE: CWE-89 (Neutralización incorrecta de elementos especiales utilizados en un comando SQL, 'Inyección SQL')

Reportado por: Rahul Karne

CNA: VulnCheck

Publicado: 3 de agosto de 2026

Resumen

PyAthena escapaba correctamente la entrada no confiable en las consultas SELECT e incorrectamente en las consultas DELETE.

PyAthena, el cliente Python DB-API de Amazon Athena ampliamente utilizado, selecciona su rutina de escape de cadenas según la palabra clave inicial de la sentencia. Las sentencias que comienzan con SELECT, WITH, INSERT, UPDATE o MERGE reciben un escape correcto para Trino, en el que una comilla simple se neutraliza duplicándola (''). Cualquier otra sentencia, más comúnmente un DELETE o un CREATE TABLE … AS SELECT (CTAS), cae en el escape con barra invertida estilo Hive (\'). El motor de Athena es Trino, que trata una barra invertida dentro de una cadena entre comillas simples como un carácter ordinario, por lo que el escape con barra invertida no neutraliza nada. Un atacante que pueda influir en un parámetro de cadena en dicha sentencia puede terminar el literal e inyectar SQL arbitrario, sin autenticación y sin interacción del usuario.

Por lo tanto, la falla está ausente de la ruta de lectura y presente exactamente en los tipos de sentencias destructivas donde causa más daño. El paquete se descarga 22,3 millones de veces al mes.

PyAthena es una biblioteca cliente comunitaria de terceros para Amazon Athena. No es un producto de AWS, y esta no es una vulnerabilidad en AWS ni en Athena en sí.

Impacto

Un atacante que controle un parámetro de cadena pasado a una sentencia vulnerable puede salirse del literal de cadena previsto y alterar la lógica de la sentencia. El impacto más directo y demostrable de manera fiable es la eliminación no autorizada de datos: una carga útil como missing' OR 1=1 -- en una consulta DELETE … WHERE token = %(token)s neutraliza el predicado WHERE y elimina todas las filas que el rol IAM del workgroup de Athena tiene permitido eliminar (por ejemplo, todas las filas de una tabla Iceberg). Dependiendo del tipo de sentencia y de los permisos del rol, un atacante también podría crear tablas definidas por el atacante mediante inyección CTAS y, cuando pueda leer posteriormente la tabla resultante, exfiltrar datos de otras tablas a las que el rol tenga acceso.

Todo el impacto está limitado por los permisos del workgroup de Athena / rol IAM que utiliza el cliente. Esta es una inyección en el plano de datos hacia el motor SQL de Athena; no permite ejecución de código en el host que ejecuta PyAthena, ni compromete a AWS en sí.

Quiénes están afectados: Aplicaciones que usan PyAthena < 3.35.4 con el DefaultParameterFormatter predeterminado (sustitución de parámetros pyformat / named en el lado del cliente) que (1) construyen una sentencia que no comienza con SELECT/WITH/INSERT/UPDATE/MERGE, en la práctica DELETE, CTAS, CREATE VIEW, DROP o ALTER, y (2) pasan datos influenciados por el atacante como parámetro de cadena a esa sentencia.

Quiénes no están afectados:

• Cualquiera que use PyAthena 3.35.4 o posterior.
• Aplicaciones cuyas sentencias parametrizadas solo comienzan con SELECT/WITH/INSERT/UPDATE/MERGE; estas se enrutan al escapador seguro de duplicación de comillas.
• Aplicaciones que pasan valores no confiables únicamente a través de los parámetros de consulta nativos del lado del servidor de Athena, en lugar de la interpolación del lado del cliente de PyAthena.
• Aplicaciones que nunca pasan datos no confiables o influenciados por el atacante como parámetros (todos los parámetros son constantes confiables).

Alcance

Detalle técnico

Causa raíz

DefaultParameterFormatter.format() selecciona la función de escape de cadenas únicamente a partir de la palabra clave inicial de la sentencia. Solo una lista de permitidos de prefijos recibe el escapador correcto para Trino; cualquier otra sentencia cae en el escape con barra invertida estilo Hive.

# src/pyathena/formatter.py, DefaultParameterFormatter.format(), lines ~271-275 (v3.35.2)
operation_upper = operation.upper()
if operation_upper.startswith(("SELECT", "WITH", "INSERT", "UPDATE", "MERGE")):
    escaper = _escape_presto      # safe: doubles single quotes
else:
    escaper = _escape_hive        # UNSAFE for Trino: backslash-escapes quotes

# src/pyathena/formatter.py, lines ~157-165 (v3.35.2)
def _escape_hive(val: str) -> str:
    escaped = (
        val.replace("\\", "\\\\")
        .replace("'", "\\'")          # produces \' (not a quote escape in Trino)
        .replace("\r", "\\r")
        .replace("\n", "\\n")
        .replace("\t", "\\t")
    )
    return f"'{escaped}'"

El motor SQL de Amazon Athena es Trino (Presto en versiones anteriores del motor). En Trino, el único escape para una comilla simple dentro de un literal de cadena entre comillas simples es duplicarla (''); una barra invertida es un carácter literal. Por lo tanto, _escape_hive no neutraliza una comilla en absoluto para Athena: emite ... = 'missing\' OR 1=1 -- ', que Trino analiza como el literal de cadena 'missing\' seguido de OR 1=1 -- ', es decir, SQL controlado por el atacante.

El diseño es de fallo peligroso (fail-dangerous): incluye en la lista blanca la ruta segura y establece como predeterminado el escapador inseguro para todo lo demás. La corrección upstream invierte esto a un diseño de fallo seguro (fail-safe): predetermina el escapador de Trino; usa el escape estilo Hive solo para DDL genuino de Hive como CREATE DATABASE/DROP TABLE/MSCK REPAIR, trata CTAS y CREATE VIEW como Trino; y, adicionalmente, elimina los comentarios SQL iniciales para que un prefijo /* … */ DELETE … no pueda eludir la detección del tipo de sentencia.

Por qué esto sobrevivió al análisis automatizado

_escape_hive no carece de sanitización, es sanitización. Es una rutina de escape correcta y bien formada para la gramática de literales de cadena de Hive, aplicada a un motor que usa la de Trino. Las herramientas de seguimiento de taint modelan la inyección SQL como datos no confiables que alcanzan un sumidero sin pasar por un escapador; aquí los datos pasan por un escapador en todas las rutas, y el escapador se ve exactamente como código de remediación porque es código de remediación, para el dialecto equivocado.

La corrección del dialecto no es una propiedad de taint, por lo que ninguna regla de taint la evalúa. El defecto es estructuralmente invisible para CodeQL, Semgrep, Snyk y Socket, no meramente pasado por alto por ellos, razón por la cual persistió en un paquete instalado aproximadamente nueve veces por segundo.

Precondiciones de explotación

Un atacante necesita:

1. Una aplicación objetivo que use PyAthena < 3.35.4 con el formateador de parámetros predeterminado del lado del cliente (paramstyle pyformat / named).
2. Una ruta de código que construya una sentencia que no comience con SELECT/WITH/INSERT/UPDATE/MERGE, en la práctica DELETE o CTAS.
3. La capacidad de influir en un parámetro de cadena pasado a esa sentencia.
4. Un workgroup de Athena / rol IAM cuyos permisos hagan significativo el SQL inyectado (por ejemplo, derechos de eliminación sobre la tabla objetivo, o derechos de lectura sobre otras tablas para la ruta de exfiltración).

Los parámetros numéricos, y cualquier sentencia enrutada al escapador seguro, no son explotables mediante esta falla.

Prueba de concepto

La PoC invoca el formateador real y sin modificar de PyAthena (importado desde la versión publicada en PyPI, no una reconstrucción) y ejecuta su salida contra una base de datos DuckDB local en memoria. Sin cuenta de AWS, sin credenciales, sin acceso a red. La reproducción completa son dos comandos:

pip install pyathena==3.35.2 duckdb
python poc_pyathena_cna_demo.py --no-pause

Fuente: poc_pyathena_cna_demo.py Demo grabada: Ver la demo

La propia afirmación de la biblioteca

El docstring de DefaultParameterFormatter afirma que escapa los parámetros para prevenir la inyección SQL. La PoC imprime ese docstring y luego imprime _escape_presto, _escape_hive y la rama de selección de prefijos directamente desde el paquete instalado mediante inspect.getsource, de modo que el lector ve la contradicción en el propio código fuente de la biblioteca en lugar de fiarse de la palabra del aviso.

Impacto A/I: ruptura del predicado en DELETE

Parámetro controlado por el atacante: missing' OR 1=1 --

DELETE FROM sessions WHERE token = 'missing\' OR 1=1 -- '

El lexer de Trino reconoce exactamente un escape para una comilla simple dentro de un literal de cadena entre comillas simples: duplicarla (''). Una barra invertida no tiene significado de escape. Por lo tanto, el literal termina en la comilla que sigue a missing\, y OR 1=1 -- se analiza como SQL. DuckDB comparte esta propiedad, y contra una tabla sessions precargada con dos filas el resultado es:

Rows before executing generated SQL: 2
Rows after executing generated SQL:  0

El predicado WHERE se neutraliza y se eliminan todas las filas.

Impacto C: ruptura de exfiltración mediante CTAS

Parámetro controlado por el atacante: nobody' UNION SELECT secret FROM admin_credentials --

CREATE TABLE leaked AS SELECT name FROM users WHERE name = 'nobody\' UNION SELECT secret FROM admin_credentials -- '

El UNION inyectado copia una fila de una tabla a la que la sentencia original nunca hizo referencia. En la demo, DEMO_SECRET_VALUE de admin_credentials termina en la tabla leaked, visible para el atacante. En Athena, esto está limitado por lo que el rol IAM del workgroup puede leer.

Controles: la ruta segura se comporta correctamente

Las mismas cargas útiles enrutadas a través de SELECT y UPDATE llegan a _escape_presto y se neutralizan correctamente mediante la duplicación de comillas:

SELECT name FROM users WHERE name = 'nobody'' UNION SELECT secret FROM admin_credentials -- '
UPDATE update_control SET token = 'x'' OR 1=1 -- ' WHERE id = 999

Ambas cargas útiles permanecen dentro del literal de cadena. SELECT devuelve cero filas y UPDATE modifica cero filas: no hay ruptura. Estos controles establecen que el banco de pruebas es sólido y que el defecto es específico de la selección del escapador, no de la configuración de la prueba.

Versión parcheada 3.35.4

Las mismas tres cargas útiles contra 3.35.4 producen en todos los casos salida con comillas duplicadas:

DELETE FROM sessions WHERE token = 'missing'' OR 1=1 -- '
CREATE TABLE leaked AS SELECT name FROM users WHERE name = 'nobody'' UNION SELECT secret FROM admin_credentials -- '

La corrección también sobrevive a un prefijo de comentario inicial, que de otro modo eludiría la detección del tipo de sentencia:

/* hi */ DELETE FROM sessions WHERE token = 'missing'' OR 1=1 -- '

En todos los casos, la carga útil queda contenida como dato y no se produce inyección.

Mitigación

Actualice a PyAthena 3.35.4 o posterior:

pip install --upgrade "pyathena>=3.35.4"

Si no puede actualizar de inmediato: evite pasar datos no confiables como parámetros a cualquier sentencia que no comience con SELECT/WITH/INSERT/UPDATE/MERGE. Para sentencias destructivas, valide o incluya en una lista blanca la entrada en el lado del servidor, o realice la operación a través de una ruta que no dependa del formateador del lado del cliente. No existe una bandera de configuración que cambie la selección del escapador en las versiones afectadas; actualizar es la solución fiable.

Nota para proyectos que importan los escapadores directamente. La corrección 3.35.4 cambia la selección del escapador dentro de DefaultParameterFormatter.format(). No cambia _escape_hive en sí, que sigue siendo correcto-para-Hive e incorrecto-para-Trino por diseño. Cualquier proyecto dependiente que importe _escape_hive o _escape_presto desde pyathena.formatter y realice su propio despacho del tipo de sentencia no queda mitigado con la actualización de PyAthena, y debería auditar su propia lógica de despacho frente a la misma cuestión de dialecto.

Cómo comprobar si está afectado:

pip show pyathena          # check the installed version
pip-audit                  # flags CVE-2026-65321 once it propagates to the advisory feeds

Sobre la puntuación CVSS

VulnCheck (la CNA) publicó dos puntuaciones, ambas Críticas: CVSS v4.0 = 9.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) y CVSS v3.1 = 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

El ataque es remoto y no autenticado, sin interacción del usuario (AV:N/PR:N/UI:N) y no requiere precondiciones especiales del lado del atacante (AC:L/AT:N). El impacto en el sistema vulnerable es alto en confidencialidad, integridad y disponibilidad (VC:H/VI:H/VA:H en v4.0; C:H/I:H/A:H en v3.1): un DELETE inyectado puede destruir datos, y un CTAS/UNION SELECT inyectado puede leer y copiar datos a los que el rol del workgroup tiene acceso. En el vector v4.0, las métricas del sistema subsiguiente son todas None (SC:N/SI:N/SA:N); la falla se limita al SQL de Athena y a su frontera de autorización y no permite ejecución de código en el host ni un pivote hacia AWS en sí. Ese trío SC/SI/SA:N es exactamente la razón por la que v4.0 se sitúa en 9.3 en lugar de un 10.0 máximo, y es la respuesta honesta a «¿esto significa un compromiso total del sistema?», no lo significa. La puntuación v3.1 alcanza 9.8 porque su indicador de alcance binario (S:U/S:C) colapsa en un solo bit lo que v4.0 divide en tres métricas separadas del sistema subsiguiente; las dos puntuaciones son consistentes, no contradictorias.

Una advertencia que vale la pena señalar de forma proactiva: la explotabilidad en el mundo real requiere que la aplicación consumidora enrute entrada no confiable hacia una sentencia parametrizada que no sea SELECT (DELETE/CTAS/DROP/ALTER), y el radio de explosión concreto está limitado por los permisos IAM del workgroup de Athena. La puntuación base modela el peor caso razonable; un despliegue con privilegios mínimos se ve afectado con menor severidad.

Cronología de divulgación

Créditos

Descubierta y reportada por Rahul Karne, investigador de seguridad y miembro senior de IEEE. Su investigación se centra en fallas de inyección y manejo de entradas en paquetes de código abierto de alta dependencia; divulgaciones anteriores incluyen CVEs en confluent-kafka (1.12B descargas), datamodel-code-generator (185M) y el plugin de WordPress ElementsKit Elementor Addons (más de 1M instalaciones activas).

Contacto: [email protected] · GitHub: rahulreddykarne

Referencias

• CVE-2026-65321, NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-65321
• Registro CVE: https://www.cve.org/CVERecord?id=CVE-2026-65321
• Aviso de VulnCheck: https://www.vulncheck.com/advisories/pyathena-sql-injection-via-defaultparameterformatter-delete-ctas
• Aviso de seguridad de GitHub: GHSA-xwj5-g6cv-4r5c, https://github.com/pyathena-dev/PyAthena/security/advisories/GHSA-xwj5-g6cv-4r5c
• Commit del parche: https://github.com/pyathena-dev/PyAthena/commit/27901d12245ea722b3b4e211c60e2ade4e7c8efd
• Repositorio de PyAthena: https://github.com/pyathena-dev/PyAthena
• Estadísticas de descargas: https://pepy.tech/projects/pyathena

Prensa

Consultas de medios: [email protected]. Grabación de la demo en alta resolución, PoC y detalles técnicos adicionales disponibles a petición.