Paquete open source malicioso robó credenciales en 2026

El 25 de abril de 2026, un atacante desconocido publicó la versión 0.23.3 de elementary-data, un paquete open source malicioso que robó credenciales de todos los sistemas donde se ejecutó. El paquete tenía más de 1 millón de descargas mensuales en PyPI y estuvo activo alrededor de 12 horas antes de ser removido.

El compromiso de elementary-data 0.23.3: qué sucedió

Elementary-data es una herramienta de línea de comandos open source para monitoreo de performance y detección de anomalías en sistemas de machine learning, distribuida principalmente a través de PyPI. Con más de 1 millón de descargas mensuales, es infraestructura crítica para equipos de data engineering.

El viernes 25 de abril de 2026, atacantes desconocidos lograron publicar la versión 0.23.3 tanto en PyPI como en Docker Hub. Esta versión incluía código malicioso que, al ejecutarse, escaneaba el sistema en busca de credenciales sensibles. Según el reporte de Ars Technica, el paquete malicioso estuvo disponible alrededor de 12 horas antes de ser detectado y removido el sábado.

Los propios desarrolladores comunicaron: “Los usuarios que instalaron la versión 0.23.3, o que descargaron y ejecutaron el Docker image afectado, deben asumir que cualquier credencial accesible en el entorno donde se ejecutó puede haber sido expuesta.”

Dicho esto, no todo el ecosistema de Elementary estuvo en riesgo. Elementary Cloud, el paquete Elementary dbt y todas las demás versiones del CLI quedaron fuera del alcance del ataque.

Cómo los atacantes explotaron GitHub Actions

Acá viene la parte técnica que más le debería importar a cualquier equipo que mantiene paquetes open source.

El vector de entrada no fue una vulnerabilidad en el código de Elementary en sí, sino en el workflow de GitHub Actions que el proyecto usaba para automatizar la publicación. Los atacantes postearon código malicioso en un pull request, y ese PR era suficiente para disparar el workflow con permisos elevados. El bash script que corrió dentro del ambiente del desarrollador fue el que hizo el trabajo sucio: extraer tokens de firma y claves de publicación. Sobre eso hablamos en optimizar para múltiples idiomas.

Con esas signing keys en mano (y los tokens de PyPI y Docker Hub), el atacante pudo publicar la versión 0.23.3 como si fuera una release legítima del proyecto. Externamente era indistinguible de una versión real.

El patrón se repite. Es el mismo vector que ya vimos en ataques de supply chain anteriores: pull_request_target con permisos amplios en lugar de pull_request con permisos restringidos. ¿Alguien revisó si su propio proyecto tiene esta configuración? Probablemente no.

Qué datos fueron robados en el ataque

Ponele que tu equipo de datos corrió pip install elementary-data==0.23.3 el viernes a la tarde. El script malicioso que vino dentro de ese paquete no preguntó permiso: empezó a escanear variables de entorno, archivos de configuración y perfiles del sistema buscando patrones que coincidieran con credenciales.

Las categorías afectadas fueron:

• Warehouse credentials: credenciales de Snowflake, BigQuery, Redshift y otros data warehouses
• Cloud provider keys: claves de acceso de AWS, Azure y GCP presentes en el entorno
• API tokens: tokens de servicios externos configurados como variables de entorno
• SSH keys: claves privadas accesibles en el entorno de ejecución
• User profiles: perfiles de usuario y configuraciones locales

El scanner no era selectivo. Buscaba el mayor volumen posible de credenciales en el menor tiempo posible, lo cual es exactamente lo que esperarías de un ataque de exfiltración oportunista.

Quién fue afectado y cuál es el riesgo real

El riesgo no es uniforme para todos.

Si ejecutaste la versión 0.23.3 en un entorno de desarrollo local sin credenciales de producción configuradas, probablemente el impacto sea bajo. Si la corriste en un pipeline de CI/CD con acceso a tu data warehouse de producción, tus claves de AWS y tu token de Snowflake, el riesgo es alto y el daño potencial es proporcional a eso.

Los más expuestos son los equipos de data engineering que tienen Elementary corriendo en pipelines automatizados, donde las credenciales de producción están cargadas como variables de entorno o archivos de configuración. Esos entornos suelen tener acceso amplio porque “así funciona la integración”. En auditar la seguridad de WordPress profundizamos sobre esto.

Cómo detectar si instalaste la versión maliciosa

La fecha crítica es el viernes 25 y el sábado 26 de abril de 2026. Si instalaste o actualizaste elementary-data en esa ventana, el primer paso es verificar qué versión tenés.

En tu entorno Python

Ejecutá pip show elementary-data y fijate en el campo Version. Si dice 0.23.3, estás en el rango afectado. También podés revisar tu requirements.txt o requirements.lock para ver si esa versión quedó pineada.

En Docker

Si corriste el Docker image de Elementary el 25-26 de abril, revisá el hash de la imagen que descargaste. Los desarrolladores deberían publicar los hashes de las versiones legítimas para comparar. Si el hash no coincide con ninguna versión oficial o si simplemente descargaste el latest en esa ventana, asumí compromiso.

En pipelines de CI/CD

Revisá los logs de tus pipelines del viernes y sábado. Buscá cualquier ejecución de elementary-data en esas fechas y cruzala con la versión instalada en ese run específico.

Acciones inmediatas si fuiste afectado

Sin vueltas. Si instalaste 0.23.3 o corriste el Docker image afectado, el checklist es este:

