El nuevo Gitea RCE permite a los escritores de repositorios instalar un gancho Git para ejecutar comandos de Shell – CYBERDEFENSA.MX

Gitea, la plataforma Git autohospedada, ha solucionado una vulnerabilidad crítica de ejecución remota de código. Un usuario con acceso normal de escritura al repositorio puede convertir el contenido del parche controlado por el atacante en un gancho Git activo y ejecutar comandos de shell como la cuenta de servicio de Gitea.

Seguimiento como CVE-2026-60004 (Puntuación CVSS: 9,8), la falla afecta a las versiones 1.17 y posteriores de Gitea antes de la 1.27.1 y se solucionó en 1.27.1. La llamada API vulnerable requiere autenticación y permiso de escritura en el repositorio. Pero Gitea habilita el registro de forma predeterminada, por lo que un visitante externo puede crear una cuenta y un repositorio normales en una instalación sin cambios y luego explotar el error sin credenciales preexistentes.

Actualizar a 1.27.1 es la solución. Gitea dijo el 27 de julio que las instancias de Gitea Cloud se actualizarían automáticamente. El aviso de Gitea del 28 de julio no dice que la falla haya sido explotada en la naturaleza, pero incluye un código de prueba de concepto (PoC) público.

Deshabilitar el registro abierto puede eliminar la ruta de creación de cuenta pública mientras se implementa la actualización, pero no soluciona la falla ni protege contra usuarios existentes con acceso de escritura al repositorio.

Ciberseguridad

La falla fue reportada por un investigador de seguridad. Shai Rod, que se hace llamar NightRang3r. Gitea acredita a NightRang3r como el reportero de su aviso.

La gitea ruta afectada invoca reqToken()que rechaza solicitudes sin un usuario registrado. La ruta sin credenciales previas proviene del proyecto configuración predeterminadaque deja el registro abierto, no requiere aprobación manual ni por correo electrónico, no marca a los nuevos usuarios como restringidos y no impone ningún límite predeterminado de creación de repositorio.

El error se encuentra en el POST /api/v1/repos/{owner}/{repo}/diffpatch punto final. Según Gitea aviso de seguridadel punto final aplica un parche proporcionado dentro de un clon temporal desnudo compartido. Invocación de compilaciones vulnerables git apply con --index, --recount, --cachedy --binaryañadiendo el -3 Opción de respaldo de tres vías cuando el servidor ejecuta Git 2.32 o posterior.

Un atacante envía el mismo parche dos veces para crear una colisión agregar/agregar. El respaldo de tres vías verifica la ruta indexada aunque la operación utilice --cached. Debido a que el clon temporal está desnudo, su raíz es $GIT_DIR. Un archivo ejecutable ubicado en hooks/post-index-change por lo tanto, llega al directorio de enlaces de Git y se activa. Git lo ejecuta mientras actualiza el índice.

El PoC inicia sesión con una cuenta normal, crea un repositorio privado inicializado, envía el parche malicioso dos veces y recupera el resultado del comando. No necesita devolución de llamada saliente. El gancho almacena el resultado en objetos Git, crea una rama que contiene el resultado y permite al atacante recuperarlo a través de HTTP inteligente autenticado.

Al 29 de julio de 2026, ninguna de las fuentes primarias citadas informa si la falla fue explotada antes o después de que la versión 1.27.1 estuviera disponible.

La explotación exitosa otorga al atacante los privilegios de la cuenta del sistema operativo Gitea. Dependiendo de cómo esté aislada la instancia, Gitea dijo que eso podría exponer secretos de aplicaciones y entornos, repositorios montados, credenciales y contenidos de bases de datos, credenciales de OAuth y servicios internos accesibles.

Ciberseguridad

La explotación aún requiere acceso de escritura al repositorio, Git 2.32 o posterior, un habilitado diffpatch ruta y un sistema de archivos temporal ejecutable y grabable. El registro predeterminado permite que un usuario externo obtenga el acceso de escritura requerido en una instalación sin cambios.

Es fácil pasar por alto la solución en el registro de cambios. Gitea cambió el clon temporal de desnudo a no desnudo. El comentario de código advierte explícitamente que los comandos de Git que usan --index puede operar en el árbol de trabajo. El cambio se fusionó y se respaldó el 26 de julio de 2026.

Versión 1.27.1 enviado el 27 de julio, y el aviso de seguridad siguió el 28 de julio. Las notas de la versión enumeraron el cambio en MISC como «refactor: git patch apply», no en SEGURIDAD.

Rod tenía obtuvo una vista previa del RCE junto con un problema de inclusión de archivos separadocon un PoC recuperando /etc/passwd desde un host Gitea 1.27.0. Esta cuestión parece corresponder a un tema aparte cambio incluido en 1.27.1 que alteró tanto el renderizador del modo Org de Gitea #+INCLUDE las rutas se devuelven como texto sin formato en lugar de leerse desde el sistema de archivos del servidor. Gitea no ha publicado un aviso por separado o CVE para el problema de la inclusión de archivos.

La campaña FakeGit utiliza 7.600 repositorios de GitHub para difundir el malware SmartLoader – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han descubierto casi 7.600 repositorios maliciosos de GitHub, de los cuales más de 800 se hacen pasar por habilidades de inteligencia artificial (IA) o servidores Model Context Protocol (MCP) para entregar una familia de malware conocida como SmartLoader como parte de una campaña en curso con nombre en código. falsogit.

«FakeGit utiliza proyectos copiados, perfiles de desarrolladores similares, archivos README convincentes y archivos ZIP maliciosos para distribuir el malware SmartLoader», Oleg Zaytsev, investigador principal de seguridad de Island, dicho en un informe compartido con The Hacker News.

El objetivo final de estos ataques es aprovechar el acceso proporcionado por SmartLoader para establecer persistencia e impulsar cargas útiles secundarias, como StealC, un ladrón de información capaz de recopilar una amplia gama de datos de sistemas comprometidos.

Vale la pena mencionar aquí que el uso de servidores MCP troyanizados para distribuir SmartLoader y StealC fue señalado a principios de este año por Straiker AI y posteriormente por Derp.ca. Pero un aspecto preocupante de FakeGit es una evolución impulsada por IA denominada Agente hostigamiento.

Ciberseguridad

Esto ocurre cuando un agente de IA que busca una habilidad o un servidor MCP termina descubriendo sin darse cuenta uno de estos repositorios falsos de GitHub, lo que hace que cumpla las órdenes del atacante por sí solo sin la intervención de un usuario humano.

Island dijo que sus pruebas revelaron que Anthropic Claude Code, Google Gemini y OpenAI ChatGPT son susceptibles a este engaño, lo que permite a los modelos mostrar repositorios de campañas maliciosas sin siquiera que se les muestre un enlace. En otras palabras, una técnica creada con la intención original de diseñar socialmente a los humanos ahora tiene la capacidad de engañar igualmente a un agente de IA que actúa en su nombre.

