Amazon Q Developer: booby-trapped repository, code execution, and AWS theft

A reported weakness in Amazon Q Developer highlighted a risk that is now central for development teams: the interface between a code assistant, a third-party repository, and the developer’s local workstation. According to the information published by The Hacker News, based on details provided by AWS, a booby-trapped GitHub repository could lead Amazon Q Developer to process an untrusted MCP configuration and trigger local command execution during the setup or initialization phase. The potential impact goes beyond the workstation alone: successful local execution can expose AWS credentials, access tokens, SSH keys, sensitive environment variables, or other secrets present on the machine.

Update 07/01/2026 — On June 26, 2026, Wiz disclosed a flaw in Amazon Q Developer allowing a booby-trapped repository to automatically load a malicious MCP configuration, execute code locally, and exfiltrate active AWS credentials/session data; Amazon had already deployed a fix on May 12, 2026, before the public disclosure. (thehackernews.com)

Update 06/29/2026 — On June 26, 2026, Wiz disclosed a high-severity flaw in the Amazon Q Developer extension for Visual Studio Code allowing, via a booby-trapped repository, the automatic execution of commands and the theft of cloud/AWS credentials; AWS had published its bulletin on June 23, 2026 and fixed CVE-2026-12957 in the Language Servers for AWS component starting with version 1.65.0. (wiz.io)

Update 07/03/2026 — A recently disclosed flaw in Amazon Q Developer allowed, via a booby-trapped repository containing a malicious MCP configuration, the execution of commands on the developer’s machine and the exfiltration of their AWS credentials or tokens. Sources published last week attribute the issue to the “Language Servers for AWS” runtime and indicate that AWS released fixes requiring explicit approval. (thehackernews.com)

Update 06/30/2026 — On June 26, 2026, Wiz disclosed a flaw in Amazon Q Developer allowing a booby-trapped repository to automatically load a malicious MCP configuration, execute commands on the developer’s machine, and exfiltrate AWS credentials; Amazon had already fixed the issue before the public disclosure. (theregister.com)

Update 07/02/2026 — In late June 2026, Wiz researchers reported a high-severity flaw in Amazon Q Developer: opening a booby-trapped repository could automatically load a malicious MCP configuration, execute commands on the developer’s machine, and enable the theft of AWS credentials. (thenextweb.com)

The issue should be understood as a developer-side supply chain risk. The application repository becomes the entry point, the code assistant acts as a trusted intermediary, and the developer’s workstation becomes the execution surface. In an environment where IDEs, extensions, and automated agents interact with Git, the terminal, dependency managers, and cloud services, the boundary between “development assistance” and “local action capability” is particularly sensitive.

At this stage, the publicly repeated information indicates that AWS has fixed the behavior in question. The essential point for technical teams is therefore twofold: apply the patched version released by the vendor, and treat any MCP configuration coming from an uncontrolled repository as untrusted until an explicit validation policy is in place. No official CVSS score is reliably repeated in the source material mentioned here, and one should therefore not invent one. Likewise, the CVE identifier is not reliably confirmed in the brief provided; it is necessary to stick to the security advisory and the fix published by AWS.

For CISOs, platform managers, and DevSecOps teams, this case is a reminder of several structural points:

• a source repository is no longer just a set of application files;
• development assistants can interpret metadata or configurations likely to influence local behavior;
• cloud secrets present on workstations remain a priority target;
• hardening the developer workstation and IDE environment is becoming a full-fledged application security issue.

The initial media source is The Hacker News article titled Amazon Q Developer Flaw Could Let Malicious Repos Run Code via MCP Configs. For remediation analysis, the preferred reference remains the advisory or official AWS communication on the fix and updated versions.

Affected versions

The information provided indicates that versions of Amazon Q Developer prior to the fix deployed by AWS are affected, in scenarios where the tool processes untrusted repositories and MCP configurations. In the absence, in the brief, of a precise officially confirmed version number, one should avoid announcing a version boundary that could be inaccurate.

For an alert of this type, best practice is to immediately inventory the following components:

• local Amazon Q Developer installations on development workstations;
• associated IDE extensions, if the tool is integrated into VS Code, JetBrains, or another environment;
• standardized workstation images in VDI or on corporate laptops;
• demonstration, training, or sandbox environments where third-party repositories are often opened without prior review.

In practice, any deployment meeting the following conditions simultaneously should be considered vulnerable:

• Amazon Q Developer version earlier than the patched version published by AWS;
• ability to open or initialize Git repositories from unapproved sources;
• support for MCP configurations imported, interpreted, or proposed during setup;
• local presence of exploitable secrets, for example in ~/.aws/credentials, ~/.ssh/, environment variables, or cloud tool configuration files.

The patched versions are those distributed by AWS after publication of the fix. If your organization does not yet have a reliable inventory, you should rely on:

• AWS’s official update documentation;
• software fleet management mechanisms;
• IDE extension installation logs;
• EDR or MDM platforms capable of reporting the installed version.

In an enterprise context, it is useful to distinguish three populations:

• application developers who frequently open public repositories or community examples;
• DevOps/SRE teams often having broad access to AWS, Kubernetes, CI/CD, and infrastructure secrets;
• contractors and temporary accounts whose workstations are sometimes less standardized and more exposed to opening third-party repositories.

If a fix has been applied by AWS but some workstations remain outside the update cycle, the risk persists locally. This is an important point for distributed environments, including at customers hosted or operated from French infrastructures such as OVHcloud, Scaleway, or o2switch, whenever development workstations interact with AWS or store cloud secrets.

Attack vector

The described attack vector relies on a booby-trapped GitHub repository containing or triggering an untrusted MCP configuration, which the development assistant may process during the setup phase. The exact mechanism must be read through AWS’s official communication, but the general pattern is clear: content controlled by an attacker influences the local behavior of a tool running on the developer’s workstation.

This type of scenario differs from a classic server vulnerability. Here, the attacker does not need to exploit a service exposed on the Internet. It is enough to get a victim to open, clone, or initialize a malicious repository in a context where the code assistant participates in configuring the working environment.

Plausible attack chain

• Publication of a public repository appearing legitimate: project example, starter kit, cloud integration, replicated internal template, or credible fork.
• Presence in the repository of MCP configuration elements or metadata likely to be taken into account by Amazon Q Developer.
• Opening of the repository by a developer on their local workstation, often from their usual IDE.
• Processing of the configuration during setup, with execution of local commands not expected by the user.
• Access to secrets present on the machine or in the current environment.
• Potential exfiltration to a destination controlled by the attacker, or direct use of the stolen secrets to access cloud resources.

The offensive value is obvious: the developer workstation often aggregates significant technical privileges. Even without system administrator privileges, a developer user account may have:

• AWS profiles in ~/.aws/config and ~/.aws/credentials;
• SSO tokens, temporary sessions, or environment variables such as AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN;
• SSH keys for access to GitHub, GitLab, Bitbucket, or bastions;
• local project .env files;
• Docker, Kubernetes, Terraform access, or secrets stored in local managers.

Why the risk is supply chain

The repository acts here as a software supply artifact. Even without a malicious dependency in the classic sense, it becomes a container of logic or configuration capable of influencing the developer’s execution environment. The chain of trust shifts:

• it is no longer only about a compromised library;
• it is about a repository carrying instructions or parameters interpreted by a local agent;
• the compromise occurs even before build or deployment;
• the attacker targets the developer, then pivots to the cloud, CI/CD, or internal repositories.

This logic recalls already known risk families around installation scripts, Git hooks, IDE tasks, workspace files, or build files executing local commands. The novelty lies in the addition of a code assistant or agent that can automate, recommend, or initiate actions based on elements present in the repository.

Concrete impact scenarios

Scenario 1: theft of local AWS credentials

A developer opens a demonstration repository related to a cloud integration. During initialization, an untrusted MCP configuration is processed. A local command reads AWS configuration files or retrieves environment variables already loaded in the session. If these secrets are then exfiltrated, the attacker can attempt to access AWS accounts, roles, or resources according to the associated permissions.

Scenario 2: compromise of a CI/CD chain

The targeted workstation belongs to a platform engineer with rights over pipelines, container registries, or internal repositories. The locally executed code retrieves Git access tokens or registry credentials. The attacker can then push a modified artifact, alter an image, or inject an internal dependency.

Scenario 3: pivot to administration infrastructure

On some workstations, one finds kubeconfig files, Terraform access, SSO sessions, or keys for administration tools. Successful local execution can enable a pivot to Kubernetes, multiple cloud accounts, or preproduction environments.

Scenario 4: silent collection of sensitive data

Even without destructive action, the attacker may favor discreet collection: project names, directory structure, repository list, application secrets, configuration files. This reconnaissance phase may precede a more targeted attack.

Example of sensitive surface on a developer workstation

Without providing an offensive proof of concept, it is useful to recall the generally sensitive locations to monitor after suspected exploitation:

~/.aws/credentials
~/.aws/config
~/.ssh/
~/.git-credentials
~/.docker/config.json
~/.kube/config
.env
.env.local
~/Library/Application Support/
%APPDATA%

The mere fact that a local tool may be led to execute a command in the user context makes these locations critical. On macOS, Linux, and Windows, the exact paths differ, but the logic remains the same: any secret accessible to the current user becomes potentially accessible to the compromised process.

Impact

The main impact is local code execution on the developer’s workstation. In the context of a code assistant, this capability is particularly sensitive because it is part of a legitimate workflow, which can reduce the user’s vigilance.

Observable consequences may include:

• reading sensitive files accessible to the user;
• theft of cloud secrets, notably AWS;
• triggering of additional processes or scripts;
• download of supplementary tools;
• local persistence depending on available rights;
• fraudulent use of access for lateral movement.

Indirect effects must also be considered:

• exposure of customer data if the workstation contains sensitive dumps, exports, or test datasets;
• alteration of source code before commit;
• compromise of signatures or publication mechanisms;
• loss of trust in code assistants and slowdown of workflows if no governance is defined.

In many organizations, developer workstations are less segmented than a production server. They have broad Internet access, several administration tools, and long-term local storage. An attacker who executes code there can therefore find very favorable ground, even if the initial entry point appears trivial.

How to patch

The fix was published by AWS. The priority measure is to update Amazon Q Developer to the patched version released by the vendor. As the brief does not provide an exact officially verified version number, you should rely on AWS documentation and distribution channels to identify the target version in your environment.

Priority remediation steps

• identify all Amazon Q Developer installations;
• update the tool and its associated extensions from the official source;
• disable or prohibit the automatic import of untrusted MCP configurations;
• restart the IDE or workstation if the vendor recommends it;
• verify after the update that the corrected behavior is indeed in place.

Examples of update commands

The update method depends on the installation channel. The commands below are generic and must be adapted to the exact package distributed by AWS or to the IDE extension actually used in your fleet.

On Debian/Ubuntu

sudo apt update
sudo apt install --only-upgrade <amazon-q-developer-package-name>

On RHEL, Rocky, AlmaLinux, Fedora

sudo dnf upgrade <amazon-q-developer-package-name>

If the tool is distributed via a universal manager

snap refresh <package-name>

flatpak update <package-identifier>

If integration is done through an IDE extension

For VS Code, the update may be done through the graphical extensions interface or via the command line if the extension is administered that way:

code --list-extensions
code --install-extension <extension-identifier> --force

For JetBrains IDEs, the update generally goes through the built-in plugin manager or through centralized management mechanisms if your organization uses them.

On enterprise-managed workstations

It is preferable to use the standard administration channel: Intune, Jamf, SCCM, Ansible, or your MDM/EMM solution. This ensures fix uniformity and provides proof of deployment.

Post-fix checks

• confirm the installed version on a representative sample of workstations;
• verify that opening an unapproved repository no longer triggers the implicit import of untrusted MCP configurations;
• document the change in the developer workstation security baseline;
• update reference images for new machines.

If a workstation may have opened a malicious repository before the fix was applied, a simple update is not always sufficient. The incident must then be handled as suspected local code execution and a compromise review initiated.

Detection

Detection is difficult because the activity may resemble a normal workflow. Several signals must therefore be correlated: repository opening, IDE activity, child process execution, access to secret files, and unusual network connections.

Indicators of compromise to look for

• recent opening of public or little-known repositories just before suspicious activity appeared;
• creation of child processes from the IDE, the extension, or a component related to Amazon Q Developer;
• abnormal reading of files such as ~/.aws/credentials, ~/.ssh/, ~/.docker/config.json, ~/.kube/config;
• outbound connections to unusual domains or IP addresses immediately after repository setup;
• modification of shell files such as ~/.bashrc, ~/.zshrc, or Windows equivalents if persistence was attempted;
• unexpected use of AWS credentials from an unusual location, user-agent, or API sequence.

Useful log sources

• workstation EDR/XDR logs;
• telemetry of IDE child processes;
• workstation or proxy outbound network logs;
• AWS-side CloudTrail to spot abnormal use of keys or sessions;
• logs from your SSO provider if sessions were reused;
• local Git history and cloning metadata if available.

Examples of AWS-side checks

In case of suspected theft of AWS secrets, you should quickly inspect:

• CloudTrail events associated with the developer’s credentials;
• unexpected calls to sts:GetCallerIdentity, often used to validate credentials;
• creation of keys, roles, sessions, or policies;
• unusual access to Secrets Manager, SSM Parameter Store, S3, ECR, IAM, or Lambda.

A spike in enumeration calls after opening an untrusted repository can be a strong signal. Security teams can also look for correlated commands or access within the same time window on the workstation and in the cloud.

Example of a local investigation-oriented check

ps aux | grep -i -E 'code|jetbrains|amazon|q'
find ~/.aws -type f -ls
find ~/.ssh -type f -ls
grep -R "AWS_" ~/.bash_history ~/.zsh_history 2>/dev/null

These commands do not constitute a complete forensic procedure, but they can help quickly establish context on a Linux or macOS workstation. In an enterprise environment, it is better to favor EDR tools and standardized investigation procedures in order to preserve elements useful to the analysis.

Mitigation

If the fix cannot be deployed immediately across the entire fleet, several risk-reduction measures can be applied without delay. They do not replace the update, but they limit the attack surface.

Immediate measures

• prohibit opening unapproved repositories in sensitive development environments;
• disable the automatic import of untrusted MCP configurations;
• restrict cloud privileges available on developer workstations;
• remove persistent credentials in favor of short-lived federated sessions;
• segment high-privilege workstations from general-purpose development workstations.

Hardening the developer workstation

This vulnerability is a reminder that a development workstation must be treated as a sensitive asset. The following recommendations are particularly relevant:

• use temporary credentials rather than long-lived keys in ~/.aws/credentials;
• enable least-privilege policies on AWS roles accessible to developers;
• avoid durable local storage of application secrets;
• isolate unapproved projects in disposable environments, for example dedicated VMs or containers;
• disable implicit execution of tasks or scripts when opening a workspace when the IDE allows it;
• monitor child processes launched by development tools.

Teams hosted in France or working with providers on OVHcloud, Scaleway, or o2switch infrastructures should keep in mind that the risk does not depend on the host of the final project. The critical point remains the local workstation and the secrets that pass through it.

DevSecOps organizational measures

• define a usage policy for code assistants and AI agents;
• classify repositories as authorized, tolerated, or prohibited;
• set up a review of approved IDE extensions and plugins;
• train developers to treat repository metadata as potentially active;
• plan a rapid secret rotation procedure in case of suspicion on a workstation.

In the French context, it is also useful to monitor CERT-FR publications when a topic broadly affects workstations, the development chain, or cloud access. Even in the absence of a specific alert, workstation hardening and secret management guides remain directly applicable.

Secret rotation in case of potential exposure

If a suspicious repository was opened before the fix, preventive rotation of secrets accessible from the workstation should be considered:

• AWS access keys and associated profiles;
• GitHub, GitLab, Bitbucket tokens;
• SSH keys;
• container registry credentials;
• Kubernetes, Terraform, or other administration tool credentials.

Rotation must be accompanied by a review of actions performed with the old secrets, in order to identify any malicious use prior to their revocation.

Ecosystem perspective

Beyond the Amazon Q Developer case, this incident is part of a broader trend: code assistance tools are becoming highly trusted components, capable of interacting with the repository, the IDE, the terminal, and sometimes remote resources. The more integrated these tools are into the workflow, the more significant the consequences of unsafe behavior become.

Two lessons emerge:

• the security of development agents must be assessed like that of a local execution component;
• third-party repositories must be treated as potentially active inputs, not just as code to read.

For CISOs, this implies broadening threat models. Security reviews can no longer be limited to deployed applications or build dependencies. They must integrate:

• AI development assistants;
• workspace and extension configurations;
• setup automation mechanisms;
• cloud rights and secrets present on laptops.

This approach aligns with hardening best practices already known in application security: principle of least privilege, environment isolation, strict secret management, review of third-party components, and traceability of sensitive actions. On FailleWeb, these topics directly overlap with the recommendations in the category /categorie/pratiques, useful for formalizing developer workstation and software chain standards.

The practical point to remember is simple: if Amazon Q Developer is used in your organization, you must verify without delay that the patched version published by AWS is indeed deployed, block the automatic import of untrusted MCP configurations, and treat any prior opening of a suspicious repository as a potential developer workstation compromise incident. In a context where a simple repository can become a vector for local execution and then cloud secret theft, the most effective response combines the vendor fix, rotation of exposed access, and durable hardening of development environments. To go further on operational hardening, the category /categorie/pratiques brings together the most useful cross-cutting measures.