• Rotar claves de AWS: invalidar access keys existentes desde la consola IAM y generar nuevas
• Rotar credenciales de Azure y GCP: revocar service accounts y credenciales presentes en el entorno
• Regenerar tokens de data warehouse: Snowflake, BigQuery, Redshift, cualquier herramienta con credenciales en el entorno
• Revocar SSH keys: especialmente las que tienen acceso a servidores de producción
• Revisar API tokens: cualquier token de servicio externo que estuviera en variables de entorno
• Auditar publicaciones en registries: revisar si hubo actividad no autorizada en PyPI, npm, Docker Hub u otros registries asociados a tu cuenta
• Revisar logs de acceso: buscar actividad inusual en los servicios a los que las credenciales comprometidas tenían acceso

La rotación tiene que ser rápida. Cada hora que pasa con credenciales comprometidas activas es tiempo que el atacante puede usar. Esto se conecta con lo que analizamos en herramientas seguras para Elementor.

Defensa contra futuros ataques de paquete open source malicioso

Este ataque fue evitable. No con magia, sino con configuraciones básicas que muchos equipos postergan.

El punto crítico acá es el de GitHub Actions. Según el análisis de Chainguard, la vulnerabilidad explotada es un patrón conocido y documentado. El repositorio ossf/malicious-packages de la OpenSSF lleva registro de este tipo de ataques y es una referencia que cualquier equipo de seguridad debería tener en el radar.

Para los que manejan infraestructura web o almacenamiento en la nube, vale mencionar que los proveedores de hosting también son parte del ecosistema. Si tu pipeline de datos corre en servidores propios, tanto los entornos como las credenciales de acceso a esos servidores entran en la categoría de “rotar si hubo compromiso”.

Errores comunes al responder este tipo de incidentes

Error 1: Solo actualizar la versión sin rotar credenciales. Instalar una versión limpia de elementary-data no deshace el daño. Si el paquete malicioso ya corrió, las credenciales que accedió ya están expuestas, independientemente de qué versión tengas ahora.

Error 2: Asumir que “solo fue en dev” significa cero riesgo. Los entornos de desarrollo suelen tener credenciales de producción configuradas “temporalmente” que nunca se removieron. Revisá qué acceso real tenía el entorno antes de asumir que estás limpio.

Error 3: Rotar solo las credenciales “obvias” y olvidar los API tokens. Los tokens de servicios menos críticos son exactamente lo que un atacante usa para moverse lateralmente o para accesos persistentes. Rotá todo lo que estuviera en el entorno, sin excepciones.

Preguntas Frecuentes

¿Qué pasó exactamente con elementary-data 0.23.3?

El 25 de abril de 2026, un atacante explotó una vulnerabilidad en el GitHub Actions workflow del proyecto y obtuvo las signing keys de publicación. Con esas claves publicó la versión 0.23.3 en PyPI y Docker Hub, que incluía código malicioso para extraer credenciales de los sistemas donde se ejecutara. El paquete estuvo disponible alrededor de 12 horas antes de ser removido. Te puede servir nuestra cobertura de proteger tu hosting y dominio.

¿Cómo sé si fui afectado por el paquete malicioso?

Ejecutá pip show elementary-data y verificá si la versión instalada es la 0.23.3. Si instalaste o actualizaste el paquete entre el 25 y 26 de abril de 2026, o si corriste el Docker image en esas fechas, tenés que asumir que el entorno estuvo expuesto. Revisá también los logs de tus pipelines de CI/CD para ese rango de fechas.

¿Qué credenciales fueron robadas en el ataque?

El código malicioso buscaba warehouse credentials (Snowflake, BigQuery, Redshift), claves de proveedores cloud (AWS, Azure, GCP), API tokens, SSH keys y perfiles de usuario que estuvieran accesibles en el entorno de ejecución. El alcance real del robo depende de qué credenciales tenía disponibles cada entorno específico.

¿Qué debo hacer si tengo este paquete instalado?

Lo primero es actualizar a una versión limpia (cualquier versión distinta de 0.23.3). Luego, rotar todas las credenciales que estuvieran accesibles en el entorno donde corrió el paquete: claves de cloud, tokens de data warehouse, SSH keys y cualquier API token configurado como variable de entorno. La rotación es obligatoria aunque no veas actividad sospechosa.

¿Cómo protegerme de ataques de supply chain similares?

Las medidas más efectivas son: usar pull_request en lugar de pull_request_target en GitHub Actions, activar 2FA en todos los registries de publicación (PyPI, npm, Docker Hub), pinear versiones exactas en lock files, y usar herramientas de análisis de composición de software (SCA) para detectar dependencias comprometidas. La segregación de entornos dev/prod limita el daño si un entorno se ve comprometido.

Conclusión

El ataque a elementary-data 0.23.3 es un recordatorio concreto de que el supply chain de software open source es un vector de ataque activo. No fue un exploit sofisticado de día cero: fue una configuración descuidada de GitHub Actions que le dio a un atacante todo lo que necesitaba para publicar código malicioso como si fuera una release legítima.

Si usás paquetes open source en pipelines con credenciales de producción (y casi todos los equipos de datos lo hacen), este incidente es el mejor argumento posible para revisar esas configuraciones ahora. El costo de hacerlo es bajo. El costo de no haberlo hecho, si aparece en tu entorno el próximo ataque de este tipo, es alto.

El equipo de Elementary respondió con transparencia y rapidez. Eso no cambia que cualquier usuario que corrió 0.23.3 tiene trabajo por hacer. Empezá por rotar credenciales y después revisá cómo proteger tu propio supply chain.

Fuentes

• Ars Technica – Open source package with 1M downloads stole user credentials
• Chainguard – Análisis del compromiso de elementary-data
• OpenSSF – Repositorio de paquetes maliciosos (ossf/malicious-packages)