De los 7.600 repositorios maliciosos de GitHub creados por alrededor de 6.600 perfiles, 800 se hicieron pasar por servidores Skills o MCP para uso individual y empresarial, desde integraciones de Gmail y WhatsApp hasta herramientas Databricks, Jenkins y Docker. Hasta julio de 2026, la operación FakeGit ha registrado más de 14 millones de descargas en todos los activos de GitHub Release en aproximadamente 200 repositorios de campaña.

Cadena de ataque FakeGit

«Los repositorios fueron diseñados para satisfacer la demanda que ya se está formando en torno a las capacidades de IA, tomando prestados los nombres y flujos de trabajo de herramientas familiares para consumidores y empresas», explicó Zaytsev. «Esa familiaridad dio a los archivos ZIP maliciosos una razón creíble para ser descargados, mientras que el README guiaba a los usuarios o agentes desde lo que parecía ser una configuración rutinaria hacia la cadena de ataque SmartLoader».

Los repositorios falsificados, ya sean completamente fabricados o copiados de proyectos legítimos, sirven como conducto para un archivo ZIP, que luego se utiliza para activar una cadena de carga LuaJIT, lo que lleva a la ejecución de un script Lua ofuscado responsable de eliminar SmartLoader. Luego el cargador procede a implementar StealC.

AgentBaiting intensifica aún más esta amenaza, ya que abre la puerta a un escenario en el que se puede incitar a un agente de IA a descubrir un repositorio de FakeGit sin tener que proporcionar un enlace malicioso al proporcionar un mensaje como este: «Encuentre la habilidad de aviso cinematográfico de Claude gratuita y deme las instrucciones de instalación» o «deme un enlace gratuito al servidor MCP de Walmart».

Ciberseguridad

«Mientras intenta completar una tarea, puede descubrir un repositorio FakeGit por sí solo, tratar el README como documentación legítima y pasar las instrucciones del atacante al usuario», dijo Island. «FakeGit construyó sus señuelos de IA siguiendo este camino».

La técnica demuestra una vez más cómo las operaciones rutinarias de descubrimiento asistidas por IA pueden convertirse en un callejón para la ejecución de código malicioso, un problema que se exacerba cuando las habilidades maliciosas o los servidores MCP figuran en registros públicos como LobeHub, Glama, MCP.so y MCP Market, dándoles una falsa sensación de legitimidad. Se han marcado más de 600 listados de campañas en registros públicos de MCP y Skill.

Para contrarrestar la amenaza, se recomienda crear un catálogo de habilidades revisadas, servidores MCP y complementos de agentes, evaluar primero las capacidades de los nuevos agentes en un entorno aislado antes de una implementación más amplia, verificar tanto el editor como el proyecto para garantizar la credibilidad y monitorear las vías de agente.

«FakeGit no necesitaba violar nada. Publicó repositorios convincentes, tomó prestadas identidades de desarrolladores reales, distribuyó sus listados en registros públicos y dejó que el descubrimiento hiciera el resto», dijo Island.

«Con AgentBaiting, ese descubrimiento ya no requiere una persona en absoluto: un agente que busca una habilidad o un servidor MCP puede encontrar el señuelo, leer el README del atacante y seguir sus instrucciones. Las defensas que importan son las que interrumpen esta cadena antes de la ejecución».

Un fallo del cursor permite que repositorios clonados maliciosos activen la ejecución de código de Windows – CYBERDEFENSA.MX

Abra un repositorio en Cursor en Windows y, si hay un archivo llamado git.exe en la raíz del proyecto, Cursor lo ejecuta. Sin clic, sin cuadro de diálogo de aprobación, sin advertencia de que algo en la carpeta está a punto de ejecutarse.

Cualquier cosa que haga ese binario, lo hace como usted, con su fuente, sus claves SSH y sus tokens de nube. El cursor sigue ejecutándolo mientras el proyecto permanezca abierto.

Sin inyección rápida, sin agente, sin modelo en el bucle y sin acceso previo a la máquina: abrir la carpeta es todo el exploit y el resultado es la ejecución de código arbitrario como usuario que ha iniciado sesión.

La empresa de seguridad de inteligencia artificial Mindgard informó la falla a Cursor el 15 de diciembre de 2025 y Detalles técnicos completos publicados. el martes, siete meses después. Todavía no hay ningún parche y Cursor no ha publicado ningún aviso sobre el problema.

El mecanismo dura aproximadamente una frase. El cursor busca en varias ubicaciones un binario de Git cuando se carga un proyecto, y una de ellas es el propio espacio de trabajo. La salida de Process Monitor en el artículo muestra Cursor.exe generando el binario repo-root con la línea de comando git rev-parse –show-toplevel.

Esa es la misma sonda raíz del repositorio. Documentos de VS Code de Microsoft describir. Si Cursor busca esas ubicaciones por sí mismo o le entrega a Windows un git no calificado y deja que elija el orden de búsqueda, el artículo no lo dice.

Ciberseguridad

La prueba de concepto de Mindgard fue la Calculadora de Windows, renombrada como git.exe y comprometida con la raíz. Clonar, abrir y listo. La captura de pantalla muestra las ventanas de la Calculadora apilándose solas mientras el proyecto permanece abierto.

La condición previa parece la parte difícil: el binario de un atacante, ubicado en la raíz de su proyecto. No lo es. Clonar el repositorio de un extraño es la forma en que los archivos binarios llegan al disco, y los desarrolladores y sus agentes lo hacen todo el día. Para empezar, el atacante no necesita ningún punto de apoyo. Esa es la distancia que cubre este error: desde un repositorio, cualquiera puede publicar código que se ejecute como usted.

Un límite a la evidencia. La confirmación fechada más reciente de Mindgard es el 30 de abril de 2026, contra Cursor 3.2.16, y el la versión actual es 3.11enviado el 10 de julio. El artículo dice que el error sobrevive en la versión más reciente que probó, pero no nombra esa versión.

The Hacker News revisó los 33 avisos de seguridad El cursor ha publicado y no encontró ninguna entrada que cubra el tema hasta el 15 de julio. No se ha asignado ningún CVE. Le pedimos a Cursor que nombrara cualquier versión que lo solucione y a Mindgard, qué versión probó por última vez. Esta historia se actualizará con cualquier respuesta.

Qué hacer

No existe ningún parche, por lo que todas las opciones siguientes son una solución alternativa. En flotas de Windows administradas, Mindgard sugiere reglas de denegación de AppLocker o Windows App Control que bloquean el ejecutable por nombre y ruta en las raíces del espacio de trabajo, como %USERPROFILE%\source\repos\*\filename.exe.

Reglas de ruta, no hashes; Los binarios del atacante varían según el hash. Windows no tiene una regla general incorporada que bloquee un proceso secundario solo cuando un padre específico lo inicia, señala la firma, por lo que la aplicación de la ley a los padres generalmente significa EDR. Todos los demás: abran repositorios que no sean de confianza en una máquina virtual desechable o en un Sandbox de Windows.

Combínalo con El consejo de Cymulate para comprobar un repositorio clonado o un archivo extraído antes de abrirlo. git.exe, npx.exe, node.exe y Where.exe no tienen nada que ver con la raíz del proyecto. Lo que pasó con el informe es el resto de la historia.

