Una falla del desarrollador de Amazon Q podría permitir que los repositorios maliciosos ejecuten código a través de configuraciones de MCP
admin Noticias, Trending
Una falla del desarrollador de Amazon Q podría permitir que los repositorios maliciosos ejecuten código a través de configuraciones de MCP

Una falla de alta gravedad en Amazon Q Developer permitió que un repositorio malicioso ejecutara comandos y robara las credenciales de la nube de un desarrollador. El camino fue corto: un desarrollador abre el repositorio, confía en el espacio de trabajo y Amazon Q hace el resto. Amazon lo ha parcheado.

Seguimiento como CVE-2026-12957 (CVSS 8.5), el error radicaba en cómo el asistente de codificación de IA de Amazon manejaba los servidores del Protocolo de contexto modelo (MCP).

Wiz Research, que lo encontró e informó, demostró que un solo archivo de configuración colocado en un repositorio era suficiente para pasar del clon de git al compromiso de la nube.

Cómo funcionó el ataque

Amazon Q leyó un archivo de configuración de MCP, .amazonq/mcp.json, desde el espacio de trabajo abierto e inició los servidores que definió. Los servidores MCP son procesos locales que un asistente de IA puede generar para acceder a bases de datos, API o herramientas de creación, por lo que iniciar uno significa ejecutar comandos en la máquina.

Esos procesos heredaron el entorno completo del desarrollador. Por lo general, eso significa claves de AWS, tokens CLI de la nube, secretos de API y sockets de agente SSH.

Ciberseguridad

Junte los dos y un archivo ubicado en un repositorio clonado podría ejecutar código arbitrario con la sesión en vivo en la nube del desarrollador adjunta. Sin contraseña, sin segundo inicio de sesión.

en su prueba de conceptoWiz hizo que el archivo ejecutara aws sts get-caller-identity y enviara el resultado a un servidor atacante, capturando la sesión activa de AWS. Lo que viene a continuación depende de los permisos en la nube de ese desarrollador: hacer una puerta trasera a un usuario de IAM para lograr persistencia, acceder a servicios internos o girar hacia la producción.

AWS y Wiz enmarcan el paso de consentimiento de manera diferente. Amazonas consultivo dice que el usuario debe confiar en el espacio de trabajo cuando se le solicite, y CVSS califica la interacción del usuario como pasiva.

Wiz informó que no había ningún paso de consentimiento por separado para los servidores MCP antes de la solución. El parche cierra esa brecha: Amazon Q ahora marca un servidor MCP que no es de confianza y permite al desarrollador rechazar el comando antes de que se ejecute.

El defecto vive en Servidores de idiomas para AWSel tiempo de ejecución que impulsa Amazon Q en VS Code, JetBrains, Eclipse y Visual Studio. Los cuatro complementos lo incluyen, por lo que los cuatro quedaron expuestos en versiones que incluían una copia anterior.

que hacer

Actualizar. CVE-2026-12957 está corregido en Language Servers para AWS 1.65.0, pero AWS boletín les dice a los clientes que pasen a 1.69.0.

Esa construcción también cierra un segundo problema, CVE-2026-12958una verificación de enlace simbólico faltante que podría permitir escrituras arbitrarias de archivos fuera del límite de confianza del espacio de trabajo.

Los mínimos del complemento parcheado:

  • Código VS: 2.20 o posterior
  • JetBrains: 4.3 o posterior
  • Eclipse: 2.7.4 o posterior
  • Kit de herramientas de Visual Studio: 1.94.0.0 o posterior

El servidor de idiomas se actualiza automáticamente a menos que la red lo bloquee y al recargar el IDE se obtiene la última versión.

Ciberseguridad

No se conoce ninguna explotación pública; La entrada ADP de CISA para CVE-2026-12957 lo enumera como ninguno. Wiz encontró la falla a través de una investigación y la reveló en coordinación con Amazon, informándola el 20 de abril y viendo una solución el 12 de mayo, antes del informe público del 26 de junio.

Un patrón, no algo único

Amazon Q no es el primer asistente de codificación que tropieza con la confianza de MCP. Los errores no son idénticos, pero riman: la configuración del proyecto se convierte en un comportamiento ejecutable y las comprobaciones de confianza en torno a esa transferencia siguen fallando.

Claude Code (CVE-2025-59536) y Cursor (CVE-2025-54136) tenían una configuración MCP a nivel de proyecto que conducía a la ejecución del comando. windsurf (CVE-2026-30615) llegó al mismo final por una ruta diferente, con contenido controlado por el atacante reescribiendo la configuración de MCP local para registrar un servidor malicioso.

