AI Coding Assistant Hijack Spreads Shai-Hulud Across About 100 Repositories

An AI coding assistant hijack at an unnamed SaaS provider turned a trusted developer workflow into a software supply-chain attack path.

Mandiant investigated an intrusion in which a threat actor compromised a SaaS provider and hijacked an active AI coding-assistant session on a developer’s workstation. The assistant then recommended an external software package that the attacker had poisoned. Once that recommendation was accepted, the attacker used the active session to install an infostealer through a poisoned PyPI package.

The intrusion did not stop at one developer endpoint. Mandiant says the attacker harvested GitHub OAuth tokens and deployed the self-propagating Shai-Hulud worm across approximately 100 internal code repositories. The worm automated repository-secret theft and source-code exfiltration.

How the AI Coding Assistant Hijack Led to a Poisoned Recommendation

The distinctive part of this incident was not simply the malicious package.

According to Mandiant, the AI coding assistant, whose active session had been hijacked, operated as a trusted interpreter within the developer environment. It recommended installing an external software package that the attacker had poisoned. The recommendation was then accepted.

That trust decision changed the attack path.

Instead of relying only on a developer independently finding and installing a malicious dependency, the attacker exploited a workflow where an AI assistant could influence dependency selection. Mandiant says the assistant effectively became a trojan horse after the poisoned recommendation was executed.

The attack path also exposes a human trust problem in AI-assisted development: developers may treat recommendations from an embedded coding assistant as operationally trustworthy rather than independently evaluating each dependency. Verifying AI-recommended packages before installation adds a human review layer before generated recommendations become executable actions.

However, important initial-access details remain undisclosed. Mandiant has not publicly explained how the SaaS provider was compromised or how the attacker hijacked the active AI coding-assistant session. The report also does not identify the SaaS provider or the coding assistant involved.

Therefore, organizations should not assume that a vulnerability in the unidentified AI coding assistant caused the intrusion. They also should not assume that a particular technique was used to hijack its active session.

How Shai-Hulud Reached About 100 Internal Repositories

Once the poisoned recommendation was accepted, the attack moved beyond the AI assistant itself.

Mandiant documented the following sequence:

• The attacker used the developer’s active session.
• A poisoned PyPI package was used to install an infostealer.
• The attacker harvested GitHub OAuth tokens.
• The attacker deployed the self-propagating Shai-Hulud worm.
• Shai-Hulud spread across approximately 100 internal code repositories.
• The worm automated the theft of repository secrets.
• It also programmatically exfiltrated proprietary product source code.
• The attacker then extended the supply-chain compromise further.

Mandiant says a package inside the organization’s official namespace was poisoned. Another employee later pulled the compromised version, resulting in a secondary downstream infection.

This step is particularly important for development teams. Once malicious code reached an organization-controlled package namespace, another employee could encounter the compromise through what appeared to be an internal, legitimate software source.

Why GitHub OAuth Tokens Expanded the Attack Surface

The theft of GitHub OAuth tokens connected the compromised developer session with repository access.

GitHub OAuth access tokens can authorize API requests on a user’s behalf within the token’s granted scopes and the user’s existing permissions. Exposed tokens should therefore be treated as sensitive credentials and revoked when compromise is suspected.

In this incident, Mandiant explicitly confirms that the attacker harvested GitHub OAuth tokens before deploying Shai-Hulud across the internal repositories.

Mandiant recommends preventing extensions from directly accessing raw API keys, long-lived OAuth tokens, and other secrets. It also recommends routing dependency traffic through controlled internal repositories.

For AI-assisted development specifically, Mandiant recommends verification hooks that validate AI-recommended third-party dependencies against cryptographic checksums and approved allowlists before installation.

These controls address the mechanism documented in this incident rather than treating AI coding assistants as inherently malicious.

How Enterprises Can Reduce Exposure to Similar AI Supply-Chain Attacks

This incident crosses several security boundaries: the developer endpoint, AI assistant, Python package ecosystem, OAuth credentials, internal repositories, and organization-controlled package namespace.

Security teams should therefore avoid relying on a single control.

For AI-assisted development environments, organizations can:

1. Validate AI-recommended dependencies against approved allowlists and cryptographic checksums.
2. Route dependency downloads through controlled internal package repositories.
3. Keep long-lived OAuth tokens, API keys, and other secrets outside extension-accessible locations.
4. Review repository permissions and minimize unnecessary token privileges.
5. Revoke exposed repository tokens after a suspected compromise.
6. Investigate developer endpoints for suspicious package installations and infostealer activity.
7. Review internal package namespaces before restoring trust after a supply-chain incident.

The first three measures directly reflect Mandiant’s recommendations for this case.

Where Hexnode Fits Around a Compromised Developer Endpoint

The Shai-Hulud incident involved a developer workstation workflow before spreading into repository and package infrastructure. That makes endpoint management and endpoint investigation supporting layers, but they do not replace repository, OAuth, or package-registry security controls.

Use Hexnode UEM to Control the Developer Endpoint Layer

Hexnode UEM gives IT teams device compliance, application management, configuration, and custom-script capabilities for managed developer endpoints.

For example, IT administrators can use Hexnode Genie within the Hexnode UEM console to generate AI-assisted scripts, refine them in the Script Editor, and deploy them to managed Windows, macOS, and Linux workstations through Hexnode UEM’s script execution capabilities.

Compliance controls can also identify devices that violate configured requirements, including cases involving missing required applications or blocklisted applications.

However, Hexnode UEM does not replace PyPI dependency validation, GitHub repository controls, token revocation, or internal package-registry security.

Featured resource

Why XDR Is Stronger With UEM

See how Hexnode UEM and XDR bring proactive endpoint management and threat response into a connected security workflow.

Download the whitepaper

Investigate Suspicious Developer Activity with Hexnode XDR

If suspicious activity reaches a managed Windows or macOS endpoint covered by Hexnode XDR, security teams can investigate associated endpoint behavior.

Hexnode XDR brings threat hunting, threat investigation, and endpoint response into the security workflow. Threat investigations provide process metadata such as process names, command lines, file paths, and hashes, while the Process Tree visualizes parent-child process relationships.

Where investigation identifies malicious endpoint activity, responders can use actions such as:

• Isolate Device to restrict network communication while preserving XDR management connectivity.
• Kill Process or Kill Process Tree to stop identified malicious execution.
• Quarantine File to move a malicious file into a restricted location.

These controls could support investigation and containment after suspicious activity appears on a developer workstation.

These capabilities strengthen endpoint investigation and containment around the incident. Repository security, dependency validation, OAuth token revocation, and package-registry controls remain separate parts of the response.

Treat AI Coding Sessions as Part of the Software Supply Chain

The AI coding assistant hijack changes the security boundary around AI-assisted development. Coding-assistant sessions, dependency recommendations, repository credentials, and package sources now need controls that reflect the access they can exercise within developer workflows.

However, the available report does not disclose how the SaaS provider was initially compromised or how the active AI session was hijacked.

The response therefore needs to cover the entire development path.

Organizations should validate AI-recommended dependencies, isolate sensitive credentials, control package sources, protect developer endpoints, and review repository permissions. If an incident occurs, endpoint containment should happen alongside token revocation and investigation of repositories and package infrastructure.

AI-assisted development can accelerate software delivery, but its outputs should not inherit trust automatically. Applying a Zero Trust mindset to AI workflows means treating AI-recommended dependencies and generated code as inputs that require verification before execution, much like untrusted third-party software. Coding-assistant sessions, credentials, dependencies, generated code, and execution privileges should receive controls proportionate to the access they hold.