cursores pagina de seguridad dice que la empresa reconoce «los informes de vulnerabilidad dentro de los 5 días hábiles». La primera respuesta sustancial de Mindgard llegó un mes después del informe de diciembre, del CISO de Cursor, quien explicó que una automatización no había logrado invitar a la empresa al programa privado HackerOne.

El informe reenviado se cerró al día siguiente por ser informativo y fuera de alcance, luego se reabrió una vez que Mindgard rechazó y HackerOne lo reprodujo. HackerOne confirmó la entrega el 20 de enero. Después de eso: solicitudes de actualización en febrero, marzo y abril, y nada a cambio.

El registro de asesoramiento de Cursor, leído en comparación con la línea de tiempo de Mindgard, muestra el proceso funcionando para otros investigadores mientras se publicaba el informe de Mindgard. El 13 de febrero de 2026, Cursor publicó GHSA-8pcm-8jpx-hv8run escape de zona de pruebas de Git-hook (CVE-2026-26268) reportado por Novee bajo divulgación coordinada y fijado en el Cursor 2.5. Tres días después, el 16 de febrero, Mindgard solicitó una actualización de su propio informe relacionado con Git. Ninguna respuesta. El 14 de julio, el día en que llegó la divulgación completa, se emitieron dos avisos más de Cursor.

«La divulgación completa es la opción nuclear de la divulgación de vulnerabilidades», escribió Mindgard, reservándola para los casos en los que todos los demás caminos han fracasado. El autor, Aarón Portnoypasó años al otro lado de ese oficio: dirigió la Iniciativa Día Cero y creó los primeros seis concursos Pwn2Own.

El mismo error, otros tres proveedores

Mindgard no es la primera empresa en encontrar esto, ni la primera en obtener la respuesta de Cursor al respecto. En junio, Cymulate publicó hallazgos sobre la misma clase en todas las herramientas de IA: en Windows, varias de estas herramientas resuelven ejecutables auxiliares utilizando el orden de búsqueda predeterminado, que verifica el directorio de trabajo antes que las rutas confiables del sistema.

GitHub Copilot CLI ejecutó un espacio de trabajo git.exe al inicio, incluso antes de que se mostrara el mensaje de confianza de carpeta. Gemini CLI hizo lo mismo cuando se inició desde el espacio de trabajo. La aplicación de escritorio Codex lo hizo en una carpeta abierta, como Cursor.

Ciberseguridad

Hasta el artículo de Cymulate del 4 de junio, ninguno de esos proveedores había enviado una solución. GitHub evaluó su informe y pagó una recompensa, luego lo bajó a nivel bajo. Google estuvo de acuerdo en que el hallazgo de Gemini CLI era válido y no lanzó ningún parche. OpenAI cerró el informe del Codex como No aplicable, razonando que un atacante que puede reemplazar git.exe ya tiene acceso al sistema. Ese no fue el escenario reportado. Cursor cerró el informe Cursor CLI de Cymulate como informativo ocho días después, con el argumento de que los hallazgos que requieren un binario malicioso «carecen de un vector de ataque».

Esa investigación produjo una solución. AWS asignado CVE-2026-10591 por su hallazgo de Kiro, le dio crédito a Cymulate y lo parcheó en Kiro 0.11. Pero ese fue un error diferente: una falla de escritura de archivos del agente que permitió que un archivo .vscode/tasks.json envenenado se ejecutara automáticamente en una carpeta abierta. Ninguno de los informes de plantación binaria había producido uno.

La clase es anterior a todo esto. Una ruta de búsqueda que no es de confianza es la debilidad; Plantar un binario donde la búsqueda lo encontrará es el ataque. Windows verificar el directorio actual antes que %PATH% es lo que rompió Git Credential Manager Core en 2020 (CVE-2020-26233): un git.exe malicioso en el nivel superior de un repositorio, se ejecuta en lugar del real durante una clonación recursiva. Corregido en GCM 2.0.289.

PoC de Blaze Information Security en aquel entonces también se cambió el nombre de calc.exe a git.exe. Seis años después, el mismo truco aterriza en un IDE que ejecuta la sonda por usted en el momento en que abre la carpeta.

A cuatro proveedores se les ha mostrado un binario de espacio de trabajo que se ejecuta solo en Windows tan pronto como un desarrollador apunta la herramienta a un repositorio clonado. Dos decidieron que no era una vulnerabilidad en absoluto; dos estuvieron de acuerdo en que así era y, según la cuenta de junio de Cymulate, no habían enviado nada de todos modos. Así que el llamado recae en los defensores, y en Windows, lo más seguro es tratar un repositorio clonado como contenido ejecutable, porque eso es lo que es.

Grok Build cargó repositorios Git completos en xAI Storage, no solo los archivos que leyó – CYBERDEFENSA.MX

La CLI de codificación Grok Build de xAI estaba cargando repositorios Git completos, con el historial de confirmación completo y todo, en un depósito de Google Cloud Storage ejecutado por xAI, no solo los archivos que necesitaba una tarea de codificación.

Un investigador que publica como cerebroversión de prueba 0.2.93capturó una de esas cargas, clonó el paquete git de la solicitud interceptada y recuperó un archivo que al agente se le había dicho claramente que no abriera.

La carga se realizó en un canal separado del modelo en sí, y es difícil discutir la división de bytes. En un repositorio de 12 GB de archivos que el modelo nunca leyó, el modelo dirige el tráfico a /v1/responses llegó a aproximadamente 192 KB, mientras que el canal de almacenamiento a /v1/storage movió 5,10 GiB, una brecha de aproximadamente 27.800 veces entre lo que necesitaba el modelo y lo que dejaba la máquina.

Esa carga de almacenamiento se ejecutó en 73 fragmentos de aproximadamente 75 MB, cada uno de los cuales devolvió HTTP 200, y a través del tamaño del investigador barrió el tamaño total del repositorio rastreado. El cubo de destino, grok-code-session-tracesse nombra en binario y en etapas metadata.json cuyas rutas por archivo apuntan a gs://grok-code-session-traces/.

El archivo no leído fue src/_probe/never_read_canary.txtplantado con un marcador único. La clonación del paquete capturado lo recuperó palabra por palabra junto con el historial de confirmación completo del repositorio, y la misma prueba se replicó en un segundo repositorio no relacionado. Las capturas lo que establecen es transmisión, aceptación y almacenamiento, no entrenamiento.

El desmontaje no afirma que xAI esté entrenado en el código, que el personal lo lea o que los archivos ignorados por git siempre sean barridos. Los archivos rastreados más el historial es lo que muestra el cable.

Ciberseguridad

El camino de los secretos es separado y más sencillo. Cuando Grok lee un archivo, su contenido pasa al turno del modelo y se realiza un seguimiento. .env fue con ellos sin redactar, canario API_KEY y DB_PASSWORD valores y todo. El mismo contenido también llegó a un session_state archivo destinado al almacenamiento. Los secretos plantados eran falsos, por lo que no se filtró nada real en la prueba. El comportamiento sigue siendo el problema: un archivo de credenciales que el agente leyó durante una tarea salió y se almacenó sin redacción.

