Last updated: July 5, 2026 at 9:01 AM UTC
All 557 Vulnerability 199 Breach 106 Threat 245 Defense 7
Tag: supply-chain (85 articles)Clear

A WordPress redirect plugin used on 70,000 sites was secretly running a hidden update channel that fetched code from an attacker-controlled server for five years

A WordPress security researcher found a backdoor that's been quietly running on 70,000 websites for five years. The Quick Page/Post Redirect plugin had a hidden self-updater added in 2020 that pointed not to WordPress.org but to anadnet[.]com, an attacker-controlled domain. In March 2021 that updater silently delivered a tampered version of the plugin - replacing the real plugin with one that included a passive backdoor. The backdoor only triggers for visitors who aren't logged in (so site owners never see it firing) and was used to inject SEO spam into pages served to Google's crawler. WordPress.org pulled the plugin pending review.

Check
If you run any WordPress site, list your installed plugins today and remove Quick Page/Post Redirect immediately - the directory pulled it but installs already on disk are still active.
Affected
Any WordPress site running Quick Page/Post Redirect plugin - 70,000 confirmed installs. Sites running versions 5.2.1 and 5.2.2 received the tampered build directly from anadnet[.]com. The pattern of buying a legitimate plugin business and quietly adding malicious code is increasingly common.
Fix
Uninstall and delete Quick Page/Post Redirect from every WordPress site you manage. Search wp-content/plugins/ on disk - removing via the dashboard alone may not catch every install. Block anadnet[.]com and w.anadnet[.]com at your DNS resolver. Audit your sites for SEO spam visible only to crawlers (compare 'fetch as Googlebot' against what regular visitors see).

Critical GitHub flaw lets a single 'git push' run code remotely on the server - patched, but most self-hosted GitHub Enterprise instances haven't updated yet (CVE-2026-3854)

Researchers disclosed CVE-2026-3854, a critical GitHub Enterprise Server flaw that lets anyone with push access execute arbitrary commands on the GitHub server with a single git push. The bug is in how Enterprise Server handles repository hooks during push operations - a crafted commit message or filename bypasses the sanitization that normally prevents shell injection. GitHub patched it last week, but self-hosted instances need to apply the patch manually, and telemetry shows most haven't yet. Anyone with developer-level access to a vulnerable Enterprise Server can take over the entire instance, then pivot into every repository and CI/CD secret it hosts.

Check
If you run a self-hosted GitHub Enterprise Server, apply the latest patch this week and review push activity from any low-privilege accounts since the patch was released.
Affected
Self-hosted GitHub Enterprise Server instances on versions before the April 2026 patch. The bug requires push access to any repository, which means every developer with commit rights is a potential entry point. CI/CD secrets, signing keys, and source code are exposed. GitHub.com (the SaaS product) is not affected.
Fix
Upgrade GitHub Enterprise Server to the patched release per GitHub's advisory. Until patched, restrict push access to trusted accounts and require code review on all pushes. Audit Enterprise Server logs for unusual git operations or shell processes spawning from the GitHub system user. Rotate any CI/CD secrets, signing keys, and webhook tokens stored on the server.

Vimeo confirms user data was exposed via breach at analytics provider Anodot

Vimeo confirmed yesterday that user data was exposed when its analytics provider Anodot was breached. The video service hasn't said how many users are affected or what data was exposed beyond 'limited' account information, but Anodot's role suggests the leaked records include event-level user activity tied to Vimeo accounts: video views, account IDs, and the kind of telemetry analytics providers ingest. The pattern is the same as Citizens Bank, Frost Bank, Pitney Bowes, and now Vimeo: customer data leaks through a third-party vendor that the customer never directly signed up with.

Check
If you use Vimeo for any work-related video hosting, watch for Vimeo-themed phishing emails over the next few weeks referencing real account activity.
Affected
Vimeo users whose account data was processed by Anodot - a substantial subset given Anodot is a primary analytics provider. The risk is targeted phishing rather than account takeover: scammers who can reference real video views or account creation dates sound legitimate enough to bait credential resets. Organizations hosting marketing or training videos on Vimeo should expect staff targeting.
Fix
Treat any Vimeo email referencing your real account activity as potentially hostile - go to vimeo.com directly. Enable two-factor auth on Vimeo accounts, especially shared organizational ones. Review access logs for unfamiliar logins since April. For organizations: pull your vendor inventory and identify other analytics providers (Mixpanel, Heap, Amplitude) that hold customer data, and confirm breach notification SLAs.

Attackers planted 73 fake VS Code extensions on Open VSX as 'sleepers' that pretended to be popular tools, then quietly turned malicious