La conveniencia de permitir que una carpeta de proyecto configure un agente de IA también es la superficie de ataque. La configuración transportada por el repositorio es una entrada que no es de confianza. Convertirlo en un proceso en ejecución debería requerir un sí explícito.

Quasar Linux RAT roba credenciales de desarrollador para comprometer la cadena de suministro de software – CYBERDEFENSA.MX
admin Noticias, Trending
Quasar Linux RAT roba credenciales de desarrollador para comprometer la cadena de suministro de software – CYBERDEFENSA.MX

Un implante de Linux previamente indocumentado con nombre en código RAT de Quasar Linux (QLNX) se dirige a los sistemas de los desarrolladores para establecer un punto de apoyo silencioso y facilitar una amplia gama de funciones posteriores al compromiso, como recolección de credenciales, registro de teclas, manipulación de archivos, monitoreo del portapapeles y túneles de red.

«QLNX se dirige a los desarrolladores y a las credenciales de DevOps en toda la cadena de suministro de software», afirman los investigadores de Trend Micro Aliakbar Zahravi y Ahmed Mohamed Ibrahim. dicho en un análisis técnico del malware.

«Su recolector de credenciales extrae secretos de archivos de alto valor como .npmrc (tokens npm), .pypirc (credenciales PyPI), .git-credentials, .aws/credentials, .kube/config, .docker/config.json, .vault-token, credenciales Terraform, tokens CLI de GitHub y archivos .env. El compromiso de estos activos podría permitir al operador impulsar archivos maliciosos paquetes a registros NPM o PyPI, acceder a la infraestructura de la nube o pasar a través de canalizaciones de CI/CD».

Ciberseguridad

La capacidad del malware para recopilar sistemáticamente una amplia gama de credenciales plantea un grave riesgo para los entornos de desarrollo. Un actor de amenazas que implementa QLNX con éxito contra un mantenedor de paquetes obtiene acceso no autorizado a su canal de publicación, lo que permite al atacante impulsar versiones envenenadas que pueden provocar impactos posteriores en cascada.

QLNX se ejecuta sin archivos desde la memoria, se hace pasar por un subproceso del kernel (por ejemplo, kworker o ksoftirqd) y es capaz de crear perfiles del host para detectar entornos en contenedores, borrar registros del sistema para cubrir las pistas y configurar la persistencia utilizando no menos de siete métodos diferentes, incluidos systemd, crontab y .bashrc shell injection.

Además, extrae los datos recopilados a una infraestructura controlada por el atacante y recibe comandos que permiten ejecutar comandos de shell, administrar archivos, inyectar código en procesos, tomar capturas de pantalla, registrar pulsaciones de teclas, establecer servidores proxy SOCKS y túneles TCP, ejecutar archivos de objetos Beacon (BOF) e incluso administrar una red de malla peer-to-peer (P2P).

No está claro exactamente cómo se distribuye el malware. Sin embargo, una vez que se establece un punto de apoyo, ingresa a una fase operativa primaria al ejecutar un bucle persistente que intenta continuamente establecer y mantener la comunicación con el servidor de comando y control (C2) a través de TCP, HTTPS y HTTP sin formato. En total, QLNX admite 58 comandos distintos que brindan a los operadores un control total del host comprometido.

QLNX también viene con una puerta trasera de gancho en línea del Módulo de autenticación conectable (PAM) que intercepta las credenciales de texto sin formato durante los eventos de autenticación, registra los datos de la sesión SSH saliente y transmite los datos al servidor C2. El malware también admite un segundo registrador de credenciales basado en PAM que se carga automáticamente en cada proceso vinculado dinámicamente para extraer el nombre del servicio, el nombre de usuario y el token de autenticación.

Ciberseguridad

Emplea una arquitectura de rootkit de dos niveles: un rootkit de usuario implementado a través del mecanismo LD_PRELOAD del vinculador dinámico de Linux para garantizar que los artefactos y procesos del implante permanezcan ocultos. También existe un componente eBPF a nivel de kernel que utiliza el subsistema BPF para ocultar procesos, archivos y puertos de red de herramientas estándar del usuario como ps, ls y netstat al recibir instrucciones del servidor C2.

«El implante QLNX fue construido para el robo de credenciales y sigilo a largo plazo», dijo Trend Micro. «Lo que lo hace particularmente peligroso no es una sola característica, sino cómo sus capacidades se encadenan en un flujo de trabajo de ataque coherente: llegar, borrar del disco, persistir a través de seis mecanismos redundantes, ocultarse tanto en el espacio de usuario como en el nivel del kernel, y luego recolectar las credenciales que más importan».