La configuración que elegirían la mayoría de los desarrolladores no hizo nada aquí. Con «Mejorar el modelo» desactivado, Grok aún cargó el repositorio y el propio servidor. /v1/settings la respuesta seguía regresando trace_upload_enabled: true. Esa palanca determina si sus datos entrenan el modelo. No rige si su código sale de la máquina. Son dos controles diferentes y sólo uno de ellos estuvo expuesto al usuario.

Cada agente de codificación en la nube tiene que enviar alguna fuente a un modelo remoto para realizar su trabajo, por lo que se espera el primer canal. Enviar todo el repositorio rastreado y su historial es un límite más amplio que enviar los archivos que necesita una tarea.

Un repositorio puede contener código propietario, URL internas, datos de clientes y credenciales que se eliminaron del árbol de trabajo pero que aún se encuentran en el historial de confirmaciones. En propia comparación de herramientas cruzadas de cereblabClaude Code y Codex no enviaron ningún paquete de repositorio; Gemini no envió ninguno en una prueba inactiva, aunque su ejecución de tarea realista fue bloqueada por cuotas antes de terminar.

Grok Build fue el caso atípico. Siguen siendo herramientas en la nube que envían los archivos que abren, por lo que «solo local» es el modelo mental incorrecto para cualquiera de ellas. Pero la recolección al por mayor del espacio de trabajo era específica de Grok Build.

La respuesta de xAI

El 13 de julio lo mismo. 0.2.93 El binario dejó de realizar solicitudes de almacenamiento. cereblab volvió a realizar la prueba seis veces y no vio nada /v1/storage cargas, y el servidor ahora regresó disable_codebase_upload: true y trace_upload_enabled: false.

El desarrollador Peter Dedene informó que la misma bandera fue devuelta a su cuentapor lo que el cierre no fue solo la observación de una sola máquina del cereblab. El cliente probado permaneció 0.2.93 aunque la configuración de su servidor cambió, se trató de un cambio del lado del servidor, no de una solución enviada en una actualización. xAI no ha confirmado si llega a todas las cuentas o es permanente.

Ciberseguridad

Hasta ahora, xAI ha abordado el problema en X en lugar de mediante un aviso de seguridad o una nota de registro de cambios. El Cuenta @SpaceXAI dijo que los equipos empresariales con retención de datos cero nunca tienen código o datos de seguimiento almacenados, que el uso de claves API respeta ZDR y que los consumidores que no lo han habilitado pueden ejecutar /privacy en la CLI para deshabilitar la retención y eliminar datos previamente sincronizados.

Elon Musk fue más allá, dicho todos los datos de usuario cargados hasta ahora serían «borrados total y absolutamente», sin dejar nada atrás. ZDR cubre equipos empresariales y el uso de API, por lo que para suscriptores individuales el /privacy El comando es el control que se ofrece.

Para cualquiera que ya haya ejecutado la herramienta, la decisión es no esperar a xAI. Rote cualquier credencial que Grok haya podido enviar: cualquier cosa que haya leído, cualquier cosa en un archivo rastreado y cualquier cosa en el historial de git que llevaba el paquete, incluido un secreto que usted confirmó y luego eliminó.

Un archivo que fue ignorado y nunca confirmado quedó fuera del paquete. Uno comprometido avanza en la historia y borrarlo más tarde no lo hace retroceder. Un análisis separado de la compilación 0.2.99. Encontré el código de carga todavía en el binario, retenido por la bandera del servidor, por lo que xAI puede volver a activarlo sin una actualización.

Y todavía no ha dicho por qué se cargaron repositorios completos de forma predeterminada, cuánto tiempo se conservaron o cuántos usuarios se vieron afectados. La exclusión voluntaria de la capacitación no es una promesa de que su código permanecerá fijo, y vale la pena comprobar usted mismo lo que sale de la máquina.

Las fallas en los enlaces simbólicos de GhostApproval podrían permitir que los repositorios maliciosos ejecuten código en agentes de codificación de IA

Investigadores de Fenómeno descubrió que una falla en seis populares asistentes de codificación de IA permite que un proyecto de código trampa tome silenciosamente el control de la computadora de un desarrollador. El asistente pide permiso para editar un archivo que parece inofensivo, pero la escritura llega a uno sensible.

Las herramientas afectadas son Amazon Q Developer, Claude Code de Anthropic, Augment, Cursor, Google Antigravity y Windsurf. Wiz llama al patrón Aprobación fantasma y lo publicó el 8 de julio.

Tres de los seis han enviado correcciones, dos no, y Anthropic niega que se trate de un error. Las más expuestas son las herramientas que cambian archivos antes de que puedas intervenir.

Cómo funciona el ataque

El ataque abusa de una antigua característica de Unix llamada enlace simbólicoo enlace simbólicoque los asistentes no logran comprobar. Un enlace simbólico apunta silenciosamente a otro archivo en otra parte del disco, por lo que escribir en él en realidad escribe en el destino.

Wiz creó un repositorio malicioso con un enlace simbólico llamado project_settings.json que realmente apunta al archivo de inicio de sesión SSH de la víctima, ~/.ssh/authorized_keys. El archivo README del repositorio le dice al asistente que agregue «una línea» a project_settings.json, y esa línea es la clave SSH del atacante vestida como una configuración inofensiva.

Pídale al agente que «configure el espacio de trabajo» o «siga el archivo README» y escribirá la clave directamente a través del enlace simbólico en el archivo de inicio de sesión. A partir de ahí, si la máquina ejecuta un servicio SSH al que el atacante pueda acceder, podrá iniciar sesión sin contraseña.

Una segunda versión del truco escribe en el archivo de inicio de su shell, ~/.zshrc, que el shell ejecuta la próxima vez que abre una terminal, por lo que no se necesita SSH. No hay señales de que nada de esto haya sido utilizado en ataques reales; Wiz lo presenta como investigación.

El cuadro de aprobación muestra algo incorrecto

Los trucos de enlaces simbólicos tienen décadas de antigüedad. El enlace simbólico es sólo la entrega; el verdadero fracaso es el cuadro de aprobación. En GhostApproval, se encuentra ese cuadro.

Al probar Claude Code, Wiz descubrió que el agente ya había detectado el objetivo real en su propio razonamiento, y señaló que project_settings.json era, en sus palabras, «en realidad un archivo de configuración zsh». Sin embargo, el cuadro mostrado al desarrollador solo mencionaba el archivo inofensivo.

Ciberseguridad

Hace clic en Aceptar, creyendo que está editando un archivo de configuración local, y la escritura llega a su archivo de inicio de shell o a sus claves SSH. Wiz llama a esto un bypass de consentimiento informado: el humano todavía está en el bucle, pero el bucle les muestra algo incorrecto.

Algunas herramientas son peores: saltan la puerta por completo, por lo que nunca hay un momento para intervenir. Windsurf escribe el archivo en el disco antes de que aparezcan los botones Aceptar y Rechazar, por lo que el mensaje es solo un botón deshacer y la clave ya está en su lugar.

Augment no muestra ningún diálogo y Wiz lo demostró en silencio, leyendo un archivo de credencial de AWS que se encontraba fuera del proyecto. Sin embargo, las herramientas que todavía muestran un mensaje no son más seguras; el mensaje simplemente nombra el archivo incorrecto.