Socket reported 73 newly identified malicious extensions on Open VSX, the marketplace used by VS Code, Cursor, and Windsurf editors. The extensions impersonate popular developer tools - same name, same icon, but published by newly-created GitHub accounts with empty repositories. Instead of being malicious from day one, they sit harmlessly for weeks gathering downloads and trust, then push a 'normal' update that silently installs malware. Six of the 73 extensions have already activated; the rest are still in the sleeper phase. The campaign is part of GlassWorm, an ongoing supply-chain attack family that has been working its way through npm, GitHub, and editor extension marketplaces since 2025.

Check
Check every developer machine and CI runner for editor extensions, verify each publisher matches the official one, and remove anything you can't account for.
Affected
Developers using VS Code, Cursor, Windsurf, or other Open VSX-compatible editors who installed extensions in the past two months. Particularly risky if your team installs popular extensions by name without checking publisher namespace, or auto-updates extensions without review. Sleeper extensions look identical to legitimate ones, so visual checks alone are insufficient.
Fix
List installed extensions in each editor and cross-check the publisher against the legitimate one (microsoft.* for Microsoft tools, the original project's GitHub for others). Remove any with newly-created publishers or mismatched namespaces. Disable auto-update on extensions in higher-risk environments. Allowlist approved extensions in managed dev environments. Socket's GlassWorm v2 page tracks the 73 by name.

Checkmarx confirms its source code, employee database, and cloud credentials were posted on the dark web after the March supply-chain attack

Checkmarx confirmed Friday that data from its private GitHub repository was posted on the dark web following the March 23 TeamPCP supply-chain attack. The LAPSUS$ group published the dump, which includes Checkmarx source code, an employee database, API keys, and MongoDB and MySQL credentials. Checkmarx says the affected GitHub repository was separate from the customer Checkmarx One SaaS production environment, with no customer data stored in it. The bigger picture: an attack that started by poisoning a single GitHub Action 35 days ago has now produced a full source code, credentials, and employee data leak - under five weeks end to end.

Check
If your team uses Checkmarx KICS or AST GitHub Actions, the Checkmarx Open VSX extensions, or any Checkmarx self-hosted product, rotate every credential issued during March.
Affected
Organizations using Checkmarx KICS or AST GitHub Action versions pulled between 12:58 and 16:50 UTC on March 23. Checkmarx Open VSX extensions ast-results 2.53.0 and cx-dev-assist 1.7.0. Any environment where Checkmarx-issued API keys reach cloud accounts, repos, or CI/CD secret stores - those credentials may be in the leak.
Fix
Rotate every credential, API key, and integration token that touched Checkmarx tooling in March. Audit GitHub Actions logs for outbound traffic to checkmarx[.]zone or audit.checkmarx.cx. Pin GitHub Actions to immutable commit SHAs rather than version tags. Treat any Checkmarx-issued auth token from March as burned and reissue. Watch for follow-up phishing referencing real Checkmarx employees.

'Shai-Hulud: The Third Coming' worm pivots from Checkmarx KICS compromise into Bitwarden CLI, stealing SSH keys, cloud secrets, and MCP configs for AI coding tools

TeamPCP's self-propagating supply-chain worm is back in its third iteration, branded 'Shai-Hulud: The Third Coming' in hard-coded strings across the malware. On April 22, Socket reported Checkmarx's official KICS Docker images and a KICS VS Code / Open VSX extension had been trojanized. Bitwarden's own clients repo runs a Checkmarx scan on every pull request via a pull_request_target workflow that holds id-token: write and fetches credentials from Azure Key Vault, so when the poisoned scanner executed it harvested GitHub OIDC and Azure tokens. At 17:57 ET the same day, attackers used those tokens to push a modified publish-cli.yml to the Bitwarden repo and publish a malicious @bitwarden/cli version 2026.4.0 to npm. The package remained live for 93 minutes until Bitwarden pulled it at 19:30 ET. The payload: a 10MB obfuscated credential harvester that grabs SSH keys, cloud provider credentials, npm publish tokens, GitHub tokens, and - new in this variant - MCP (Model Context Protocol) configuration files used by Claude Code, Cursor, and similar AI coding tools. It then self-propagates by republishing into every npm package the victim can modify and uploads encrypted stolen secrets to public GitHub repositories under Dune-themed names. The worm has a Russian-locale kill switch (exits if LC_ALL/LANG starts with 'ru').

Check
Immediately check every CI/CD runner, developer laptop, and container that pulled Checkmarx KICS Docker images, the KICS GitHub Action, or @bitwarden/cli between March 23 and April 23, and rotate every credential that was ever present on those machines.
Affected
Confirmed malicious artifacts per Socket: @bitwarden/cli 2026.4.0 on npm (live 21:57 to 23:30 UTC on April 22, a 93 minute window); compromised Checkmarx KICS Docker images and GitHub Actions (first compromised March 23, re-compromised April 22); two Checkmarx-published Visual Studio Code and Open VSX extensions. Any npm package subsequently republished by a victim whose npm token this worm captured is also potentially malicious.
Fix
Remove the listed versions from all developer environments, CI runners, and private mirrors. Rotate every credential the worm would have seen: GitHub PATs and OIDC tokens, npm publish tokens, cloud provider keys (AWS/GCP/Azure), SSH keys, Azure Key Vault secrets, container registry creds, and MCP config files for AI coding tools - assume every credential stored in ~/.config, ~/.ssh, or exported to CI env is burned. Audit bitwarden/clients commit history for changes to publish-cli.yml and similar pipeline files around April 22. Search public GitHub for repositories named after Dune terms (beautifulcastle-* pattern) to find whether your stolen data has been published. Tighten pull_request_target triggers on security scanners - they should not have id-token: write permission.

Vercel expands Context.ai breach scope - additional accounts compromised, and some predate the April incident entirely

Vercel updated its security bulletin on April 23 to disclose that ongoing forensics has uncovered additional customer accounts compromised in the Context.ai-linked breach that went public on April 19, and - more worryingly - a separate cluster of customer accounts with evidence of compromise that predates and appears unconnected to the Context.ai incident. CEO Guillermo Rauch confirmed on X that the threat actor has been active beyond Context.ai's compromise. Hudson Rock's forensic report traced patient-zero to a Context.ai employee whose laptop was infected by Lumma Stealer in February 2026 after downloading Roblox auto-farm scripts - a roughly four-week dwell time before the operator pivoted into Context.ai's AWS environment and then through OAuth tokens into Vercel's Google Workspace. The stolen credential set from that single laptop included Google Workspace logins, Supabase keys, Datadog tokens, Authkit credentials, and the support@context.ai account. Vercel has now confirmed non-sensitive environment variables in affected team scopes were readable to the attacker, and says customer notifications are going out individually rather than via a public list.

Check
If you run any service on Vercel, re-check your team's incident email for new direct notifications, and proactively rotate any environment variable not marked as 'sensitive' that was stored in Vercel during February to April 2026.
Affected
Vercel customer teams where a member authorized Context.ai's AI Office Suite OAuth integration against a Vercel enterprise Google Workspace account, and any Vercel team with environment variables not explicitly marked as 'sensitive' stored during the February to April 2026 window. The newly-surfaced predate-April account cluster is separate and Vercel has not publicly scoped it - if you receive a notification email, treat it as a distinct compromise and not simply a continuation of the Context.ai incident.
Fix
Rotate every environment variable stored in Vercel that was not marked as 'sensitive' - in practice, treat every database URL, API key, signing secret, and third-party credential as public and rotate it in place. Audit Google Workspace OAuth app grants and revoke any Context.ai 'AI Office Suite' integration. Review Vercel activity logs back to February 2026 for unexpected access to environment variable dashboards. Rotate Supabase, Datadog, and Authkit credentials if any Context.ai employee or integration ever had access to yours. Set a standing policy that no OAuth grant from an external AI tool gets 'Allow All' Workspace permissions.

Citizens Bank and Frost Bank breached via third-party vendor - Everest ransomware claims 3.4M and 250K records, deadline expires today

The Everest ransomware group listed Citizens Financial Group and Frost Bank on its leak site on April 20 with a six-day deadline that expires today. Everest claims 3.4 million Citizens records (names, addresses, account numbers) and 250,000 Frost records with the more sensitive set: SSNs, tax IDs, mortgage rates, and income data. Both banks confirmed the breach traces to a third-party vendor - a statement-printing provider for Citizens, a tax-document fulfillment firm for Frost - rather than direct compromise. Citizens disclosed publicly April 21; class-action lawsuits were filed April 23.

Check
If you bank with Citizens or Frost, monitor accounts and credit reports closely, and treat any inbound communication referencing real account or mortgage details as hostile.
Affected
Citizens Financial Group customers (3.4M records claimed; addresses, names, account numbers in samples) and Frost Bank customers (~250K records; samples include SSNs, tax IDs, mortgage rates - high identity-theft risk). Any organization that shares customer PII with statement-printing, tax-document, or marketing-mail vendors faces equivalent third-party exposure.
Fix
Affected consumers: place a credit freeze, enable 2FA on banking apps, and watch for tax and mortgage fraud since the leak window straddles US filing deadlines. Organizations: pull your vendor PII inventory, identify which downstream printers and tax processors hold equivalent record types, and renegotiate contracts to mandate at-rest encryption and breach notification SLAs.

Vercel breach root cause revealed: Lumma Stealer on a Context.ai employee's laptop, delivered via Roblox auto-farm scripts

Follow-up: this is the origin-story update to the Vercel breach disclosed April 19 (which our publication did not cover at the time). Hudson Rock traced the initial compromise to a Context.ai employee whose laptop was infected by Lumma Stealer malware in February 2026 after the user downloaded Roblox 'auto-farm' scripts and game-exploit executors - a notorious delivery vector for infostealers. The malware harvested that employee's Google Workspace credentials plus access keys and logins for Supabase, Datadog, and Authkit. The haul also included the support@context.ai account, letting the attacker escalate inside Context.ai, reach its AWS environment, and then pivot through compromised Google Workspace OAuth tokens into a Vercel employee's enterprise workspace that had granted the 'AI Office Suite' app 'Allow All' permissions. The attacker (ShinyHunters, now selling the data for $2M on BreachForums) read Vercel environment variables not flagged as 'sensitive.' Google pulled the Context.ai Chrome extension (ID omddlmnhcofjbnbflmjginpjjblphbgk) on March 27 - it embedded an OAuth grant for read access to users' entire Google Drive. The lesson is brutal: one employee's personal risky behavior on a work device cascaded through four SaaS platforms into a supply-chain breach that a threat actor is now auctioning.

Check
If any employee at your company has ever signed into Context.ai with a corporate Google Workspace account, treat that account as compromised and begin full credential rotation and OAuth review immediately.
Affected
Any Google Workspace tenant where an employee granted the Context.ai 'AI Office Suite' OAuth app broad permissions (specifically OAuth app IDs 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com and 110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq.apps.googleusercontent.com). Any Vercel customer whose environment variables were not explicitly marked 'sensitive'. Any organisation whose employees also install uncurated browser extensions or run game cheats on corporate devices (a pattern that keeps reappearing in infostealer cases).
Fix
In Google Workspace admin, search the OAuth app inventory for the two Context.ai client IDs above and revoke them from every user. On Vercel, audit and rotate every environment variable not marked 'sensitive' across every project, and going forward default-enable sensitive flags on new environment variables. Rotate Supabase, Datadog, and Authkit tokens that were ever accessible from a Context.ai-linked Google account. Pull 60 days of audit logs for each affected SaaS and look for impossible-travel sign-ins, new OAuth grants, and unexpected API-key creation. Block game-cheat and executor download domains at the corporate DNS layer and communicate the Roblox-script risk directly to staff.

Self-propagating npm worm hits Namastex Labs packages, steals secrets across npm, PyPI, and crypto wallets

A new supply-chain worm is loose on npm, stealing developer credentials and republishing itself automatically from whichever compromised account it lands on. Socket and StepSecurity identified the attack in packages published by Namastex Labs, a company that builds agentic AI tooling, with 16 package versions confirmed malicious so far and the first poisoned release (pgserve 1.1.11 on April 21 at 22:14 UTC) followed by two more the same day. The injected code grabs tokens, API keys, SSH keys, credentials for cloud services, CI/CD systems, container registries, and LLM platforms, plus Kubernetes and Docker configs, then rifles through Chrome and Firefox for cryptocurrency wallet data including MetaMask, Exodus, Atomic Wallet, and Phantom. If the malware finds an npm publish token in environment variables or ~/.npmrc, it identifies every package the victim can publish, injects itself into each, bumps the version, and republishes - a worm in the literal sense. It applies the same trick to PyPI via a .pth-based payload if Python credentials are present, making this a cross-ecosystem threat. Socket and StepSecurity note the techniques mirror TeamPCP's CanisterWorm attacks but stop short of definitive attribution.

Check
Search your package-lock and yarn.lock files and private registry caches for any of the listed Namastex Labs versions, and then rotate every credential that has ever been present on a machine that installed them.
Affected
Confirmed malicious versions per Socket: @automagik/genie 4.260421.33 through 4.260421.39; pgserve 1.1.11 through 1.1.13; @fairwords/websocket 1.0.38 through 1.0.39; @fairwords/loopback-connector-es 1.4.3 through 1.4.4; @openwebconcept/theme-owc 1.0.3; @openwebconcept/design-tokens 1.0.3. Any additional npm package republished by an account whose publish token was exfiltrated by this worm is also potentially malicious.
Fix
Remove the listed versions from development environments, CI/CD runners, and private mirrors immediately. Rotate every secret the worm would have seen: npm publish tokens, PyPI tokens, cloud provider keys, CI/CD deploy keys, SSH keys, LLM platform API keys, container registry credentials, and any crypto wallet seeds stored in browser extensions on affected machines. Audit your package caches and internal mirrors for related packages that share the same public.pem file, webhook host, or postinstall pattern (Socket publishes IoCs for this). Pin production dependencies to known-good versions with integrity hashes and deny the newest versions of the affected packages in your package firewall until forensics is complete.