Security Advisory: $foo compromised on $packagemanager

The package name changes. The attack pattern changes. The workflow you need to combat it doesn’t – whatever the headline will be next week.

You've probably seen alerts this week. Between pgserve, fairwords, openwebconcept, @automagik/genie, kube-health-tools all on npm while kube-node-health and xinference on PyPI have the security community socials all abuzz. 

One package has worm-like behavior and acts as a remote access trojan harvesting credentials that executes at installation in a postinstall hook. Another package will run a subprocess upon import.

You've maybe read variations of these sentences before, with different names. That's the point.

Multiple packages. Multiple registries. Multiple threat actors. Multiple teams writing incident reports. Some heavily used by engineering teams, some more niche.

The attack template for malicious open-source packages is not creative. Attacker gains publish access, whether compromising maintainer credentials through phishing, registering a plausible look-alike domain, etc.

The package name is a variable. Everything else is becoming boilerplate.

What this week's wave showed is how fast the template executes and discovery, forensics, and analysis are all improving to combat the increasing the pace of supply chain breakdowns. Kudos to the wider security community who have discovered and reported on these incidents.

The true value for the org comes from a workflow aimed at solving the root causes of the problem, not the latest symptoms.

It's not just about the package version right?

Most SCA tools can answer one question well: is this package version in your dependency tree? That's a good place to start.

For malicious packages like the ones above, the answer is always yes: postinstall hooks run during npm install; code in __init__.py runs on import. You installed it, you ran it. 

That's why the first question in incident response is always exposure. You need to know whether or not the package is in your supply chain at all.

For Semgrep customers

1. Trigger a new scan if you haven't run one recently on your active projects. If you're on managed scans or CI scanning, verify the last run completed successfully.

2. Check the advisories dashboard for direct findings in your org:

• pgserve, fairwords, openwebconcept, @automagik/genie → Advisory 

• xinference → Advisory

3. Use dependency search to check if any of these packages are installed across your repos:

• pgserve, fairwords, openwebconcept, @automagik/genie: https://semgrep.dev/orgs/-/supply-chain/t/dependencies?packages=pgserve%3Aexact-name,fairwords%3Aexact-name,openwebconcept%3Aexact-name,%40automagik%2Fgenie%3Aexact-name

• xinference: https://semgrep.dev/orgs/-/supply-chain/t/dependencies?packages=xinference%3Aexact-name

• kube-health-tools, kube-node-health: https://semgrep.dev/orgs/semgrep/supply-chain/t/dependencies?packages=kube-health-tools%3Aexact-name,kube-node-health%3Aexact-name 

4. Check the full advisories feed at https://semgrep.dev/orgs/-/advisories for other recent malicious dependency detections.

These dependencies are malicious so versions will be pulled by the registries, but everyday secure coding bugs still apply so should be reviewed regularly.

Indicators of compromise

pgserve, fairwords, openwebconcept, @automagik/genie (npm)

Affected packages:

• pgserve 

• fairwords

• openwebconcept

• @automagik/genie 

See advisory for affected versions.

xinference (PyPI)

Affected packages:

• xinference

See advisory for affected versions.

kube-health-tools, kube-node-health (npm / PyPI)

Affected packages:

• kube-health-tools

• kube-node-health

The security advisory workflow

The specific package name doesn't change what you need to do. This playbook applies regardless of which $foo shows up in your supply chain alerts next.

1. Determine exposure. Use dependency search to query your entire codebase for the compromised package and version range. Don't guess about blast radius, get a comprehensive review quickly.

2. Scan for malicious findings. Trigger a scan and check the advisories dashboard.

3. If you're affected, rotate everything. Assume anything matching TOKEN, SECRET, KEY, PASSWORD, AWS_*, GITHUB_*, NPM_*, OPENAI*, ANTHROPIC* was harvested. Also assume ~/.npmrc, ~/.aws/credentials, and ~/.ssh/ were read. Rotate all of it. If a publish token was present, audit the packages it could reach and check their recent publish history for unauthorized versions.

4. Pin your dependencies. Lock to exact versions and not ranges. package-lock.json with npm ci for Node; requirements.txt with exact pins for Python. Semgrep Supply Chain's autofix PRs help handle the clean-version upgrade once you've confirmed it's safe.

5. Get back to work. This is recoverable if you were impacted. Rotate the credentials, update the lockfiles, re-scan clean. The goal is to spend as little time on malicious dependencies as possible and get back to shipping secure code.

Run through this workflow to check your status each time you want to understand your exposure.

For incident response steps: Semgrep Supply Chain incident response docs →