¿Qué herramientas se ven afectadas?

Wiz informó del problema a los seis proveedores. Aquí es donde se encuentra cada uno al momento de la publicación:

Herramienta Estado que hacer
Desarrollador de Amazon Q Corregido en el servidor de idiomas 1.69.0 (CVE-2026-12958) Actualizar. Se instala automáticamente para la mayoría de los usuarios y al volver a cargar el IDE se activa.
Cursor Fijado en v3.0 (CVE-2026-50549) Actualización desde el administrador de extensiones.
Antigravedad de Google Fijo (CVE pendiente) Actualizar a la versión actual.
Aumentar Admitido; aún no hay solución No apuntes a repositorios en los que no confíes.
windsurf Admitido; aún no hay solución No apuntes a repositorios en los que no confíes.
Código Claude antrópico Cuestionado; Las versiones actuales advierten. Actualice y lea la advertencia del enlace simbólico antes de aceptar.

Anthropic rechazó la clasificación y le dijo a Wiz que el escenario se encuentra «fuera de nuestro modelo de amenaza»: el desarrollador eligió confiar en la carpeta al iniciar la sesión y luego aprobó la edición, por lo que la decisión fue suya.

También dijo que la advertencia de enlace simbólico de Claude Code se envió a principios de febrero, antes del informe privado de Wiz, como un refuerzo de rutina en lugar de una solución, y que un «sin comentarios» anterior era una respuesta automática.

De los seis proveedores, Anthropic es el único que dice que esto no es un error; Se enviaron tres correcciones y dos están trabajando en ellas. Sin embargo, la pregunta que plantea su postura es real, y no solo Anthropic debe responder: ¿hasta dónde debe llegar un agente de codificación para proteger a un desarrollador que ya ha confiado en un repositorio malicioso?

Más allá de los parches, algunos hábitos reducen el riesgo, independientemente de la herramienta que utilice. Ejecute el agente con acceso limitado a archivos o dentro de un entorno limitado o contenedor. Revise el archivo README de un repositorio y los archivos de configuración ocultos antes de permitir que un agente lo «configure».

Y después de trabajar en un repositorio desconocido, verifique los archivos a los que se dirige el ataque, que se encuentran fuera del proyecto y, por lo tanto, no aparecerán en el estado de git: su archivo de inicio de shell, sus claves SSH y la propia configuración de su herramienta de inteligencia artificial. Verificar sus marcas de tiempo, por ejemplo, con ls -la ~/.zshrc ~/.ssh/authorized_keys, muestra si algo cambió mientras el agente se estaba ejecutando.

Ciberseguridad

El consejo de Wiz para los fabricantes de herramientas es breve: resuelva el enlace simbólico y muestre el destino real antes de preguntar, marque cualquier escritura que termine fuera de la carpeta del proyecto y nunca toque el disco hasta que el usuario lo haya aprobado.

Un defecto compartido, no el desliz de un proveedor

En mayo, Adversa AI publicó SymJackel mismo patrón de enlace simbólico y aprobación contra seis agentes de codificación, incluidos Claude Code, Cursor, GitHub Copilot y Grok Build.

Dos equipos independientes descubrieron que esto apunta a una debilidad de diseño compartida, no a un desliz de un proveedor: estos agentes siguen un enlace simbólico utilizando operaciones de archivos ordinarias, luego solicitan aprobación según la ruta que se les entregó, no la ruta en la que llega la escritura.

El solapamiento llega incluso al CVE. El propio aviso de Cursor por su error de enlace simbólico acredita tanto a Wiz como a Cato AI Labs, cuyo trabajo anterior The Hacker News cubrió como DuneSlide.

Los archivos en los que confía un asistente de IA ya no son solo código. Para estos agentes, sirven también como instrucciones que el agente sigue y caminos que sigue, y dan forma a lo que muestra el cuadro de aprobación. El boletín de AWS también cubre una falla separada de Amazon Q, CVE-2026-12957, donde un repositorio envenenado podría cargar automáticamente un archivo de configuración y ejecutar comandos para robar las claves de AWS de un desarrollador una vez que se confiaba en el espacio de trabajo.

La técnica exacta de GhostApproval todavía está bajo investigación, pero el patrón más amplio ya está apareciendo en la naturaleza: repositorios que contienen archivos que dirigen a los agentes de IA a comportamientos inseguros.

Como informó THN ​​en junio, el gusano Miasma colocó archivos de configuración de agentes de IA en un repositorio de Microsoft Azure para que su carga útil se ejecutara en el momento en que un desarrollador abriera el proyecto en Claude Code, Cursor o Gemini. En respuesta, GitHub deshabilitó los 73 repositorios de Microsoft afectados.

«Human in the loop» sólo te protege si el loop dice la verdad. A medida que estos asistentes obtienen más libertad para leer y escribir archivos por su cuenta, un cuadro de aprobación que nombra el destino incorrecto no es una protección sino una responsabilidad, y tratar un repositorio engañoso como un problema puramente del usuario pone el peso en la persona que tiene menos capacidad para ver el intercambio.

Un problema público de GitHub podría engañar a los flujos de trabajo agentes de GitHub para que filtren datos de repositorios privados

Un asunto público puede engañar Flujos de trabajo agentes de GitHub en filtrar el contenido de los repositorios privados de una organización, según han demostrado investigadores de Noma Security.

El atacante sólo necesita abrir un problema de apariencia normal en un repositorio público, sin credenciales robadas y sin acceso a la organización. Si esa organización le ha dado al agente acceso de lectura a todos sus repositorios, incluidos los privados, el problema puede llevarlo a incluir contenidos privados en un comentario público.

Noma llama a la técnica GitPerdido. El objetivo es Flujos de trabajo agentes de GitHubuna característica ahora en versión preliminar pública que GitHub lanzó en febrero. En lugar de escribir scripts de automatización, escribe instrucciones para un agente de IA en inglés sencillo en un archivo Markdown. El agente lee problemas y solicitudes de extracción, ejecuta herramientas y responde por sí solo.

Puede funcionar con GitHub Copilot, Claude de Anthropic, Google Gemini u OpenAI Codex. Los flujos de trabajo son de solo lectura de forma predeterminada, pero una organización puede entregarle un token con acceso de lectura en todos sus repositorios para darle contexto entre repositorios, incluidos los privados.

Esa concesión es la configuración que GitLost vuelve en su contra.

Cómo funciona el truco

La debilidad es bien conocida: inyección inmediata indirecta. Un agente de IA no puede distinguir de manera confiable entre las instrucciones de su propietario y las instrucciones ocultas dentro del contenido que lee. Entonces, si un atacante escribe esas instrucciones en un problema, el agente puede simplemente seguirlas.

En Noma’s prueba de conceptoel problema malicioso se disfrazó de una solicitud de rutina de un vicepresidente de ventas después de una reunión con un cliente. El flujo de trabajo al que llegó estaba configurado para activarse cuando se asigna un problema, leerlo y responder con un comentario. También tenía acceso de lectura a otros repositorios de la organización.

Ciberseguridad

