Catch-Up Bulletin, June 23 to August 28, 2026: The keyv npm Worm, Two Container-Escape Kernel Bugs, OpenSSH 10.4, and Actively Exploited GitLab, Metabase, and vCenter Flaws

This bulletin covers the nine-week gap since the June 23 libssh2 bulletin, ranked by how much of this audience it touches. The headline is the August 4 keyv / CHAINDROP npm worm: a compromised maintainer account trojanized keyv, flat-cache, file-entry-cache, cacheable-request, and cache-manager (over two billion summed monthly downloads across the affected packages, per Aikido, with heavy overlap between them), then used stolen npm tokens to spread to more than 440 packages. It steals cloud, GitHub, npm, Kubernetes, Vault, and AI-tool credentials, and it persists by writing hooks into .claude/settings.json and .vscode/tasks.json so cloning a repo and opening it in VS Code or Claude Code can re-infect. Two Linux kernel local-root bugs, GhostLock (CVE-2026-43499) and RefluXFS (CVE-2026-64600), both escape default Docker containers and both have public or demonstrated exploits. OpenSSH 10.4 fixed a client-side use-after-free (CVE-2026-60002). Three self-hosted platforms were exploited as zero-days or within days of disclosure: GitLab CVE-2026-19478 (CVSS 9.4, unauthenticated modify/delete of public projects), Metabase CVE-2026-72898 (CVSS 10.0, unauthenticated SQL injection to admin), and vCenter CVE-2026-59310 (CVSS 9.8, syslog path traversal to RCE). Also inside: the July 14 AsyncAPI import-time npm compromise that defeats --ignore-scripts, Langflow on CISA KEV, the Node.js July 29 security release, the RubyGems legacy API key leak, and a roll-up of edge-appliance and developer-tool items. If you do nothing else: sweep for the keyv IOCs, patch kernels, and update any exposed GitLab, Metabase, or vCenter.

Framing note: this is a round-up, not the usual single-incident bulletin, so each item gets the affected range, the fix, a check, and an action rather than a full response guide. Items are ordered by breadth of exposure for developers, ops, AI/ML infrastructure operators, and self-hosters, not by CVSS. Every item is sourced to a vendor advisory, a named research team, or CISA KEV; where a detail (victim names, exploitation telemetry) is available only through press coverage of a named team's findings, the text attributes it that way. All "as of" statements are anchored to August 28, 2026. Where two primary sources disagreed on a detail, the disagreement is stated rather than resolved by guesswork.

Priorities, by what you run

The table maps each item to who needs to act. "Higher" means confirmed compromise or in-the-wild exploitation with a broad footprint in this audience; "Medium" means a real fix to apply on your normal cadence, or a narrower footprint; "Lower" means awareness or a niche check.

Categorization source: this ordering is the bulletin's own framing, derived from confirmed exploitation or compromise status (CISA KEV listings, vendor statements, named research team telemetry) weighted by how common the affected component is in developer, ops, and self-hosted environments. It is not a CVSS sort.

1. keyv / CHAINDROP: the Shai-Hulud worm's sixth wave (August 4)

On August 4, 2026 at roughly 09:00 UTC, an attacker holding the compromised GitHub account of the keyv maintainer pushed malicious releases of the jaredwray monorepo packages to npm. Elastic Security Labs, Wiz, Aikido, and StepSecurity published analyses the same day; the worm component is named CHAINDROP by Elastic and the campaign self-identifies as "Shai-Hulud: Here We Go Again." The initial packages were keyv@6.0.0, flat-cache@6.1.24, file-entry-cache@11.1.6, cacheable-request@13.0.20, cacheable@2.5.1, cache-manager@7.2.10, and five smaller siblings. The three largest alone are downloaded well over a billion times a month in aggregate (keyv around 600 million, flat-cache around 580 million, file-entry-cache around 570 million, per Aikido's download figures; these are summed download counts, not unique systems, and overlap heavily). Within a day the worm had used stolen npm tokens to republish more than 440 packages across 1,381 versions (Aikido's August 5 count; StepSecurity counts 444 packages and 2,212 versions), including packages from Deliveroo, Picsart, and Qlik.

The mechanism is a preinstall script in package.json that runs node setup.mjs, which downloads the Bun runtime (v1.3.13, fetched from the official oven-sh GitHub releases) and executes a 728 KB obfuscated stealer, Math_Symbol.js in the keyv-family packages and math_init.js in worm-propagated ones. The stealer sweeps more than 300 credential patterns: npm tokens (validated against registry.npmjs.org/-/whoami), GitHub PATs, OAuth and App tokens, the Actions OIDC request token and URL, AWS credentials including IMDS and Secrets Manager, GCP and Azure, Kubernetes service account tokens (it queries the API directly), HashiCorp Vault tokens, Stripe and Slack keys, Anthropic, OpenAI, Cursor, Codex, and Gemini configuration, and about 200 file globs (.env*, private keys, SSH keys, Terraform state, Docker configs, KeePass databases, /etc/shadow). On GitHub Actions runners it dumps Runner.Worker process memory to recover injected secrets, and it commits a workflow named "Run Copilot" that writes ${{ toJSON(secrets) }} to an artifact. Exfiltration is RSA-encrypted and lands in public repositories created under the victim's own account (about 1,300 were identified by Aikido on August 5), with npm-cache[.]com as a fallback. Command-and-control domains are resolved at runtime from an Ethereum smart contract (0xE1f2395ee43e45A1556EC6438a88c31B83493103), so blocking a domain does not stop it.

