PostHog's official npm packages hit by the Shai-Hulud 2.0 worm: a misconfigured GitHub workflow handed attackers the publish token

Who is affected

The malware runs at install time. Your code never has to import or call these packages. Treat yourself as affected if a developer machine or CI job ran npm install (or similar), pulled in one of the versions in the table or the list below it, and allowed install scripts to run. The most likely window is from 04:04 UTC on 2025-11-24 until the versions were deleted (PostHog says by 09:30 UTC). PlainCVE’s judgement is that if a lockfile already recorded a malicious version, or a local cache or internal package mirror kept a copy, a later reinstall could still bring it back, so check those too. No source addresses this case directly, but PostHog’s post-mortem and issue both advise deleting cached dependencies.

PostHog’s post-mortem lists only the “most relevant” packages. OSV also lists the following PostHog packages as malicious (compiled from this page’s OSV query on 2026-09-28; each package has its own MAL ID, searchable by package name on osv.dev; PostHog has not named individual safe versions for them):

• @posthog/clickhouse 1.7.1, @posthog/hedgehog-mode 0.0.42, @posthog/icons 0.36.1, @posthog/lemon-ui 0.0.1, @posthog/nextjs-config 1.5.1, @posthog/nuxt 1.2.9, @posthog/piscina 3.2.1, @posthog/plugin-contrib 0.0.6, @posthog/plugin-server 1.10.8, @posthog/rrweb 0.0.31, @posthog/rrweb-player 0.0.31, @posthog/rrweb-record 0.0.31, @posthog/rrweb-replay 0.0.19, @posthog/siphash 1.1.2, @posthog/web-dev-server 1.0.5
• Version 0.0.8 of these 30 plugin packages: @posthog/automatic-cohorts-plugin, @posthog/bitbucket-release-tracker, @posthog/currency-normalization-plugin, @posthog/customerio-plugin, @posthog/databricks-plugin, @posthog/drop-events-on-property-plugin, @posthog/event-sequence-timer-plugin, @posthog/filter-out-plugin, @posthog/first-time-event-tracker, @posthog/geoip-plugin, @posthog/github-release-tracking-plugin, @posthog/gitub-star-sync-plugin, @posthog/heartbeat-plugin, @posthog/ingestion-alert-plugin, @posthog/intercom-plugin, @posthog/kinesis-plugin, @posthog/laudspeaker-plugin, @posthog/migrator3000-plugin, @posthog/netdata-event-processing, @posthog/pagerduty-plugin, @posthog/plugin-unduplicates, @posthog/postgres-plugin, @posthog/sendgrid-plugin, @posthog/snowflake-export-plugin, @posthog/taxonomy-plugin, @posthog/twilio-plugin, @posthog/twitter-followers-plugin, @posthog/url-normalizer-plugin, @posthog/variance-plugin, @posthog/zendesk-plugin

npm registry metadata shows every malicious version of these 56 packages was published between 04:04 and 04:13 UTC on 2025-11-24, and none of them is in npm’s version lists any more. This page’s query covered npm packages whose names contain posthog, so it is not guaranteed to be complete.

Other points:

• PostHog’s post-mortem says the latest versions, published after it discovered the attack, are known-good. The malicious versions were deleted from npm and replaced with newer releases; see the table for the safe versions.
• Deletion time: PostHog says it had found and deleted the malicious packages by 09:30 UTC. However, npm registry metadata shows posthog-docusaurus last modified at 09:57 UTC and posthog-plugin-hello-world at 14:11 UTC. The registry does not record deletion times directly, so it is not certain every package was gone by 09:30.
• Publish times: PostHog’s post-mortem says 04:11 UTC, while npm registry metadata shows posthog-node 5.11.3 published at 04:04 UTC, 5.13.3 at 04:09 UTC and 4.18.1 at 04:13 UTC. This page uses 04:04 as the start of the exposure window.
• PostHog says it knows of no customer production deployments that used the malicious versions.
• Installs that skip lifecycle scripts were less exposed (for example, pnpm 10 does not run dependency install scripts by default).
• Wiz found posthog-node in 25% and posthog-js in 15% of the environments it scanned. That shows how common the packages are, not how many were infected.

How it works

There are two layers here: how PostHog itself was breached, and what the malicious package did to whoever installed it.

Layer one: a “pwn request” handed over the publish token

GitHub Actions’ pull_request_target trigger runs as the base repository, with its secrets and write access. It exists so the workflow definition comes from the trusted main branch. The trouble starts when the workflow then checks out and runs code from an outside pull request: that stranger’s code gets the same privileges. GitHub Security Lab calls this mistake a “pwn request”.

A workflow PostHog merged on 2025-09-11 did exactly that. It used pull_request_target and also ran a reviewer-assignment script taken from the PR. In its post-mortem PostHog admits its developers believed pull_request_target protected the code being run, when in fact it only controls where the workflow definition is read from.

What happened (conceptual summary):