Una vez que una automatización de rutina asignó el problema, el agente extrajo el archivo README de un repositorio privado y lo pegó en un comentario público sobre el problema.

GitHub construyó barreras de seguridad para detener exactamente esto. en su propio documentaciónla compañía advierte que «los agentes de IA pueden ser manipulados mediante inyección rápida, contenido de repositorio malicioso o herramientas comprometidas», y el producto se envía con sandboxing, tokens de solo lectura de forma predeterminada, limpieza de entradas y un paso de detección de amenazas que escanea la salida propuesta de un agente antes de publicarla.

Noma informó que en su prueba, un cambio de una palabra fue suficiente para pasar desapercibido. Anteponer la instrucción maliciosa con «Además» llevó al modelo a tratarlo como una tarea de seguimiento, no como algo que rechazar, y la barandilla lo dejó pasar.

¿Por qué este es diferente?

Lo que distingue a GitLost es lo que el atacante puede controlar. «Los ejemplos anteriores de inyección rápida tenían que ver en gran medida con la manipulación de lo que decía un agente», Sasi Levi, líder de investigación de seguridad de Seguridad Nomadijo a The Hacker News. «GitLost trata de manipular lo que hace un agente con sus permisos».

El agente aquí, dijo, no es una ventana de chat sino un actor acreditado que se encuentra dentro de la infraestructura adyacente a CI/CD de una organización, con acceso de lectura que abarca repositorios que el atacante no puede ver. No toca ningún servidor, no necesita credenciales robadas y no requiere acceso de escritura a nada privado. El atacante sólo tiene que abrir un tema público.

La configuración se ajusta a lo que el desarrollador Simon Willison llamó el «trifecta letal»y Levi usa el mismo término: un agente que puede acceder a datos privados, recibe contenido externo que no es de confianza y tiene una forma de enviar datos. Combine los tres y tendrá una ruta de fuga.

Este no es el tipo de error que soluciona un parche; Como lo plantea Levi, es una consecuencia estructural de otorgar a los agentes de IA credenciales permanentes mientras les hacen leer texto accesible al atacante.

¿Por qué esto sigue sucediendo?

GitLost es el último de una serie del mismo tipo de ataque, y THN ha informado de varios en los últimos meses. Una falla en Claude Code GitHub Action de Anthropic permitió que un solo problema malicioso empujara al agente a filtrar secretos y tomar acceso de escritura a un repositorio.

RoguePilot de Orca Security utilizó un mensaje oculto en un problema de GitHub para hacer que Copilot filtrara el token privilegiado de un repositorio. La versión del problema del agente GitHub se remonta al menos a mayo de 2025, cuando Invariant Labs presentado que un problema público podría empujar a un agente conectado al servidor MCP de GitHub a leer un repositorio privado y filtrarlo a través de una solicitud de extracción; los investigadores lo llamaron arquitectónico, sin ningún parche del lado del servidor para cerrarlo.

Ciberseguridad

Un estudio entre proveedores llamado Comentar y controlar luego engañó a los agentes de Claude Code, Gemini CLI y GitHub Copilot para que filtraran sus propias claves API a través de textos de problemas y solicitudes de extracción, eludiendo las defensas de tiempo de ejecución agregadas de GitHub en el camino.

Que hacer ahora

Noma reveló GitLost a GitHub y publicó sus hallazgos con el conocimiento de la empresa. La exposición se limita a organizaciones que han habilitado la vista previa y han conectado a un agente para leer información pública que no es de confianza mientras mantienen acceso de lectura a repositorios privados y pueden publicar en público.

Lo que un atacante podría obtener depende de lo que el token del agente pueda ver, desde código fuente propietario hasta claves internas, documentos de diseño o secretos de CI/CD. Como dice Levi, el alcance es lo que más importa: un token de agente con alcance en el repositorio único que clasifica es «mucho menos peligroso que uno con acceso de lectura amplio para toda la organización» por conveniencia.

En la práctica, ese acceso entre repositorios proviene de un token de acceso personal que la organización configura, por lo que el token se aplica al repositorio que el flujo de trabajo clasifica en lugar de a toda la organización. Las escrituras fluyen solo a través de salidas declaradas seguras, por lo tanto, limite lo que un flujo de trabajo público puede publicar, porque el comentario que produce es el canal de exfiltración. Restrinja el contenido de los autores sobre el cual actuará el agente y controle sus resultados tras la revisión humana.

El paso de detección de amenazas de GitHub escanea la salida de un agente antes de publicarlo, pero la omisión de una palabra de Noma es un recordatorio de que un filtro es un respaldo, no un límite.

GitHub, al igual que los otros proveedores, construyó barreras de seguridad exactamente para esta clase de ataque, y un cambio de una palabra las evitó. Los investigadores y los propios proveedores siguen archivando el resultado bajo «limitación arquitectónica», y el punto de Levi es por qué se mantiene la etiqueta: en el lenguaje natural, no hay una línea clara entre los datos y las instrucciones como ocurre en SQL, por lo que la solución se basa en la arquitectura en lugar de filtrar la inyección, en el aislamiento, las credenciales de alcance y la revisión por etapas.

Hasta que exista ese límite, cualquier agente que lea datos privados, reciba información que no sea de confianza y pueda publicar en público está a un paso inteligentemente redactado de una filtración.

El nuevo ChocoPoC RAT apunta a investigadores de vulnerabilidades a través de repositorios de exploits PoC falsos – CYBERDEFENSA.MX

Los atacantes esconden un troyano que roba datos dentro de un código de explotación falso dirigido a las personas que se ganan la vida cazando errores. El malware, llamado ChocoPoCviaja en repositorios de prueba de concepto (PoC) de Python en GitHub que afirman explotar nuevos CVE.

Ejecute uno y extraerá silenciosamente sus contraseñas guardadas, cookies del navegador y archivos, y luego le entregará al atacante un shell en su máquina. YesWeHack y Sekoia publicaron sus hallazgos conjuntos el 1 de julio y advirtieron que, a partir de ese informe, el malware y sus servidores todavía estaban activos, por lo que no ejecute ninguna de estas PoC.

El truco está en dónde se encuentra el código. El PoC visible parece limpio. El malware se esconde en un paquete de Python que el PoC incorpora como una dependencia, por lo que pasa desapercibido en una revisión rápida del código.

Cómo funciona la trampa

El cebo es la presión del tiempo. Cuando surge una falla importante, los investigadores se apresuran a probarla y a obtener PoC de la comunidad para actuar rápidamente. Esta campaña convierte ese hábito en una vía de infección.

Ciberseguridad

La cadena, en términos sencillos:

  1. Clona el repositorio y ejecuta pip install para obtener los requisitos de PoC.
  2. Eso atrae un paquete llamado frint, que a su vez arrastra un segundo paquete, skytext.
  3. skytext incluye un pequeño archivo compilado (gradient.so en Linux, gradient.pyd en Windows) que se ejecuta en el momento en que inicia el PoC.
  4. Solo se despierta cuando ve el PoC real cargado, busca un archivo llamado EXPLOIT_POC.py o similar, luego descomprime su carga útil y descarga el troyano.