Un gusano autopropagante de la cadena de suministro secuestra paquetes npm para robar tokens de desarrollador – CYBERDEFENSA.MX
admin Noticias, Trending
Un gusano autopropagante de la cadena de suministro secuestra paquetes npm para robar tokens de desarrollador – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han detectado un nuevo conjunto de paquetes que han sido comprometidos por malos actores para entregar un gusano autopropagante que se propaga a través de tokens npm de desarrollador robados.

El gusano de la cadena de suministro ha sido detectado por ambos Enchufe y PasoSeguridadcon las empresas rastreando la actividad bajo el nombre RecipienteExpansión debido al uso de un recipiente de PIC para exfiltrar los datos robados, en una táctica que recuerda al CanisterWorm de TeamPCP para hacer que la infraestructura sea resistente a los derribos.

La lista de paquetes afectados se encuentra a continuación:

  • @automagik/genie (4.260421.33 – 4.260421.40)
  • @fairwords/loopback-connector-es (1.4.3 – 1.4.4)
  • @fairwords/websocket (1.0.38 – 1.0.39)
  • @openwebconcept/design-tokens (1.0.1 – 1.0.3)
  • @openwebconcept/tema-owc (1.0.1 – 1.0.3)
  • pgserve (1.1.11 – 1.1.14)

El malware se activa durante el tiempo de instalación a través de un enlace posterior a la instalación para robar credenciales y secretos de los entornos de desarrollo, y luego aprovecha los tokens npm robados para enviar versiones envenenadas de los paquetes al registro con un nuevo enlace posterior a la instalación malicioso para ampliar el alcance de la campaña.

Ciberseguridad

La información capturada incluye:

  • .npmrc
  • Claves SSH y configuraciones SSH
  • .git-credenciales
  • .netrc
  • credenciales de nube para Amazon Web Services, Google Cloud y Microsoft Azure
  • Configuraciones de Kubernetes y Docker
  • Material de Terraform, Pulumi y Vault
  • Archivos de contraseña de base de datos
  • Archivos .env* locales
  • Archivos de historial de Shell

Además, intenta acceder a credenciales de navegadores web basados ​​en Chromium y a datos asociados con aplicaciones de extensión de billeteras de criptomonedas. La información se extrae a un webhook HTTPS («telemetry.api-monitor[.]com») y un recipiente ICP («cjn37-uyaaa-aaaac-qgnva-cai.raw.icp0[.]io»).

«También contiene lógica de propagación PyPI», dijo Socket. «El script genera una carga útil basada en Python .pth diseñada para ejecutarse cuando se inicia Python, luego prepara y carga paquetes Python maliciosos con Twine si las credenciales requeridas están presentes».

«En otras palabras, esto no es sólo un ladrón de credenciales. Está diseñado para convertir un entorno de desarrollador comprometido en compromisos de paquetes adicionales».

La divulgación se produce cuando JFrog reveló que varias versiones del paquete legítimo de Python «xinference» (2.6.0, 2.6.1 y 2.6.2) han sido comprometidas para incluir una carga útil codificada en Base64 que recupera un módulo recopilador de segunda etapa responsable de recolectar una amplia gama de credenciales y secretos del host infectado.

«La carga útil decodificada se abre con el comentario ‘# hackeado por teampcp’, el mismo marcador de actor visto en compromisos recientes de TeamPCP», dijo la compañía. dicho. Sin embargo, en una publicación compartida en X, TeamPCP cuestionadoestaban detrás del compromiso y afirmaron que era obra de un imitador.

Ataques dirigidos a npm y PyPI

Los hallazgos son las últimas incorporaciones a una larga lista de ataques dirigidos al ecosistema de código abierto. Esto incluye dos paquetes maliciosos, cada uno en npm (kube-health-tools) y PyPI (kube-node-health), que se hacen pasar por utilidades de Kubernetes, pero instalan silenciosamente un binario basado en Go para establecer un proxy SOCKS5, un proxy inverso, un servidor SFTP y un proxy de modelo de lenguaje grande (LLM) en la máquina de la víctima.

El proxy LLM es una puerta de enlace API compatible con OpenAI que acepta solicitudes y las enruta a API ascendentes, incluidos enrutadores LLM chinos como shubiaobiao.