1. The attacker opened a malicious PR, and its code ran in the trusted CI context.
2. That code stole a bot account’s GitHub personal access token (PAT).
3. The attacker used the token to change a workflow and dump the repository’s secrets, including the npm publish token.
4. The attacker used the npm token to publish worm-infected versions of the packages.

The flawed pattern (conceptual illustration, not PostHog’s actual configuration):

on: pull_request_target        # runs with base-repo permissions and secrets
jobs:
  assign:
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # checks out outside PR code
      - run: node scripts/assign-reviewers.js            # runs the PR's code → it gets the secrets

A safer pattern:

on: pull_request               # outside PRs run with no secrets and read-only access
permissions:
  contents: read
jobs:
  check:
    steps:
      - uses: actions/checkout@v4
      - run: node scripts/check.js
# Anything that needs write access goes in a separate workflow triggered by workflow_run,
# which only handles the results and never runs PR code

Layer two: what the Shai-Hulud 2.0 worm did

This summary comes from the research reports. This page did not open any package file or malware sample.

• Starts at install: a preinstall script (setup_bun.js) installs the Bun JavaScript runtime, then runs a large obfuscated program, bun_environment.js. Datadog notes that using Bun helps it avoid tools that only watch Node.js.
• Steals credentials: PostHog says it uses the open-source TruffleHog scanner to search the environment for credentials of any kind. According to Datadog and StepSecurity, it also collects GitHub tokens, npm tokens, environment variables, and AWS, GCP and Azure cloud credentials and secret-manager contents; Wiz counted hundreds of cloud credentials among those leaked across the whole wave.
• Posts them publicly: it creates new public GitHub repositories with the victim’s own token and posts the stolen data there. Wiz also saw one victim’s secrets posted under unrelated users’ accounts.
• Leaves a backdoor: it registers a self-hosted GitHub Actions runner named SHA1HULUD and adds .github/workflows/discussion.yaml. That workflow listens for new GitHub Discussions, so the attacker can run commands on the machine registered as that runner just by creating a new Discussion in the victim’s repository with the command in its body.
• Spreads itself: with a stolen npm token it infects up to 100 packages the victim maintains (according to Aikido, the first wave’s limit was 20).
• Destroys data: according to Aikido and Datadog, if it can neither steal credentials nor spread, it tries to wipe the user’s home directory. StepSecurity also describes Linux file overwriting meant to erase evidence.
• Other behaviour: it runs immediately in CI but in the background on developer machines, and it tries to escape Docker containers through privileged mounts.

This maps to CWE-506 (Embedded Malicious Code).

Timeline

Further reading

• Scoring: there is no CVE and no NVD score. GitHub’s advisory for @posthog/core gives no CVSS number and rates it Critical (Malware). GitLab gives posthog-js a CVSS 3.1 score of 8.6 (AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H). Because that score is for a different package, this page leaves its severity field empty.
• Where sources disagree:
  • Scope of affected packages: PostHog’s post-mortem lists only the 8 “most relevant” packages (10 versions) and its issue adds @posthog/wizard, for 9 in total; OSV lists 56 PostHog packages, including @posthog/core, posthog-react-native 4.12.5 and posthog-plugin-hello-world.
  • Deletion time: PostHog says by 09:30 UTC; npm registry shows last-modified times of 09:57 UTC for posthog-docusaurus and 14:11 UTC for posthog-plugin-hello-world.
  • Publish time of the malicious versions: PostHog’s post-mortem says 04:11 UTC, but npm registry metadata shows posthog-node 5.11.3 was already published at 04:04 UTC.
  • Size of the whole wave: Aikido counts 492 packages; Datadog counts 796 and calls that a lower bound; Wiz estimates about 700 to 800, and also counted 775 exposed GitHub tokens plus 373 AWS, 300 GCP and 115 Azure credentials; StepSecurity’s early count was more than 70; PostHog’s issue says “over 300”.
  • Repository description strings: StepSecurity and Aikido report “Sha1-Hulud: The Second Coming”. Wiz separately reports a potential second phase first seen at 22:45 UTC on 11/25, in which one victim’s private repositories were made public using credentials stolen in phase one; the description used for that phase is “Sha1-Hulud: The Continued Coming”.
  • Wiz says the second wave reuses the first wave’s name and methods but may be run by different people.
• Where PostHog fits in: PostHog was breached through its own CI misconfiguration, not because a maintainer installed an infected package. Datadog calls this one of several ways the attackers got in. Once the malicious versions were published, PostHog’s packages became carriers that could infect other maintainers.
• npm context: the attack came shortly before npm’s 2025-12-09 deadline for revoking classic tokens. GitHub’s September 2025 plan includes retiring classic tokens, granular tokens that last at most 7 days, trusted publishing, and required 2FA for local publishing with FIDO keys replacing one-time codes.
• AI angle: two affected packages are named @posthog/ai and @posthog/agent, but no source links the attack itself to AI, and this page does not suggest one.
• Could not be confirmed: whether GitHub has GHSA advisories for posthog-node and posthog-js; how many times the malicious versions were downloaded while live; what CISA’s alert on the first Shai-Hulud wave says (the page could not be read and is not used here).