Esa última comprobación es la razón por la que un sandbox simple no ve nada. Detona el paquete por sí solo, sin el PoC completo a su alrededor, y el malware permanece inactivo.

Lo que roba y hace

Una vez en ejecución, ChocoPoC es un troyano de acceso remoto completo. Extrae contraseñas guardadas, cookies, autocompletar e historial de Chrome, Brave, Edge y Firefox. Toma archivos de texto, notas y bases de datos locales, junto con el historial del shell, la configuración de red y la lista de procesos en ejecución.

El atacante también puede ejecutar cualquier comando de shell, ejecutar Python arbitrario, extraer carpetas enteras y ralentizar el malware para permanecer en silencio. Varios nombres de comandos están en español y el código contiene pequeños errores, que los investigadores interpretan como escritos a mano en lugar de generados por IA.

Para controlarlo, el malware se esconde a simple vista. Lee sus órdenes de un conjunto de datos en Mapbox, un servicio de mapas normal, y lo utiliza como punto muerto. Resuelve esa dirección a través de DNS sobre HTTPS y utiliza un truco de dominio frontal, por lo que el tráfico parece llamadas API de Mapbox normales. Las cargas más grandes van a un servidor separado en 91.132.163.78.

¿Hasta dónde se ha extendido?

YesWeHack y Sekoia encontraron al menos siete repositorios PoC falsos, cada uno vinculado a una falla de alto perfil:

  • Recorrido de ruta FortiWeb (CVE-2025-64446)
  • React2Shell (CVE-2025-55182)
  • MongoBleed (CVE-2025-14847)
  • Omisión de autenticación PAN-OS (CVE-2026-0257)
  • Inyección de comando Ivanti Sentry (CVE-2026-10520)
  • Omisión de autenticación de VPN de Check Point (CVE-2026-50751)
  • Generador de páginas Joomla SP RCE (CVE-2026-48908)

Solo el paquete skytext se descargó unas 2.400 veces, principalmente en Linux. Las descargas no prueban que alguien estuviera infectado, pero aumentaron justo después de que los principales CVE se hicieran públicos, lo que encaja con el atractivo.

Una ejecución anterior de la misma campaña, que se remonta a finales de 2025, utilizó otros dos paquetes, slogsec y logcrypt.cryptography, con un código casi idéntico. Sekoia evalúa con alta confianza que un actor está detrás de ambos, basándose en marcadores de control reutilizados.

Dice que el operador rotó cuentas de GitHub, PyPI y Mapbox, varias de ellas creadas a partir de inicios de sesión filtrados o robados. No se ha nombrado ningún grupo conocido.

Los investigadores de seguridad son un objetivo rico. Ejecutan código no confiable por diseño, a menudo con altos privilegios, y sus máquinas contienen credenciales de clientes, informes privados y detalles de interacciones en vivo. Si compromete uno, podrá llegar mucho más allá de una sola computadora portátil.

La campaña MUT-1244 mostró la recompensa, utilizando repositorios PoC falsos para robar claves SSH y credenciales de nube de investigadores y equipos rojos.

Ciberseguridad

Esta no es una idea nueva, sólo un nuevo envoltorio. El grupo Lazarus de Corea del Norte ha cortejado a investigadores durante años, hacerse pasar por compañeros cazadores de errores y enviar proyectos maliciosos de Visual Studio en 2021y luego les quemará un día cero en 2023, con nuevas oleadas desde entonces.

En lo que respecta a los delitos contra las materias primas, Trend Micro encontró un PoC falso para una falla LDAP de Windows (CVE-2024-49113) que robó datos del investigador a principios de 2025, y una campaña separada impulsó PoC CVE falsos que llevaban un troyano llamado WebRAT a finales de 2025, afectando principalmente a estudiantes y evaluadores junior.

Lo que añade ChocoPoC es el escondite. El malware vive en una dependencia, por lo que la prueba de concepto que lees permanece limpia. Como lo expresaron los investigadores, el malware en sí es una noticia vieja, pero «lo que está cambiando es el mecanismo de entrega».

Que hacer ahora

  • Trate cualquier PoC como hostil hasta que se demuestre lo contrario y manténgase alejado del código de cuentas nuevas o desconocidas.
  • Lea la cadena de dependencia completa, no solo el archivo PoC. Esté atento a paquetes recién publicados, mantenedores desconocidos y cuentas con historial oculto.
  • Pruebe solo en una máquina virtual desechable, pero recuerde que el aislamiento por sí solo no activará esta. La verdadera solución es no instalar ningún paquete.
  • Verifique sus sistemas en busca de frint, skytext, slogsec y logcrypt.cryptography, además de los hashes de archivos en el informe. Si ejecutó alguno de ellos, rote las credenciales y reconstruya el host.

El mayor riesgo está aguas abajo. Estos señuelos se dirigen a los investigadores que proporcionan detecciones y PoC a marcos como Nuclei y MDUT. Sekoia señala el peligro de un doble impacto en la cadena de suministro: si se envenena a un investigador, el código incorrecto puede trasladarse a un marco en el que confían miles de personas más.

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.

Las fallas de Cordyceps CI/CD exponen más de 300 repositorios de GitHub a ataques a la cadena de suministro – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han señalado una nueva clase de debilidad en el flujo de trabajo de CI/CD que permite a los atacantes secuestrar flujos de trabajo y comprometer las cadenas de suministro de código abierto.

El «patrón crítico explotable» ha recibido el nombre en clave cordyceps por Novee Seguridad. El problema puede permitir a los atacantes el control total de los repositorios en docenas de las organizaciones más grandes del mundo, incluidas Microsoft, Google, Apache y Cloudflare.

«La falla puede ser explotada por cualquier usuario no autenticado», dijo Elad Meged, ingeniero fundador e investigador de seguridad de Novee Security. dicho. «Sin membresía en una organización ni privilegios especiales; una cuenta gratuita es suficiente para falsificar aprobaciones, enviar códigos o robar credenciales».

El análisis de la empresa de pruebas de penetración de unos 30.000 repositorios de alto impacto ha revelado que más de 300 son totalmente explotables, lo que permite la ejecución de código controlada por atacantes, el robo de credenciales y el compromiso de la cadena de suministro, lo que puede tener graves impactos posteriores.

El núcleo del problema se reduce a configuraciones CI/CD débiles que otorgan a las solicitudes de extracción (PR) más permisos de los que deberían tener. Las relaciones públicas son propuestas para fusionar cambios de código de una rama en el proyecto principal. Sin embargo, debido a que un RP que no es de confianza puede desencadenar flujos de trabajo privilegiados, puede abrir la puerta a la inyección de comandos, la escalada de privilegios y el compromiso de la cadena de suministro.

Ciberseguridad

«Esta vulnerabilidad de la cadena de suministro radica en las tuberías fundamentales de código abierto con las que funciona toda la industria y en el tipo de problema que se esconde de los escáneres porque, técnicamente, cada pieza individual funciona según lo diseñado», explicó Novee. «El flujo de trabajo hace lo que se le dijo. La vulnerabilidad existe sólo en la composición: datos que no son confiables cruzan un límite de confianza que nadie auditó».

