OpenSourceMalware’s October 30, 2026 investigation describes a malicious Claude Code extension identifying itself as anthropic.claude-code version 2.1.313. The report describes an October 29 incident and credits Dean Hardcastle with alerting the researchers. Original investigation.
The researchers found JavaScript inserted before the normal extension code. It runs when the editor loads that file, without requiring a Claude conversation. The code adds an SSH key, attempts to enable SSH, opens a reverse tunnel and creates startup instructions. Reported code behavior.
How an extension can leave SSH access behind
SSH lets someone log into another computer. An authorized public key is an accepted login credential. Someone holding the matching private key can authenticate if the server’s other requirements are met. Adding an unwanted key can therefore create another way into an account. OpenSSH authentication reference.
A reverse tunnel begins with an outbound SSH connection. It can carry connections back to a service on the computer that opened it. This can provide access without a direct incoming connection to that computer. Whether forwarding succeeds depends on the connection and server settings. OpenSSH forwarding reference.
Startup instructions can launch unwanted code again after a restart or login. Security reports call this persistence. Those instructions may sit outside the extension directory, so deleting an extension may leave access behind.
Reading code shows what it attempts. Files, process records and authentication logs are needed to establish what happened on a particular machine. An attempt to start SSH is different from a successful login.
What remains uncertain about the extension’s source
The report’s correction names Cursor’s marketplace and excludes Open VSX, Microsoft’s extension and npm from this finding. But it also says the source of the examined directory is unestablished. Its analysis does not establish an Anthropic infrastructure compromise. Correction and evidence limits.
An extension’s displayed name and version cannot prove where its files came from. Keep installation records and the files themselves when checking a machine. Do not extend findings about one examined version to other versions without evidence.
Save the extension files before comparing them
Record the editor, extension identifier, version, installation source, affected account and approximate installation time. Save the installed files using your incident-response process. Do not reopen the extension to see what it does. Check separate editor profiles and remote development environments separately.
The report lists this SHA-256 digest for extension.js:
ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15
A digest is a value calculated from file contents. Compare the same file, rather than an extension archive, bundled executable or whole directory. On Linux with GNU sha256sum, this reads a preserved copy without executing it:
sha256sum -- '/mnt/evidence/developer-host/extension.js'
Replace the path with your evidence-file path. Compare the first output field with the reported digest. A match establishes matching content, not execution or installation source. A mismatch does not establish safety: another file or modified build will produce a different value. GNU checksum reference.
Save the original path, collection time and collection method with the result.
If evidence suggests malicious execution, follow your organization’s isolation procedure. Ask responders about collecting memory and running-process evidence before shutting down. Use a clean device to administer affected accounts.
Inspect the affected account’s SSH keys
A key fingerprint is an identifier calculated from a key. For an affected Unix account, this command displays fingerprints from its existing authorized-keys file:
ssh-keygen -l -E sha256 -f "$HOME/.ssh/authorized_keys"
These options list fingerprints, select SHA-256 and read the specified file. They do not add or remove keys. Run the command in the affected account’s context; an administrator’s $HOME points to a different directory. Key comments can be changed, so they cannot establish ownership. OpenSSH key utility reference.
The reported fingerprint is SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk. Reported SSH indicator.
Check who owns an unfamiliar key before attributing it to an attacker. Save keys and startup entries before removing them.
A missing file or parsing error needs investigation; do not create a new file just to make the command succeed. SSH can use other configured key files or authentication sources, so this default path is only a starting point. SSH server reference.
Read SSH logs for a specific time window
On Linux with systemd, inspect the SSH service journal around the suspected activity. The --utc option in this command requires systemd 217 or later:
journalctl --unit=ssh.service --unit=sshd.service \
--since='2026-10-30 08:00:00 UTC' \
--until='2026-10-30 10:00:00 UTC' \
--utc --no-pager
Replace these illustrative dates with the relevant interval. The two unit names are alternatives commonly used for SSH. The command reads accessible stored records without starting the service or changing logging. Both time boundaries are inclusive. The UTC suffixes set the input time zone; --utc controls displayed time. systemd journal reference.
Empty output does not prove that nothing happened. Check the service name, your access, retained dates and logging destination. Authentication messages may be in files instead. The Linux system logging guide explains how to find them. Avoid broad permission changes merely to make a query work.
Look for successful public-key authentication, the account, the time and any recorded fingerprint. This is a synthetic illustration, not an observed incident record. Actual formats vary:
Oct 30 08:17:42 dev-laptop-12 sshd[4821]: Accepted publickey for developer from 127.0.0.1 port 52418 ssh2: ED25519 SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk
If genuine and intact, such a record supports successful authentication with that key. It does not show which commands followed, what data was read or who controlled the key. SSH logging settings affect what records exist. OpenSSH logging reference.
The loopback address 127.0.0.1 means the connection reached SSH locally. A forwarded connection can arrive that way, so loopback alone does not identify the legitimate user as its origin. SSH forwarding reference.
Keep each finding separate in the timeline
A matching file, an outbound connection and a successful login answer different questions. The following timeline is entirely synthetic. It shows how to record conclusions without filling gaps with assumptions.
| UTC time | Illustrative evidence | What it supports |
|---|---|---|
| 08:10 | Preserved file matches the reported digest | Matching content was present when collected; execution is unproven |
| 08:12 | Existing process records link the editor to an unexpected SSH process | A process started; inspect its command and account |
| 08:13 | Network records show that process connecting outward | A connection occurred; successful forwarding is unproven |
| 08:17 | Authentication log records the reported fingerprint | The key authenticated, if the record is genuine and intact |
| 08:20 | Saved startup entry references an unexpected executable | Startup was configured; later execution is unproven |
Do not assume this sequence occurred on your machine. Check clock differences and collection delays before ordering events. Record missing evidence explicitly. The guide to reading logs covers time windows and event correlation in more detail.
For startup entries, inspect the executable path and account. A familiar-looking name does not prove that the operating system installed it. Existing audit records may explain process starts or file changes. Turning auditing on now cannot recreate earlier activity; see the Linux audit logging guide.
Compare logs already retained in Fluxtail
If the affected machine’s authentication logs were already delivered to and retained in Fluxtail, narrow the investigation to the relevant stream and time window. Search for the reported fingerprint, inspect the raw matching events and read nearby SSH events for the same account. Check that the full fingerprint survived collection before relying on that search.
Use host or service fields only after verifying how those fields arrived. Record the event time, host, account and authentication result alongside the evidence source. Compare those records with the extension files and process evidence saved separately.
Fluxtail supports centralized log search and browser-based Live Tail inspection. The live-tail incident-response guide explains how stream and time-window investigation helps keep the search focused. Live Tail can show newly arriving events; it cannot recover logs that were never collected or prove that a machine is clean.
Keep private keys, environment dumps and unrestricted shell history out of investigation uploads.
Remove unwanted access, not just the extension
Save evidence first. Then identify unwanted SSH keys, tunnel processes and startup tasks with the responders handling the incident. Remove confirmed unwanted access through the agreed recovery process. Deleting the extension alone may leave files or tasks it created elsewhere.
From a clean device, revoke exposed credentials and active sessions. Replace affected tokens, passwords and keys. Check whether the account could access repositories, cloud accounts or keys used to sign software. Base those actions on what was available to the account and what the investigation finds. Access to credentials does not, by itself, prove they were stolen.
If an attacker logged in, the known extension files may show only the beginning. The attacker could have made other changes. Rebuilding from a trusted image may be safer when you cannot establish what changed or remove it reliably. Check backups and needed files before bringing them onto the rebuilt machine.
Finish with a clear record: which file was found, whether execution was established, which access was observed, what was removed and what remains unknown.