«Más allá de proporcionar acceso barato a la IA, los enrutadores LLM como el implementado aquí se encuentran en un límite de confianza del que se puede abusar fácilmente», Ilyas Makari, investigador de Aikido Security dicho. «Debido a que cada solicitud pasa a través del enrutador en texto plano, un operador malintencionado puede […] inyecta llamadas de herramientas maliciosas en las respuestas de los agentes de codificación antes de que lleguen al cliente, introduciendo instalaciones maliciosas de pip o curl | cargas útiles de bash en pleno vuelo.»

Alternativamente, el enrutador se puede utilizar para extraer secretos de los cuerpos de solicitud y respuesta, incluidas claves API, credenciales de AWS, tokens de GitHub, claves privadas de Ethereum y mensajes del sistema.

Otra campaña sostenida de ataque a la cadena de suministro de npm documentado by Panther se ha hecho pasar por el proveedor de seguros telefónicos Asurion y sus subsidiarias, publicando paquetes maliciosos (sbxapps, asurion-hub-web, soluto-home-web y asurion-core) del 1 al 8 de abril de 2026, que contienen un recolector de credenciales de múltiples etapas.

Ciberseguridad

Las credenciales robadas fueron exfiltradas inicialmente a un webhook de Slack y luego a un punto final de AWS API Gateway («pbyi76s0e9.execute-api.us-east-1.amazonaws[.]com»). Para el 7 de abril, se dice que la URL de exfiltración de AWS se ha ofuscado utilizando la codificación XOR.

Por último, pero no menos importante, Wiz, la empresa de seguridad en la nube propiedad de Google. arrojar luz en una campaña impulsada por inteligencia artificial (IA) denominada prt-scan que ha explotado sistemáticamente el activador del flujo de trabajo de GitHub Actions «pull_request_target» desde el 11 de marzo de 2026, para robar secretos de los desarrolladores.

Se ha descubierto que el atacante, que opera con las cuentas testingbefore, beforetested-boop, 420tb, 69tf420, elzotebo y ezmtebo, busca repositorios usando el activador, bifurca esos repositorios, crea una rama con una convención de nomenclatura predefinida (es decir, prt-scan-{12-hex-chars}), inyecta una carga útil maliciosa en un archivo que se ejecuta durante la CI, abre un pull solicitar y luego robar las credenciales del desarrollador cuando se activa el flujo de trabajo y publicar una versión del paquete malicioso si se descubren tokens npm.

«En más de 450 intentos de explotación analizados, hemos observado una tasa de éxito <10%», dijeron los investigadores de Wiz. «En la mayoría de los casos, los ataques exitosos fueron contra pequeños proyectos de aficionados y solo expusieron credenciales efímeras de GitHub para el flujo de trabajo. En su mayor parte, esta campaña no otorgó al atacante acceso a la infraestructura de producción, credenciales de la nube o claves API persistentes, salvo excepciones menores».

«La campaña demuestra que, si bien las vulnerabilidades pull_request_target siguen siendo explotables a escala, las prácticas modernas de seguridad de CI/CD, en particular los requisitos de aprobación de los contribuyentes, son efectivas para proteger repositorios de alto perfil».

UNC4899 infringió una empresa de cifrado después de que un desarrollador lanzara por aire un archivo troyanizado al dispositivo de trabajo
admin Noticias, Trending
UNC4899 infringió una empresa de cifrado después de que un desarrollador lanzara por aire un archivo troyanizado al dispositivo de trabajo

El actor de amenazas norcoreano conocido como UNC4899 Se sospecha que está detrás de una sofisticada campaña de compromiso en la nube dirigida a una organización de criptomonedas en 2025 para robar millones de dólares en criptomonedas.

La actividad se ha atribuido con moderada confianza al adversario patrocinado por el estado, al que también se le rastrea bajo los criptoónimos Jade Sleet, PUKCHONG, Slow Pisces y TraderTraitor.

«Este incidente se destaca por su combinación de ingeniería social, explotación de mecanismos de transferencia de datos entre pares (P2P) de dispositivos personales a corporativos, flujos de trabajo y eventual giro a la nube para emplear técnicas de vivir fuera de la nube (LOTC)», señaló el gigante tecnológico en su informe. Informe sobre horizontes de amenazas en la nube del primer semestre de 2026 [PDF] compartido con The Hacker News.

Al obtener acceso al entorno de la nube, se dice que los atacantes abusaron de los flujos de trabajo legítimos de DevOps para recopilar credenciales, romper los límites de los contenedores y alterar las bases de datos de Cloud SQL para facilitar el robo de criptomonedas.