Two properties make this wave different from the earlier ones this project covered (TanStack in May, the AUR wave in June). First, the worm only propagates through npm tokens that have publish rights and bypass_2fa: true; Elastic identifies that token configuration as the necessary condition for the worm's spread from one account to 440 packages. Second, when it holds a GitHub token, it commits to up to 50 branches per repository adding a SessionStart hook to .claude/settings.json (running node .claude/setup.mjs) and a folderOpen task to .vscode/tasks.json (running node .vscode/setup.mjs). Those files are outside the scope of most dependency scanners, and the payload runs the next time someone opens the repo in VS Code or starts a Claude Code session, with no npm install involved. The commits are authored as claude <claude@users.noreply.github.com> with the message chore: update config.

Am I affected?

Check installed trees for the headline versions (this only covers the eleven jaredwray packages; use the StepSecurity feed for the full 444):

npm ls keyv flat-cache file-entry-cache cacheable-request cacheable cache-manager @cacheable/memory @cacheable/node-cache @cacheable/utils @cacheable/net ecto 2>/dev/null | grep -E '(keyv@6\.0\.0|flat-cache@6\.1\.24|file-entry-cache@11\.1\.6|cacheable-request@13\.0\.20|cacheable@2\.5\.1|cache-manager@7\.2\.10|@cacheable/memory@2\.2\.1|@cacheable/node-cache@3\.1\.2|@cacheable/utils@2\.5\.1|@cacheable/net@2\.1\.1|ecto@5\.0\.1)( |$)'

