A package install reads your home directory. This week two of them did it on purpose.

On 23 September, OSV recorded malicious versions of two related packages. On npm, memos-cloud-openclaw-plugin under the memtensor scope, at versions 0.1.21, 0.1.23 and 0.1.25. On PyPI, memoryos at version 2.0.34. The interleaved version numbers are worth noticing: 0.1.22 and 0.1.24 are reported clean, so a team pinning to a recent version had roughly even odds.

An open issue on the project's own GitHub repository, filed by an outside researcher, reports that versions were published to npm that do not correspond to any commit or tag in the repository, and says the package's npm publish token appears to have been compromised. That is the researcher's assessment. The maintainers have not publicly commented, and no primary source describes a compromise of the company itself, so we are not going to.

The payload is a Go binary called sckit that executes when the package loads. OSV describes functions named credentialPaths, readCredentialFile and extractJSONCredentials that target a specific list of files: .npmrc, .pypirc, .git-credentials, .netrc, id_rsa, id_ecdsa, id_ed25519, .vault-token, msal_token_cache, access_tokens.json and access_tokens.db. It collects credentials from the home directory and sends them to servers under skyleen[.]fr.

There is nothing sophisticated in that list, and that is the point worth internalising. It is simply the set of places developer tooling stores long-lived secrets by convention. Registry tokens, git credentials, SSH private keys, a Vault token, cached cloud tokens. Everything a working developer machine accumulates and rarely audits.

In CI the implant adds a second stage. OSV records that when GITHUB_ENV is set, it appends a BASH_ENV entry pointing at a script inside the package, which gives it a hook into subsequent shell invocations in the job. The quoted behaviour concerns capturing PyPI publishing tokens.

When you add a dependency, you are asking a program to run on your machine with your permissions. Package managers run install scripts, and imported modules execute code at load time. There is no sandbox between a dependency and your home directory by default, on any of the major ecosystems.

That means the blast radius of one bad package is not the feature that package provides. It is every credential the process can read. A small utility library that helps format dates has, by default, exactly as much access to your SSH key as your deployment script does.

This is why the rotation list after an incident like this is so much longer than the package itself suggests. The question is not what the package could legitimately need. It is what was reachable from the account that ran the install.

Work from the machine outward. Every credential that was readable from the home directory of the user that ran the install should be treated as known to someone else.

On 18 September GitHub shipped a new npm token permission level, read and write, stage only. A workflow with that token runs npm stage publish to submit a version for review, and npm rejects a direct npm publish attempt with that token even if it is configured to bypass two-factor authentication for automation. A maintainer then approves the release with a second factor. GitHub says npm is targeting January 2027 to remove direct publishing through bypass-2FA tokens.

That change is aimed squarely at this class of attack, where the entire objective is a publish token sitting in a release job. A stolen stage-only token cannot ship anything to your users on its own.

It has a genuine cost, and it is worth stating rather than glossing: releases now require a human being with a second factor, which is slower and occasionally inconvenient at the wrong hour. That is the trade. Given what a stolen publish token does to everyone downstream of you, it is a reasonable one.