Ciberseguridad

La cadena de ataque, dijo Google Cloud, representa una progresión de lo que comenzó con el compromiso del dispositivo personal de un desarrollador en su estación de trabajo corporativa, antes de saltar a la nube para realizar modificaciones no autorizadas a la lógica financiera.

Todo comenzó cuando los actores de amenazas utilizaron estrategias de ingeniería social para engañar al desarrollador para que descargara un archivo como parte de una supuesta colaboración en un proyecto de código abierto. Luego, el desarrollador transfirió el mismo archivo al dispositivo de su empresa a través de AirDrop.

«Utilizando su entorno de desarrollo integrado (IDE) asistido por IA, la víctima interactuó con el contenido del archivo y finalmente ejecutó el código Python malicioso incrustado, que generó y ejecutó un binario que se hacía pasar por la herramienta de línea de comandos de Kubernetes», dijo Google.

Luego, el binario se puso en contacto con un dominio controlado por el atacante y actuó como una puerta trasera para la máquina corporativa de la víctima, brindando a los atacantes una forma de pasar al entorno de Google Cloud probablemente usando sesiones autenticadas y credenciales disponibles. A este paso le siguió una fase inicial de reconocimiento destinada a recopilar información sobre diversos servicios y proyectos.

El ataque pasó a la siguiente fase con el descubrimiento de un anfitrión bastióncon el adversario modificando su atributo de política de autenticación multifactor (MFA) para acceder a él y realizar reconocimiento adicional, incluida la navegación a pods específicos dentro del entorno de Kubernetes.

Posteriormente, UNC4899 adoptó un enfoque de vivir fuera de la nube (LotC) para configurar mecanismos de persistencia alterando las configuraciones de implementación de Kubernetes para ejecutar un comando bash automáticamente cuando se crean nuevos pods. El comando, por su parte, descargaba una puerta trasera.

Algunos de los otros pasos llevados a cabo por el actor de amenazas se enumeran a continuación:

  • Los recursos de Kubernetes vinculados a la solución de plataforma CI/CD de la víctima se modificaron para inyectar comandos que mostraban los tokens de la cuenta de servicio en los registros.
  • El atacante obtuvo un token para una cuenta de servicio CI/CD con altos privilegios, lo que le permitió escalar sus privilegios y realizar movimientos laterales, apuntando específicamente a un módulo que manejaba políticas de red y equilibrio de carga.
  • El token de la cuenta de servicio robado se utilizó para autenticarse en el pod de infraestructura confidencial que se ejecuta en modo privilegiado, escapar del contenedor e implementar una puerta trasera para acceso persistente.
  • El actor de amenazas llevó a cabo otra ronda de reconocimiento antes de centrar su atención en una carga de trabajo responsable de administrar la información del cliente, como las identidades de los usuarios, la seguridad de la cuenta y la información de la billetera de criptomonedas.
  • El atacante lo usó para extraer credenciales de bases de datos estáticas que estaban almacenadas de forma insegura en las variables de entorno del pod.
  • Luego se abusó de las credenciales para acceder a la base de datos de producción a través de Cloud SQL Auth Proxy y ejecutar comandos SQL para realizar modificaciones en la cuenta de usuario. Esto incluyó restablecimientos de contraseñas y actualizaciones de semillas de MFA para varias cuentas de alto valor.
  • El ataque culminó con el uso de cuentas comprometidas para retirar con éxito varios millones de dólares en activos digitales.
Ciberseguridad

El incidente «destaca los riesgos críticos planteados por los métodos de transferencia de datos P2P de persona a empresa y otros puentes de datos, modos de contenedores privilegiados y el manejo no seguro de secretos en un entorno de nube», dijo Google. «Las organizaciones deben adoptar una estrategia de defensa en profundidad que valide rigurosamente la identidad, restrinja la transferencia de datos en los puntos finales y aplique un aislamiento estricto dentro de los entornos de ejecución de la nube para limitar el radio de explosión de un evento de intrusión».

Para contrarrestar la amenaza, se recomienda a las organizaciones implementar acceso contextual y MFA resistente al phishing, asegurarse de que solo se implementen imágenes confiables, aislar los nodos comprometidos para que no establezcan conectividad con hosts externos, monitorear procesos de contenedores inesperados, adoptar una gestión sólida de secretos, aplicar políticas para deshabilitar o restringir el intercambio de archivos entre pares mediante AirDrop o Bluetooth y montar medios externos no administrados en dispositivos corporativos.