Also check lockfiles, which record what was resolved even if node_modules has since been rebuilt. This is a coarse filter (it will pair a package with a sibling's version); treat a hit as a lead to read:

grep -nE '(keyv|flat-cache|file-entry-cache|cacheable-request|cacheable|cache-manager|ecto)[@"/].{0,40}(6\.0\.0|6\.1\.24|11\.1\.6|13\.0\.20|2\.5\.1|7\.2\.10|5\.0\.1)' package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

Sweep for the dropper and stealer files, the IDE hooks, and the token monitor. The sweeps below start at / and stay on one filesystem; add each separately mounted home or workspace volume as its own starting point. Hash anything you find against the IOC block: a setup.mjs inside node_modules is unusual but not by itself proof, and a legitimate settings.json or tasks.json can reference a file of that name. Read what a hit actually runs.

find / -xdev -type f \( -name 'Math_Symbol.js' -o -name 'math_init.js' -o -name 'setup.mjs' \) -path '*/node_modules/*' 2>/dev/null
find / -xdev -type f \( -path '*/.claude/setup.mjs' -o -path '*/.vscode/setup.mjs' \) 2>/dev/null
find / -xdev -type f \( -name 'settings.json' -path '*/.claude/*' -o -name 'tasks.json' -path '*/.vscode/*' \) -exec grep -l 'setup\.mjs' {} + 2>/dev/null
ls -la ~/.local/bin/gh-token-monitor.sh 2>/dev/null
ls -d ${TMPDIR:-/tmp}/bun-dl-* 2>/dev/null

On macOS also check ~/Library/LaunchAgents for an unfamiliar plist; on Linux check ~/.config/systemd/user. CI runner images and build caches built after August 4 should be rebuilt rather than searched; also clear the npm cache (npm cache clean --force) on any machine that installed during the window. In every repository you own, look for the worm's commits and its secrets-dumping workflow:

git log --all --author='claude@users.noreply.github.com' --oneline
git log --all --grep='chore: update config' --oneline
grep -rlE 'Run Copilot|toJSON\(secrets\)' .github/workflows/ 2>/dev/null

On GitHub, search your account and organizations for repositories whose description is "Shai-Hulud: Here We Go Again"; their presence means your token was used to exfiltrate.

Response

1. Isolate the host first, then rotate from a machine you trust. Disconnect any workstation or runner that shows an IOC from the network (or stop the runner) and preserve a copy of the artifacts and shell history before touching anything. Then perform the credential rotation in the next step from a separate, known-clean machine. That sequence satisfies both readings of the revocation-trap dispute: a disconnected host cannot detect the revocation, and a live credential is not left running while you clean. Only after rotation: delete .claude/setup.mjs and .vscode/setup.mjs, strip the injected hook from .claude/settings.json and the folderOpen task from .vscode/tasks.json, remove ~/.local/bin/gh-token-monitor.sh and any unit or LaunchAgent that references it, and kill any Bun process you did not start. Rebuild rather than clean if the host is a CI runner or held cloud credentials.
2. Rotate, in this order: GitHub tokens (PATs, App installation tokens, OAuth), npm tokens (delete every automation token with bypass_2fa; recreate with 2FA-required or move to trusted publishing), cloud provider keys, Kubernetes service account tokens, Vault tokens, then Stripe, Slack, and AI-provider keys. Treat every .env the machine could read as exposed.
3. Pin and reinstall clean. Add overrides for every affected package you depend on ("overrides": { "keyv": "5.6.0", "flat-cache": "6.1.23", "file-entry-cache": "11.1.5", "cacheable": "2.5.0", "cache-manager": "7.2.9" } plus the prior release of cacheable-request, the scoped @cacheable/* packages, and ecto if present), delete node_modules and the lockfile, regenerate with npm install --ignore-scripts, review the diff, and commit the new lockfile so npm ci resolves consistently. Note that pnpm 11 ships a minimum-release-age guard on by default and npm 11.10+ supports min-release-age in .npmrc; a 7-day cooldown would have skipped every version in this wave.
4. Audit GitHub for what the worm did with your identity. Revert the chore: update config commits on every branch they touched, delete the "Run Copilot" workflow and any artifacts it produced, delete the exfil repositories, and check organization audit logs for token use from unfamiliar IPs.
5. Inventory .claude/ and .vscode/ like code. Add both directories to code review, and treat any hook or task that runs node on a file in the repo as suspect until someone owns it. This is a persistence surface that dependency tooling does not cover.

2. GhostLock (CVE-2026-43499) and RefluXFS (CVE-2026-64600): two local-root kernel bugs, both container escapes

GhostLock was disclosed July 7, 2026 by Nebula Security's VEGA team. It is a use-after-free in the rtmutex priority-inheritance code (remove_waiter() in kernel/locking/rtmutex.c): on the FUTEX_WAIT_REQUEUE_PI rollback path the kernel clears pi_blocked_on on the wrong task, so a waiter returns to userspace with a dangling pointer into its own freed kernel stack frame. It has been present since Linux 2.6.39 (2011) and affects every kernel through 7.1-rc1 with CONFIG_FUTEX_PI=y (the default in mainstream distribution configs) that does not carry the fix or a backport. CVSS is 7.8, which understates it for this audience: Nebula reports its public reproducer gets a stable root shell about 97% of the time in roughly five seconds on the kernels it tested, it needs no capabilities, and the default Docker seccomp profile does not block the futex operations involved, so it escapes containers. There is no runtime mitigation; RANDOMIZE_KSTACK_OFFSET lowers the odds per attempt to about 1 in 64 but an attacker can just retry. The upstream fix (commit 3bfdc63936dd) landed April 20 and was backported to stable May 4, months before public disclosure, and a regression from that fix was corrected June 2 (CVE-2026-53166). So a kernel updated after mid-May is likely fixed; a kernel from before then is not.

RefluXFS was disclosed July 22, 2026 by Qualys TRU (the research credits a collaboration with Anthropic). It is a race in the XFS copy-on-write path introduced in Linux 4.11 (2017): concurrent O_DIRECT writes to a reflinked file hit a window where XFS drops the inode lock while waiting for log space, and a stale block mapping lets an unprivileged local user overwrite the contents of a root-owned file on disk. The default-vulnerable set is everything that ships XFS with reflink=1 as the root filesystem: RHEL 8, 9, 10 and CentOS Stream, Rocky, AlmaLinux, Oracle Linux, Fedora Server 31+, and Amazon Linux 2 and 2023 images. Debian, Ubuntu, and SUSE are affected only where XFS was chosen with reflink enabled. Qualys states SELinux enforcing does not block the path, and that KASLR, SMEP, SMAP, lockdown, seccomp, and container isolation all fail to stop it: there is no configuration to harden around it. Qualys demonstrated a reliable exploit that leaves no kernel log; the upstream fix is commit 2f4acd0 ("xfs: resample the data fork mapping after cycling ILOCK"), merged July 16.

Am I affected?

uname -r
grep CONFIG_FUTEX_PI /boot/config-$(uname -r)
for m in $(findmnt -t xfs -n -o TARGET); do echo "$m $(xfs_info "$m" 2>/dev/null | grep -o 'reflink=[01]')"; done

If CONFIG_FUTEX_PI=y and the running kernel predates the versions above, GhostLock applies. If any XFS mount prints reflink=1, RefluXFS applies. Because vendor backports keep the old version string, check the running kernel's changelog for the CVE IDs rather than comparing version numbers, and confirm the fixed kernel is the one actually booted, not just installed:

rpm -q --changelog kernel-core-$(uname -r) 2>/dev/null | grep -iE '43499|64600'
zgrep -iE '43499|64600' /usr/share/doc/linux-image-$(uname -r)/changelog.Debian.gz 2>/dev/null
rpm -q kernel-core 2>/dev/null; dpkg -l 'linux-image-*' 2>/dev/null | grep '^ii'

Response

1. Update and reboot. Both fixes require the new kernel to be running, not just installed. Prioritize hosts that run code you do not fully trust: shared CI runners, multi-tenant Kubernetes nodes, shared hosting, sandboxes for AI agents, and anything with a public shell or a web app that could yield a low-privilege foothold. Live-patch products (KernelCare, kpatch, Canonical Livepatch) have shipped patches for at least GhostLock; confirm coverage for RefluXFS before relying on it, because Qualys specifically flagged that RefluXFS is not a bug you can "live-patch" around in the general case.
2. Do not rely on container isolation as a stopgap. GhostLock's reproducer escapes a default Docker container without any added capabilities. If you cannot reboot a node yet, treat every workload on it as sharing root until you can.
3. Look for signs of prior use. Neither bug leaves a reliable kernel log entry. What you can check: unexpected setuid binaries, modified root-owned files under /etc or /usr/bin with recent mtimes on XFS hosts, new cron or systemd units, and audit records of unprivileged processes calling futex with FUTEX_WAIT_REQUEUE_PI if you already had auditd rules that granular (most do not).

3. GitLab CVE-2026-19478: unauthenticated modify/delete of public projects, exploited within days (August 17)

GitLab shipped an out-of-cycle patch release on August 17, 2026 (18.11.11, 19.0.8, 19.1.6, 19.2.4) for CVE-2026-19478, a CVSS 9.4 code-injection flaw reached through a GraphQL directive. An unauthenticated attacker can modify or delete public projects and user data; watchTowr's writeup describes deleting entire repositories, forging merge records so a fix appears to have landed when it did not, and banning project maintainers. It affects self-managed CE and EE from 18.2 through the versions before each fix; GitLab.com and GitLab Dedicated were patched before disclosure. watchTowr reproduced the bug within minutes of the advisory from the patch diff alone and reported in-the-wild exploitation against its honeypots roughly two days later. Attacks need only network reach to the GraphQL endpoint, so any self-managed instance that is internet-reachable, or reachable from a compromised workstation, should be assumed probed.

Am I affected?

sudo gitlab-rake gitlab:env:info 2>/dev/null | grep -A2 'GitLab information'
head -1 /opt/gitlab/version-manifest.txt
curl -s -H "PRIVATE-TOKEN: $GITLAB_TOKEN" https://gitlab.example.com/api/v4/version

The first two are Omnibus paths; the API call works for Helm, Docker, and source installs (any token with read_api). Any 18.2 through 18.11.10, 19.0.0 through 19.0.7, 19.1.0 through 19.1.5, or 19.2.0 through 19.2.3 is vulnerable.

Response

1. Upgrade to the fixed version for your line. There is no workaround published. If you cannot patch immediately, put the instance behind authentication at the reverse proxy or restrict /api/graphql to trusted networks as a temporary measure; that does not protect against an attacker already inside your network.
2. Audit after patching. Because the impact is integrity, not just confidentiality, check that public projects still exist and have their expected default branches, review the audit events log for project deletions, member bans, merge request state changes, protected-branch and CI configuration edits, new access tokens, and runner registrations since August 17, and compare recent merge records against CI history for anything that "merged" without a pipeline. Restore from backup where a project was deleted.

4. Metabase CVE-2026-72898: unauthenticated SQL injection to admin, found because Metabase Cloud was attacked (August 6)

Metabase's August 6, 2026 security update says the company discovered the bug when someone used it against Metabase Cloud as a zero-day. The flaw is an unauthenticated SQL injection through POST /api/session/reset_password; a successful attempt yields an administrator session on the Metabase instance and, from there, every connected data warehouse. It carries CVSS 10.0 and CISA added it to KEV on August 11. Wiz observed follow-on exploitation against self-hosted instances, and The Hacker News' coverage names Framework, n8n, and Kilo Code as confirmed victims. Affected: every self-hosted release from x.58 onward; fixed in x.58.24, x.59.21, x.60.17, x.61.11, x.62.9, and x.63.5. Metabase Cloud was patched before disclosure.

Am I affected?

curl -s http://localhost:3000/api/session/properties | grep -o '"tag":"[^"]*"'
grep -E 'POST /api/session/reset_password|GET /api/user/current' /path/to/metabase.log | grep -A1 'POST /api/session/reset_password.* 400' | grep -B1 'GET /api/user/current.* 200'

Metabase's own detection indicator is a reset_password POST returning 400 immediately followed by GET /api/user/current returning 200 from the same client. The second command filters the log to those two endpoints and prints 400/200 pairs that are adjacent in that filtered stream; confirm the client IP matches on each pair before treating it as a hit. The first line prints the running version tag from the unauthenticated properties endpoint. Preserve the application and reverse-proxy logs before you upgrade.

Response

1. Upgrade to the fixed point release for your branch, then revoke every session (Metabase's advisory says to delete the rows in the core_session table; back up the application database first), delete any API key you do not recognize, and review the administrator list for accounts or changes you did not make.
2. Rotate the credentials of every connected database. Metabase recommends this explicitly. An attacker with admin on Metabase can read the warehouse connection details and has had arbitrary query access to the data behind them; treat the warehouse as exposed, not just the BI layer.
3. Keep Metabase off the public internet. The vulnerable endpoint is pre-auth by design (it is the password reset path). A VPN or identity-aware proxy in front of it would have removed the pre-auth exposure, though not the risk from a compromised identity inside that boundary.

5. VMware vCenter CVE-2026-59310: syslog path traversal to RCE, exploited five days after the advisory (July 29)

Broadcom published VMSA-2026-0006 on July 29, 2026 for CVE-2026-59310, a directory traversal in the vCenter syslog server component rated CVSS 9.8: "a malicious actor with network access to vCenter may exploit this issue to execute arbitrary code." Affected: vCenter 7.0, 8.0, 9.0.x, 9.1.x, and the VCF and vSphere Foundation bundles that carry them. Fixed in 9.1.0.0300, 9.0.2.0100, and 8.0 U2f / U3k; 7.0 customers are told to contact Broadcom support. No workaround. German incident-response firm QUIRSO reported compromised systems calling out to attacker infrastructure from August 3, with 361 unique victim IPs across 47 countries and persistence via a cron job that runs the open-source reverse_ssh tool. CISA added the CVE to KEV on August 18. Broadcom's advisory FAQ said no exploitation was known at publication and was revised August 3 and August 19.

Am I affected and was I hit?

vpxd -v
ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /var/spool/cron/ 2>/dev/null
crontab -l 2>/dev/null; cat /etc/cron.d/* 2>/dev/null
find / -xdev -type f -iname '*reverse_ssh*' 2>/dev/null
ss -tnp state established '( dport = :22 )'

Run these on the vCenter appliance shell. The last command lists established outbound connections to port 22, which a vCenter appliance normally has none of. QUIRSO's public report does not include the cron line text, file paths, hashes, or the callback addresses, so there is no exact string to grep for; the indicator is an unexpected cron entry that runs something you did not install, plus an outbound SSH session. QUIRSO notes reverse_ssh is a legitimate tool and its presence alone is not proof, but on a vCenter appliance where you did not install it, combined with the above, it is a high-priority indicator.

Response

1. Patch to the fixed build for your line, and if you are on 7.0, open the Broadcom support case immediately rather than waiting. If the vCenter management interface is reachable from anywhere but an administrative network, fix that in the same change.
2. If you find the cron job or reverse_ssh, treat vCenter as fully compromised. Isolate the appliance from the network, snapshot it for evidence, and rebuild from a clean image rather than removing the cron line. vCenter holds credentials for every ESXi host it manages, so rotation has to cover vCenter SSO administrators, ESXi root and service accounts, the vpxuser accounts, machine and solution certificates, and every integration that authenticates to vCenter (backup, monitoring, automation, Kubernetes and cloud connectors).

6. The other package compromises: AsyncAPI (July 14), Jscrambler (July 11), and Hades on PyPI (June 8, before this window but not previously covered)

AsyncAPI matters because of the technique. On July 14, 2026 an attacker opened a pull request against an @asyncapi repository whose workflow used pull_request_target, ran code in the base repo's context, captured the asyncapi-bot personal access token, pushed to release branches, and let the project's own OIDC trusted-publishing workflow ship five trojanized versions to npm within ninety minutes, each with valid provenance attestations. Microsoft Threat Intelligence's July 15 analysis describes the payload ("miasma-train-p1," a build of the Miasma RAT with credential harvesting and propagation compiled out) as executing at require() time rather than through a lifecycle script, so npm install --ignore-scripts did not prevent it. It spawns a detached Node child, pulls an 8.2 MB encrypted bundle over IPFS, and drops a persistent sync.js under a NodeJS directory in the user profile. Affected versions: @asyncapi/specs@6.11.2 and 6.11.2-alpha.1, @asyncapi/generator@3.3.1, @asyncapi/generator-components@0.7.1, @asyncapi/generator-helpers@1.1.1. All five were removed; @asyncapi/specs latest is 6.11.1 as of August 28. C2 was 85.137.53[.]71 on ports 8080, 8081, and 8091.

Jscrambler was a stolen-credential publish on July 11: jscrambler 8.14.0, 8.16.0, 8.17.0, 8.18.0, and 8.20.0 plus jscrambler-webpack-plugin@8.6.2, gulp-jscrambler@8.6.2, grunt-jscrambler@8.5.2, and jscrambler-metro-plugin@9.0.2 carried a preinstall hook dropping a Rust infostealer for Linux, macOS, and Windows that targets cloud credentials, wallets, and AI coding-assistant credential stores. Socket flagged it six minutes after publish; the vendor reports 1,479 downloads before removal. Clean versions: jscrambler@8.22.0, plugins 8.6.3 / 8.6.3 / 8.5.3 / 9.0.3.

Hades is the PyPI branch of the same Mini Shai-Hulud lineage, reported by Socket in early June with a second wave June 8: 19 to 29 packages (counts differ by vendor) aimed at bioinformatics, graph ML, and MCP-themed libraries. Its trick is a *-setup.pth file in site-packages, which Python executes at interpreter startup, before any import, to fetch Bun and run the stealer. It predates this bulletin's window and was not covered in the June 23 bulletin, so it is included here; the .pth check below is cheap.

Am I affected?

npm ls @asyncapi/specs @asyncapi/generator @asyncapi/generator-components @asyncapi/generator-helpers jscrambler jscrambler-webpack-plugin gulp-jscrambler grunt-jscrambler jscrambler-metro-plugin 2>/dev/null | grep -E '(@asyncapi/specs@6\.11\.2(-alpha\.1)?|@asyncapi/generator@3\.3\.1|@asyncapi/generator-components@0\.7\.1|@asyncapi/generator-helpers@1\.1\.1|jscrambler@8\.(14|16|17|18|20)\.0|jscrambler-webpack-plugin@8\.6\.2|gulp-jscrambler@8\.6\.2|grunt-jscrambler@8\.5\.2|jscrambler-metro-plugin@9\.0\.2)( |$)'
ls -la ~/.local/share/NodeJS/sync.js "$HOME/Library/Application Support/NodeJS/sync.js" 2>/dev/null
find / -xdev -path '*site-packages*' -name '*.pth' -exec grep -lE 'import (os|subprocess|urllib)|exec\(' {} + 2>/dev/null

On Windows, check %LOCALAPPDATA%\NodeJS\sync.js. A .pth file that contains an import line is normal for a few packages (setuptools' editable installs, for one); read what it does before deleting it.

Response

1. For any hit, follow the keyv playbook: remove the artifact, rebuild the environment, rotate what the machine could read. For AsyncAPI, also block the 85.137.53[.]71 ports at egress and remove the sync.js persistence.
2. Fix the AsyncAPI class of bug in your own repos. Grep your workflows for pull_request_target and make sure none of them check out or execute PR-controlled code with a secret in scope. This is the second incident in this bulletin alone where a trusted-publishing pipeline shipped malware with valid provenance (CHAINDROP also published through OIDC); provenance proves the pipeline ran, not that the pipeline was yours.

7. OpenSSH 10.4 (July 6) and where libssh2 stands

OpenSSH 10.4 shipped July 6, 2026 with seven security fixes. The one that earned a CVE and a 7.7 score is CVE-2026-60002, a use-after-free in the ssh client when a server changes its host key during key re-exchange, reported by Zhenpeng Lin; a malicious or machine-in-the-middle server can corrupt memory in the connecting client, with code execution as the assessed worst case. It is client-only; sshd is not affected. The rest: sftp could be tricked by a malicious server into writing a downloaded file to an unexpected path; scp remote-to-remote copies could be steered to write into the parent directory; sshd's internal-sftp silently truncated command lines after the ninth argument, dropping security options; DisableForwarding=yes did not override PermitTunnel=yes; a pre-auth denial of service in sshd when GSSAPIAuthentication is enabled; and the minimum authentication delay was not being enforced, weakening brute-force resistance. Ubuntu's USN-8533-1 rolled these into 22.04, 24.04, and 26.04.

This is the same threat model as the June 23 libssh2 bulletin: the danger is your automation connecting out to a host an attacker controls or can interpose on. The two together mean the two most widely deployed SSH client implementations each had a memory-safety bug on the server-controlled path in June and July 2026. libssh2 status update: as of August 28 there is still no tagged release after 1.11.1 (this bulletin checked the project's tag list); the fixes remain commits 97acf3df and 17626857 on master, and distributions have been backporting. Several aggregators reported a public proof-of-concept for CVE-2026-55200 around June 27; this bulletin could not locate a primary researcher publication for it and treats PoC availability as reported-but-unverified.

Am I affected?

ssh -V
sshd -T 2>/dev/null | grep -iE 'gssapiauthentication|permittunnel|disableforwarding'
curl --version | tr ' ' '\n' | grep -i ssh2

Response

1. Update OpenSSH everywhere a client runs, which is everywhere: developer workstations, CI runners, bastions, and anything that scripts scp or sftp. On distributions, the backport carries the fix without the 10.4 version string, so check the package changelog rather than ssh -V alone.
2. Enforce strict host-key checking in automation. StrictHostKeyChecking=accept-new at minimum; pinned known_hosts or SSH certificates where you can. CVE-2026-60002 requires the server to present a changed key mid-session, which a properly pinned client will already refuse.
3. Re-run the libssh2 inventory from the June 23 bulletin if you have not, and confirm your distro's backported build is installed; do not wait for the upstream tag.

8. Langflow CVE-2026-55255: authenticated IDOR, exploited, on CISA KEV (July 7)

Langflow, the open-source visual builder for LLM agents and workflows, has an insecure direct object reference in /api/v1/responses: an authenticated user can execute any other user's flow by supplying its ID, and read whatever that flow returns. The vendor rates it CVSS 9.9. The fix (PR #12832) merged April 22 and shipped in 1.9.1; the GitHub advisory (GHSA-qrpv-q767-xqq2) lists all versions before 1.9.2 as affected, so land on 1.9.2 or later. Sysdig's threat research team observed the first in-the-wild exploitation on June 25 and describes the attackers' goal as credential harvesting from flows that embed API keys and database connections. CISA added it to KEV on July 7 with a July 10 federal deadline. It is "authenticated," but Langflow instances are routinely deployed with shared or self-service accounts, and the earlier 2025 Langflow RCE showed how many are internet-exposed.

Am I affected?

pip show langflow 2>/dev/null | grep -i version
docker ps --format '{{.Image}}' | grep -i langflow
curl -s http://localhost:7860/api/v1/version

Response

1. Upgrade to 1.9.2 or later and, if the instance was reachable by any account you do not personally control, rotate every secret referenced by any flow: LLM provider keys, vector database credentials, tool API keys.
2. Put Langflow behind real authentication. An identity-aware proxy or VPN in front of it turns an authenticated IDOR into an internal-only problem.

9. Node.js July 29 security release: three High CVEs, one incomplete June fix

The Node.js project shipped 22.23.2, 24.18.1, and 26.5.1 on July 29, 2026 with eleven CVEs. The three rated High: CVE-2026-56846, HTTP/2 retained headers bypass maxSessionMemory (22.x and 24.x); CVE-2026-56848, an HTTP/2 re-entrant send causing a heap use-after-free (all three lines); and CVE-2026-58043, Permission Model path matching that over-grants filesystem access under --permission. Of the Mediums, CVE-2026-58040 is worth a specific note: it revisits June's HTTPS Agent session-reuse hostname-verification bug (CVE-2026-48934), meaning the June patch did not fully close it, and CVE-2026-56850 lets an HTTPS Agent reuse an mTLS identity across different PFX certificates. Also fixed: a request-smuggling primitive via header truncation in the HTTP parser (Low), a node:sqlite iterator replay, a dns.resolveAny() abort on large responses, and a node:zlib crash. The release bumped undici and llhttp. The HTTP/2 pair is the urgent part for anything internet-facing, given how this project's June 3 HTTP/2 Bomb bulletin played out.

Am I affected?

node -v
node -e "console.log(process.versions.llhttp, process.versions.undici)"

Response

1. Move to 22.23.2, 24.18.1, or 26.5.1, prioritizing HTTP/2 servers exposed to the internet and any service that relies on --permission as a security boundary. Node 18 and 20 are past end-of-life and did not get these fixes; anything still on them needs a migration plan, not a patch.

10. RubyGems: a nine-year cache bug served legacy API keys to strangers (disclosed July 23)

RubyGems' July 23, 2026 advisory (the blog post is dated July 22 in its URL) describes a bug present since October 2016: responses from GET /api/v1/api_key, the legacy endpoint that returned a user's API key after HTTP Basic authentication, were cached at the Fastly edge for up to an hour without Cache-Control: private and without Vary: Authorization. A gzip-accepting request from anyone could receive the previous authenticated user's key from the shared cache slot. RubyGems found it July 6, fixed the headers July 9, purged the CDN, retired the endpoint, and revoked every legacy API key. Scoped keys created through the website or through RubyGems 3.2.0+ (December 2020 onward) were never exposed. Their log review found no sign of malicious use of a leaked key, with the caveat that CDN cache hits do not reach origin logs.

Response

1. If you publish gems, regenerate your key at rubygems.org/profile/api_keys, update ~/.gem/credentials and every CI secret that publishes, and enable MFA for API requests. A legacy key in CI is already dead, so your next release pipeline will fail until you do this anyway.
2. Review your gems for versions, yanks, owners, or webhooks you did not create, since that is what an attacker with a leaked key would have done.

11. Edge and management appliances that landed on CISA KEV

None of these got a standalone bulletin, and none fits this audience as squarely as the items above, but each is confirmed exploited and each has an operator who needs to hear it. Cisco Secure Firewall Management Center, CVE-2026-20316: hardcoded credentials for a low-privilege account in the FMC web interface, CVSS 5.3 but Cisco assigned a High security impact rating because it chains with other FMC bugs; Cisco PSIRT saw exploitation in July and CISA listed it July 29. Cisco ASA and FTD, CVE-2026-20349: crafted HTTP to the Remote Access SSL VPN service reloads the firewall, CVSS 8.6, unauthenticated, exploited in the wild per Cisco's August 11 advisory (cisco-sa-asaftd-vpn-dos-dzv4mQFF), no workaround, fixes in hot fixes for FTD 7.0 through 10.0. SonicWall SMA1000, CVE-2026-15409 and CVE-2026-15410 (KEV July 14). Fortinet FortiOS CVE-2025-68686 and Arista VeloCloud Orchestrator CVE-2026-16812 (KEV July 27). N-able N-central authentication bypass CVE-2026-18577 (KEV August 3), which matters to anyone whose MSP manages their fleet with it. TrueConf Server CVE-2026-72529 and CVE-2026-72530 (KEV August 20). If you operate any of these, the vendor advisory and the KEV due date are the action; the only general point is that the edge-appliance pre-auth pattern this project has tracked since PAN-OS in April has not slowed.

12. Developer-tool and workstation items, briefly

Windows afd.sys, CVE-2026-68820: August Patch Tuesday (August 11) fixed a use-after-free in the Ancillary Function Driver for WinSock that gives a local attacker SYSTEM. Check Point attributes in-the-wild use to a North Korean actor deploying a kernel rootkit in a new Operation Dream Job wave, which targets developers specifically. It is a post-foothold escalation, so the action is the ordinary one: install the August cumulative update on developer Windows machines. The same release fixed 421 CVEs including a publicly disclosed User Profile Service link-resolution bug (CVE-2026-62832).

Cursor "DuneSlide," CVE-2026-50548 and CVE-2026-50549: Cato AI Labs disclosed on July 1 two zero-click prompt-injection paths out of Cursor's terminal sandbox, one via the working_directory parameter of run_terminal_cmd (which can be steered to ~/.zshrc or the sandbox binary itself) and one via symlink-resolution fallback. Both CVSS 9.8, both fixed in Cursor 3.0, released April 2. Check with cursor --version; anything below 3.0 should be updated before it reads another MCP response or web page.

FakeGit and "agentbaiting": researchers mapped about 7,600 malicious GitHub repositories from roughly 6,600 profiles, about 800 of them posing as AI Skills or MCP servers (Gmail, WhatsApp, Databricks, Jenkins, Docker integrations), delivering SmartLoader and then the StealC infostealer, with more than 14 million release-asset downloads across the campaign. The repos are built to be found and recommended by AI coding agents; in testing, Claude Code, Gemini, and ChatGPT surfaced them unprompted when asked for an MCP server. The operator rule: an MCP server or skill your agent "found" gets the same review as a dependency, and release binaries from a repo with no history get none of your credentials.

Claude Code CVE-2026-46406: the /copy command wrote responses to a fixed, world-readable /tmp/claude/response.md, so on a shared host any local user could read what a developer copied. Fixed in 2.1.128 (June 29). Only matters on multi-user machines; update and delete the file. GitHub Copilot "CoSnitch," CVE-2026-24301: a one-click data exfiltration chain through Copilot Personal's URL fetching and memory, patched server-side August 18; no user action. Microsoft Entra ID CVE-2026-69836: a CVSS 10.0 deserialization RCE that Microsoft found internally and fixed server-side on August 20; the bulletin briefly said "Exploited: Yes" and was corrected to "No" the next day. Nothing for tenants to patch, included here because the headline circulated widely.

The broader pattern

Three things repeat across this window. The first is that, as of this window, the AI coding toolchain is a persistence and delivery surface in its own right: CHAINDROP writes hooks into .claude/settings.json and .vscode/tasks.json, Jscrambler and CHAINDROP both harvest Claude, Cursor, Codex, and Gemini credentials, FakeGit builds repositories for agents to recommend, and DuneSlide turns a poisoned MCP response into a shell. The controls that matter are old ones applied to new files: review agent configuration like code, scope agent credentials narrowly, and do not let an agent install what it discovers.

The second is that the defenses adopted after the spring compromises are being routed around. --ignore-scripts stopped lifecycle hooks, so AsyncAPI's payload runs at import. Trusted publishing proves the pipeline ran, so attackers compromise the pipeline (a pull_request_target workflow) and let it sign the malware. Hades runs from a .pth before any import happens. A minimum release age (pnpm 11 default, npm 11.10+ min-release-age; uv's exclude-newer on the Python side) is the one control that would have skipped every npm version named in this bulletin for anyone installing during the takedown window, because each was pulled within hours to days.

The third is the n-day window. GitLab was exploited about two days after its advisory; vCenter, five; Metabase was a zero-day against the vendor's own cloud before it was a CVE. "Patch within 30 days" is not a policy that survives contact with 2026, at least for anything with a pre-auth surface reachable from the internet.