En Azure Sentinel de Microsoft, por ejemplo, Novee encontró un comentario sobre un PR que podía ejecutar código de atacante anónimo en el CI de Microsoft y robar una clave de aplicación GitHub que no vence. En un caso similar, un PR en el kit de desarrollo de agentes de IA de Google («adk-samples») podría ejecutar código de atacante en el CI de Google para obtener autoridad completa sobre un repositorio de Google Cloud.

Otros hallazgos se enumeran a continuación:

  • Apache Doris, donde dos ataques sin clic provocan que un solo comentario en cualquier PR o un PR bifurcado ejecute el código del atacante y extraiga credenciales de CI codificadas o un token con permisos de escritura completos.
  • SDK de trabajadores de Cloudflare, donde un PR con un nombre de rama diseñado puede ejecutar comandos arbitrarios en los ejecutores de CI de Cloudflare
  • Black de Python Software Foundation, donde una sola solicitud de extracción de cualquier persona podría ejecutar código de atacante en los sistemas de compilación de Black y robar el token de automatización, que luego puede usarse para aprobar solicitudes de extracción.

Tras una divulgación responsable, tanto Microsoft como Google confirmaron el impacto, mientras que Cloudflare, Python y Apache aplicaron refuerzos y parches, respectivamente.

«La naturaleza de la codificación agente significa que estas vulnerabilidades de CI/CD se reproducen persistentemente, a escala, ‘infectando’ repositorios a un ritmo exponencial», dijo Meged. «Debido a que los usuarios anónimos pueden usarlos para obtener control sobre la cadena de suministro de software, nos gusta pensar que es como un ‘títere’ de los repositorios de algunas de las empresas más grandes del mundo, manipulando silenciosamente sus flujos de trabajo».

Microsoft restaura algunos repositorios de GitHub y mantiene otros fuera de línea mientras continúa Miasma Probe – CYBERDEFENSA.MX

Microsoft confirmó el lunes que eliminó temporalmente algunos repositorios de GitHub en respuesta a un reciente incidente de seguridad que llevó a que 73 de sus proyectos de código abierto se vieran comprometidos para inyectar un ladrón de información en el código.

«Nuestra prioridad es proteger a los clientes y al ecosistema en general», dijo un portavoz de Microsoft a The Hacker News por correo electrónico. «Eliminamos temporalmente algunos repositorios mientras investigamos contenido potencialmente malicioso. Algunos de estos repositorios se restauraron después de la revisión, mientras que otros pueden permanecer fuera de línea mientras continúa el trabajo».

«Como parte de nuestra investigación, notificamos a un pequeño número de clientes que pueden haber eliminado contenido de los repositorios afectados. Continuaremos investigando y, si se identifica algo más que requiera la acción del cliente, nos comunicaremos directamente a través de nuestros canales de soporte establecidos».

El desarrollo se produce días después de que el fabricante de Windows cortara el acceso a docenas de sus proyectos de código abierto alojados en GitHub luego de informes de que fueron comprometidos como parte de una campaña en curso de la cadena de suministro de software con el nombre en código Miasma.

Ciberseguridad

Entre los proyectos infectados se encuentra «durabletask», un paquete de Python que fue comprometido por primera vez el mes pasado por un grupo de cibercrimen conocido como TeamPCP para ofrecer un ladrón de información diseñado para sistemas Linux.

Un análisis más detallado de la carga útil de Miasma integrada en los proyectos ha descubierto capacidades para activar la ejecución automática de código cuando un desarrollador desprevenido abre el repositorio en una herramienta de codificación impulsada por inteligencia artificial (IA) o en un entorno de desarrollo integrado (IDE).

Los hallazgos son los últimos de una campaña sostenida en la cadena de suministro de software que ha violado paquetes de código abierto ampliamente utilizados para plantar malware capaz de propagarse a usuarios posteriores y más allá.

Esto incluye una ola PyPI más nueva vinculada a las ondas más amplias Mini Shai-Hulud, Miasma y Hades, que infecta un conjunto adicional de 23 paquetes, incluidos algunos Bibliotecas relacionadas con la bioinformática utilizadas en el aprendizaje de gráficos, fenotipado de pacientes, herramientas de fenopaquetes y flujos de trabajo científicos.

Algunos de los otros paquetes incluyen un conjunto de paquetes temáticos de AI y Model Context Protocol (MCP) y paquetes de estilo typosquat como rsquests, tlask y rlask que se hacen pasar por solicitudes y flask, y un langchain-core-mcp. La lista completa de paquetes legítimos y de cebo se encuentra a continuación:

  • sueñogen 1.8.1
  • aumentar 0.11.97
  • achicar 0.8.101
  • gpsea 0.9.14
  • instructor-mcp 1.15.2, 1.15.3
  • langchain-core-mcp 1.4.2, 1.4.3
  • mem8 6.0.1
  • mflux-streamlit 0.0.3, 0.0.4
  • openai-mcp 2.41.1, 2.41.2
  • plataforma orquesta8 3.3.2
  • kit de herramientas de tienda de fenopacket 0.1.7
  • ppkt2synergy 0.1.1
  • herramientas pyphetools 0.9.120
  • servidor-ray-mcp 0.2.1
  • rlask 3.1.7
  • rsquests 2.34.3
  • tiktoken-mcp 0.13.1, 0.13.2
  • tarea 3.1.4

El nuevo clúster emplea un nuevo mecanismo de entrega de carga útil, según Enchufelo que indica que los actores de la amenaza se están adaptando y experimentando activamente con diferentes métodos como parte de lo que se ha descrito como una «campaña de cadena de suministro en rápido movimiento».

Ciberseguridad

Mientras que los paquetes anteriores utilizaban ganchos de inicio ejecutables .pth para iniciar Bun y ejecutar un ladrón de JavaScript ofuscado, el último conjunto incorpora diferentes enfoques:

  • Extensiones .abi3.so nativas troyanizadas que ejecutan el ladrón cuando se importa el paquete
  • Una variante del cargador de gancho de inicio .pth que busca en sys.path la carga útil «_index.js» en lugar de agrupar la carga útil en la misma rueda

«Esa última variante separa el cargador de la carga útil de JavaScript, lo que podría hacer que el paquete parezca menos malicioso durante el análisis estático», dijo Socket a The Hacker News.

Independientemente del método utilizado, el resultado final es el mismo. Una vez ejecutado, el malware se dirige a las estaciones de trabajo de los desarrolladores y a los entornos de CI/CD, recopilando secretos de alto valor y exfiltrándolos a un repositorio público de GitHub.

Una capacidad clave del paquete de bioinformática es su capacidad para descarrilar y eludir escáneres y copilotos de analistas impulsados ​​por IA mediante una inyección rápida adversaria integrada dentro de un comentario de bloque de JavaScript, una característica detallada previamente por StepSecurity.

«La rama Hades de la actividad Shai-Hulud y Miasma se entiende mejor como una campaña de rápida cadena de suministro, no como un solo incidente de paquete», dijo el investigador de Socket Kirill Boychenko. «La variante langchain-core-mcp va más allá al instalar un cargador .pth que busca _index.js en sys.path, lo que significa que el cargador y la carga útil no necesitan vivir en la misma rueda».