LiteLLM confirms its release pipeline pushed malicious 1.107.0 packages to PyPI and container registries. The malware stole credentials and loaded remote-code tools. Affected artifacts were removed; private enterprise releases were not impacted.
Sources
What happened
In the early morning of October 21, 2026, LiteLLM's release pipeline was compromised and pushed a malicious version 1.107.0 to PyPI and to Docker Hub and GHCR. The package contained compiled malware: a credential stealer that runs every time Python starts, plus a remote-code loader backdoor. According to LiteLLM's own incident write-up, the attacker held GitHub CLI OAuth tokens from three engineers, used an organization owner's token to disable branch protections, pointed the release workflow at a lookalike repository (Berri-AI/litellm instead of BerriAI/litellm), and let the normal signing pipeline publish the poisoned artifacts. LiteLLM believes the tokens were harvested from logs of an internal LiteLLM deployment that was exposed to the public internet, possibly through a recently patched vulnerability; it notes that Claude Code can embed a user's GitHub CLI OAuth token into response bodies, and those bodies may land in LiteLLM logs. This is LiteLLM's second supply chain compromise of 2026; Datadog linked the earlier March incident (versions 1.82.7 and 1.82.8) to TeamPCP and says no connection between the two has been established.
Exposed
Anyone who ran pip install on litellm 1.107.0 between 11:39 and 13:23 UTC on October 21, or started the v1.107.0, latest, main-latest or main-stable Docker Hub images between 11:46 and 14:20 UTC (affected GHCR tags were unavailable by 13:51 UTC). The stealer collected cloud credentials (AWS, GCP, Azure, including instance metadata), Kubernetes, Docker, Vault and Terraform secrets, SSH, GPG and TLS keys, Git, npm and PyPI tokens, .env files, shell history, LLM provider API keys, AI coding tool sessions, browser saved passwords and cookies, and credentials stored in a LiteLLM proxy database. Data went encrypted to the lookalike domain www.litellm[.]dev/healthcheck. The backdoor polled a fixed GitHub-hosted file hourly for a new domain; Datadog says that file only ever held test values, so no second-stage payload was observed in the wild. Enterprise customers on LiteLLM's private registry were not affected, and the official 1.107.0 source tag on GitHub is clean.
Do this
Affected artifacts were removed or repointed on Oct 21. LiteLLM recommends an explicit clean pin such as 1.106.2. On an affected host, follow the vendor's ordered cleanup before running Python or pip: startup hooks can re-execute the malware. Remove persistence, rebuild from trusted images, then rotate every credential the host or proxy database could reach. Do not treat uninstalling the package as complete cleanup.
Still unknown
LiteLLM has not confirmed how the attacker first accessed its internal deployment. The investigation is ongoing and the company committed to rolling updates. The number of users who installed the malicious artifacts has not been published.
Confirmed by LiteLLM and Datadog: v1.107.0 was live on PyPI from 11:39 to 13:23 UTC on October 21 (morning UTC; afternoon in India) with a credential stealer and a remote-code loader. The claim omits that Docker Hub and GHCR tags were also compromised for a slightly longer window.
Responses
LiteLLM (CEO, CTO, Director of Security)
Published a detailed incident post with the attack chain, exact compromise windows, artifact digests, cleanup steps and a promise of updates every two hours; status marked contained with investigation in progress.
Datadog Security Labs
Independently analyzed the payload: a Python-startup credential stealer exfiltrating to a lookalike domain plus an hourly remote-code loader whose second stage was never observed live; noted this is LiteLLM's second 2026 compromise with no established link to the March TeamPCP incident.
When
21 Oct 2026; PyPI 11:39–13:23 UTC
Note
This is the October 1.107.0 compromise, separate from the earlier 2026 1.82.x incident. The official advisory lists affected registry tags and the exposure windows.
Onamae says malicious programs were placed in customer Desktop Cloud server environments. Up to 26,739 servers were potentially affected, and it began stopping servers to contain the incident. Data viewing was possible; data theft was not confirmed.
Sources
When
Malware confirmed 20 Oct; notice 21 Oct 2026
Note
The provider’s potentially affected server count is not a confirmed count of servers with stolen data. The incident concerns the Desktop Cloud product, not every Onamae or GMO service.
PHP fixed two critical core bugs, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. The PHP team rates both 9.2 and urges immediate updates. All web-serving PHP installations need review, with the highest demonstrated risk in Apache mod_php.
Sources+1
What happened
Two memory-handling bugs in PHP itself can allow unauthenticated remote code execution. One involves out-of-memory cleanup; the other leaves stale state for a later request in the same worker. PHP released fixes on Oct 21. The PHP project uses the CVE identifiers; php2shell is the researchers' name.
Exposed
PHP rates both CVSS v4.0 9.2 (the leaked post claimed 10.0). On Apache mod_php, an unauthenticated request can trigger the first bug before application code runs. Amazon Threat Intelligence (via Tenable) reports exploitation attempts from Oct 17, before disclosure. CISA's Oct 21 alert said it had not itself observed exploitation at publication.
Do this
Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. CISA says take PHP systems offline if you cannot patch or you run PHP 8.1 or older, and that a WAF may give partial protection.
Still unknown
PHP is embedded in many products, so inventory is hard. End-of-life branches have no official fix except source backports (per Tenable). The PHP Foundation admitted a fix for the underlying out-of-memory problem had stalled for months.
Claims, checked
✓
[9.2] Unauth RCE in PHPsupported
PHP and Check Point both give CVSS v4.0 9.2 and unauthenticated RCE.
~
70% of the webroughly right, needs qualifier
W3Techs on Oct 22 says PHP is used by 69.3% of sites whose server-side language is known. Not 70% of all websites.
~
CISA: Patch or GO OFFLINEpartly
CISA says patch immediately; take systems offline only if you cannot update or run PHP 8.1 or earlier. WordPress, Drupal and Laravel are affected only if they run an unpatched PHP; CISA's alert does not name them.
~
Exploitationreported by Amazon, not CISA
Amazon Threat Intelligence reports attempts from Oct 17 per Tenable; CISA had not observed any at its publication time. Not on the KEV list in the captured sources.
Responses
CISA
Urges immediate patching; offline if unpatchable or PHP 8.1 and older.
PHP Foundation
Explains the bugs, credits finders, admits the fix was delayed by decision-making and resources.
Check Point
Timeline of the leak and IPS/WAF coverage.
When
Disclosed / fixed 21 Oct 2026
Note
This is a vulnerability and patch advisory, not proof that every PHP installation was breached. CISA advises taking systems offline if they cannot be patched or run PHP 8.1 or older; it does not tell every patched site to go offline.
Railway says an unauthorised party may have accessed encrypted customer environment variables and decrypted some of them. It paused deployments during its investigation and recommended credential rotation. The affected-account scope remained unresolved.
Sources+1
What happened
On the morning of October 21, 2026, Railway detected anomalous activity in the systems that store customer environment variables. It disclosed that an unauthorized third party may have accessed those encrypted variables and, for some customers, obtained the decrypted contents. Railway says it believes the attack is part of a series targeting platform companies with the aim of compromising AI inference providers, and it asked those providers to revoke keys proactively. A Railway employee wrote on Hacker News that preliminary forensics point to AI credentials as the attacker's primary goal and called the attacker highly motivated, while cautioning that a formal postmortem is still pending and that the company balanced its duty to warn against the risk of messaging before exploit paths were closed. Railway has not said how the attacker got in.
Exposed
Secrets customers stored as environment variables: API keys, database passwords and private registry credentials. Railway says its initial analysis suggests the impact may be limited to a subset of users, but it has not given a count of affected accounts. Separately, individuals reported on X and Hacker News that AI keys stored on Railway were drained in real time, and the founder of Postiz said he took that service offline after Anthropic and Stripe warned that its keys were compromised. Those are individual reports, not Railway findings. Railway has not said that consumers' personal data was taken.
Do this
Railway paused all deployments while it investigates, told every customer to immediately roll all environment variables, API keys and private registry credentials, and to review service logs for unusual activity. It reset the credentials it holds on customers' behalf: S3 access keys for every storage bucket and the GitHub tokens Railway held, which forced redeploys for bucket-using services and a manual GitHub reconnect. It published step-by-step follow-up guides covering the bucket and GitHub resets, database credential rotation, and how to check OpenAI, Anthropic, Grok, OpenRouter and Stripe accounts for misuse. It says it will email confirmed-affected customers directly.
Still unknown
The entry point and affected-account count are undisclosed, and a formal postmortem was not yet in the checked disclosure. Railway had paused deployments during investigation; its live status page, rather than this snapshot, determines restoration status. Downstream access to customers' application databases has not been established.
Claims, checked
~
Railway BREACHED TODAY. Env variables decrypted. Your API keys and DB passwords exposed. Rotate all.mostly accurate
Railway disclosed on October 21 that an unauthorized party may have accessed encrypted environment variables and decrypted some of them, and it does recommend rotating everything. Nuances: Railway frames access as possible rather than fully confirmed, says impact may be limited to a subset of users, and has not said how many accounts were affected or how the attacker got in. The disclosure was October 21, one day before the user's message.
Responses
Railway (official disclosure)
Disclosed possible access to encrypted environment variables with some decrypted contents, recommended rotating all secrets, paused deployments, and linked the attack to a series targeting AI inference providers.
Railway (engineering)
Explained that Railway staff reset every bucket's S3 credentials and the GitHub tokens it held, and published redeploy and reconnect instructions.
Railway employee on Hacker News
Said preliminary forensics indicate AI API tokens were the attacker's primary goal, described a highly motivated attacker moving laterally, and explained the aviate-navigate-communicate reasoning for the timing of public messaging.
Railway status page
Tracks the deployment pause and build restoration during the investigation.
When
Disclosed 21 Oct 2026; investigation ongoing
Note
Railway confirmed the investigation, not a final count of exposed accounts. The deployment pause was precautionary. Follow the current status page for restoration updates.
Microsoft Threat Intelligence reports that China-state-aligned Storm-0940 used ARTEX agentic AI to automate attacks targeting hundreds of organizations. Some attacks gained privileged cloud access in under three hours. Microsoft attributes the ConnectWise supply-chain compromise to this campaign; that incident is also listed separately with its vendor response.
Sources
What happened
Microsoft reports that Storm-0940, a China-state-aligned actor, used the ARTEX agentic AI framework from at least September 2026 to automate reconnaissance, password spraying and OAuth application abuse across hundreds of organizations. Microsoft assesses that the ConnectWise Cloud Backup compromise was part of this campaign. Its X followup explicitly makes that attribution and describes the hundreds-targeted scope.
Exposed
Microsoft observed privileged cloud access in several attacks, including cases under three hours from targeting to access. It also describes Graph reconnaissance, application credential changes and attempted privilege changes. Targeting and successful authentication do not by themselves prove customer-data theft. Microsoft says this did not result from a compromise or vulnerability in its corporate systems, products or services.
Do this
Microsoft recommends preserving relevant sign-in/audit evidence, investigating unexpected service-principal activity and application credential or privilege changes, and following ConnectWise containment guidance. Revoking the original vendor credentials alone may not remove separately planted credentials or other persistence. Use the primary report and vendor advisory for current steps.
Still unknown
The campaign spans different attacks and populations. Microsoft says most targeting was unsuccessful, but privileged persistence was achieved at many organizations. A total of unique organizations compromised or records stolen is not established by the hundreds-targeted figure. ConnectWise remains the same included incident, not an extra duplicate compromise.
Claims, checked
✓
Microsoft confirmed a China-state-aligned group used AI agents against hundreds of organizations, including ConnectWisesupported as Microsoft assessment
The actual Microsoft X followup and linked primary report support this. Keep targeting distinct from successful compromise and attribution as Microsoft assessment, not an independently audited conclusion.
Responses
Microsoft Threat Intelligence on X
Assesses Storm-0940 was responsible for the ConnectWise supply-chain compromise and says it used ARTEX to target hundreds of organizations. The post links the Microsoft report. Displayed Oct 22 at 02:03 in the reading session.
Microsoft Security Research and Threat Intelligence
Published the Oct 21 campaign report, telemetry, detection and containment guidance. Explicitly says Microsoft systems/products/services were not the compromised source.
When
Activity from at least September 2026; report Oct 21
Note
Microsoft is the reporting source, not a breached company in this report. Hundreds targeted does not mean hundreds compromised. This broader campaign includes the ConnectWise incident; do not add the two entries together as independent victim counts.
GitLab released fixes for CVE-2026-110264, a CVSS 10.0 flaw in its bundled regular-expression compiler that could allow unauthenticated code execution under certain conditions. Older self-managed releases are affected; no exploitation was known in the captured reporting.
Sources
What happened
On Oct 21, 2026 GitLab shipped a critical patch for CVE-2026-110264, an integer overflow in its regular expression compiler. Under certain conditions it could let an unauthenticated user run code on a self-managed server. GitLab rates it CVSS 10.0; the detailed exploitation conditions are not public.
Exposed
Self-managed GitLab CE and EE only. GitLab lists affected versions from 7.0 up to the fixed releases. An Oct 12 fix for a different bug does not resolve this Oct 21 vulnerability. GitLab.com already runs the fixed version. Same release also fixes high-severity LDAP auto-linking and OAuth/OIDC cache poisoning issues.
Do this
Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13.
Still unknown
No reported exploitation and not on CISA KEV as of Oct 22 per The Hacker News. Exploitation conditions undisclosed.
Claims, checked
~
GitLab 10.0/10, unauthenticated RCEsupported, with conditions
GitLab's own current patch notice lists CVSS 10.0 and affected releases from 7.0, and says an unauthenticated user could execute code under certain conditions. That is not proof every server was exploited.
~
Which CVEtwo separate ones
CVE-2026-97229 (Oct 12) and CVE-2026-110264 (Oct 21) are different. Use the Oct 21 one for the current claim.
Responses
GitLab
Critical patch release; strongly recommends all self-managed installs upgrade immediately.
When
Fixed 21 Oct 2026
Note
Potential remote code execution is not proof of exploitation. The advisory concerns self-managed GitLab; hosted services and detailed supported release guidance are covered in GitLab’s own notice.
A researcher found 333 Tor exit relays (~10% of the network's ~3,000 exits) redirecting SSH connections through 12 interception servers using the Ebury OpenSSH backdoor, harvesting passwords when users accepted forged host keys. Exit policies on hundreds of relays were rewritten Oct 1-5; Tor directory authorities removed the compromised relays around Oct 20-21.
Sources
When
Exit-policy rewrites Oct 1-5; researcher scan Oct 2; removals and coverage Oct 20-22, 2026
Note
The figure of 333 exit relays comes from a researcher’s scan. It is a reported observation, not an independently verified count of distinct breached relay operators.
Bullhorn’s status updates describe separate events: a contained 17 October cyber incident, precautionary PHP2Shell product shutdowns, and a 21 October login outage linked to database-replication lag. They should not be presented as one confirmed breach.
Sources
When
Separate events 17–22 Oct 2026
Note
The PHP shutdown, the earlier cyber incident and login replication problems are separate. The status page is a changing source; this entry reflects the captured 21–22 October updates.
A group calling itself Scarlettgroup claims to have breached Rajasthan Police and offered data for sale. Coverage repeats claims of about 70,000 identity records and 59,460 mobile numbers. These figures and the alleged breach are unverified.
Sources
What happened
On Oct 21, coverage attributed to an X monitoring account reported that a group calling itself Scarlettgroup claimed to have breached Rajasthan Police. The group claims about 70,000 identity records and 59,460 mobile numbers, plus documents and attachments. These are the group's claims, not independently verified counts.
Exposed
Unknown. Nobody independent has confirmed the data is genuine, or that it came from Rajasthan Police systems. If genuine it would be an identity theft and fraud risk.
Do this
None reported.
Still unknown
Authenticity, source system and scope are all unconfirmed. Coverage reported no Rajasthan Police comment at publication. No leak forum or sample data was accessed for this index.
Claims, checked
?
Group claims 70,000 identity records + 59,460 numbers for sale. Unverified.claim accurately reported, unverified
The numbers match the group's own claim as reported. Keep status 'alleged'. No confirmation by police or independent researchers found.
Responses
Response status
BusinessToday reported no police comment at publication on Oct 21. This is absence of a response in that coverage, not a police statement.
Node.js shipped October security releases covering four high-severity flaws alongside medium- and low-severity fixes. The release also updates certificate trust after eMudhra. Patched vulnerabilities do not by themselves establish an intrusion.
Sources
What happened
On Oct 21, 2026 the Node.js project shipped security releases v22.23.4, v24.22.1 and v26.12.1 fixing ten CVEs and updating bundled c-ares, OpenSSL (24.x, 22.x), SQLite (22.x), Undici and the CA certificate list to drop the eMudhra intermediates.
Exposed
CVE-2026-111497, a Brotli decoder out-of-bounds write that can permit remote code execution, affects 26.x, 24.x and 22.x. The release also fixes TLS hostname bypasses (CVE-2026-105483, CVE-2026-106069), a dns.resolve NUL truncation (CVE-2026-105482) and others. Node rates the highest of them 'high', not critical.
Do this
Upgrade to 22.23.4, 24.22.1 or 26.12.1. End-of-life Node versions stay affected.
Still unknown
Node's post does not say whether any of the ten CVEs was exploited. Treat that as unknown.
Two high-severity TLS hostname-validation bypasses (CVE-2026-105483, CVE-2026-106069), not one.
✓
10 CVEs patched todaysupported
Ten CVEs counted on the advisory; release date Oct 21, 2026 (not Oct 22).
✓
Also blocked eMudhrasupported
Advisory lists 'ca-cert (eMudhra Intermediate CA Compromise)' as a dependency update.
Responses
Node.js project
Security release across three lines; also removes eMudhra intermediates from the bundled cert list.
When
Released 21 Oct 2026
Note
The same release includes both independent vulnerability fixes and an eMudhra certificate-trust update. They are not all caused by the certificate incident.
SBI told stock exchanges that customer records had surfaced on the dark web, according to reporting. Reports distinguish more than 375,000 records from 3,897 containing personal information. The bank was still assessing authenticity and scope.
Sources
What happened
State Bank of India told stock exchanges on Oct 21, 2026 that about 375,000 records tied to it were found on the dark web, and that its preliminary analysis found 3,897 records with personal information. It learned of it on Oct 16 from its threat intelligence provider, the Defence Cyber Agency and CERT-In.
Exposed
For the 3,897: names, registered mobile numbers, dates of birth, gender, emails, addresses, branch and CIF identifiers, lead IDs and loan/lead metadata. The bank says authenticity and completeness still need a detailed investigation and that core operations are not affected.
Do this
SBI activated incident response and hired a CERT-In-empanelled agency. Customers have not been given specific steps in the checked sources.
Still unknown
Source of the leak, authenticity and full scope are not established. The Internet Freedom Foundation says affected customers could get calls from people posing as SBI who can recite their details, and wants SBI to notify them (The Hindu). BusinessToday says a group called Siriusim had claimed the hack on BreachForums; that claim is not verified.
Claims, checked
~
SBI CONFIRMED 3,897 customers' mobile, DOB, address + loan data on dark webmostly supported, qualify
SBI itself disclosed 3,897 PII records among ~375,000 found, per preliminary analysis, including loan/lead metadata. 'Confirmed' overstates it: the bank says authenticity and completeness are still being established. Say 'SBI disclosed'.
Responses
SBI, as quoted by The Hindu
Exchange disclosure with 3,897 PII records, investigation under way, no material business impact.
When
Bank alerted Oct 16; exchange filing and coverage Oct 21, 2026
Note
Reporting distinguishes more than 375,000 records from 3,897 containing personal information. Authenticity and scope remained under assessment; neither figure establishes that every record belongs to a different person.
Reporting describes a RingRTC flaw that could let a malicious participant continue receiving audio after the other person hangs up. Camera continuation is not confirmed. The issue concerns call shutdown, not a general break of Signal encryption.
Sources
When
Reported 21 Oct 2026
Note
Press reports describe audio continuation with a malicious call participant. Camera continuation remains uncertain. The library fix and the first fixed mobile app versions should not be assumed to be identical.
Tailscale published an emergency update to distrust the compromised eMudhra intermediate certificates. This is a downstream certificate-trust response, not a separate Tailscale breach. WireGuard mesh traffic does not rely on that public certificate trust.
Sources
What happened
Tailscale published bulletin TS-2026-013 on the eMudhra keys. Its client trusts whatever the operating system's certificate store trusts, so a forged eMudhra-signed certificate would have been accepted on devices that still trusted those intermediates.
Exposed
Only web PKI connections that rely on the system store. Tailscale says node-to-node WireGuard traffic does not use that store and is not affected. No exploitation reported in the bulletin.
Do this
Tailscale v1.104.2 or later (built with Go 1.27.3) explicitly distrusts the compromised certificates. Tailscale's own services were updated.
Still unknown
Devices on older clients with OS stores that still contain the intermediates.
Claims, checked
~
Tailscale incidentclarify
Tailscale was not breached. It published a bulletin and a client fix as a downstream user of the OS certificate store. The bulletin page lists it without a visible per-item date in what was fetched, so keep the Oct 21 date as 'listed by Oct 21-22'.
Responses
Tailscale
Bulletin TS-2026-013: update to v1.104.2 or later. Listed by Oct 21-22; a per-bulletin publication date was not visible.
When
Bulletin / release 21 Oct 2026
Note
This is a follow-on to the eMudhra certificate incident, not an independent Tailscale compromise. See bulletin TS-2026-013 and the current changelog.
The original list does not identify which North Korea-linked campaign it means. Reporting on Operation FlashHole is one possible lead, not a confirmed match to that claim.
Sources
When
Original claim not tied to a specific campaign
Note
The unspecific North Korea claim cannot be assigned to one event. October reporting covers separate campaigns and enforcement actions. Linked reports are leads, not evidence that they are the same campaign.
Plex confirms active exploitation of a chain of server vulnerabilities that can let an unauthenticated attacker run code. Update to 1.43.3.10861 or newer; Plex says an older internet-reachable server may already be compromised. CISA lists the four related CVEs as known exploited.
Sources+3
What happened
Four Plex Media Server bugs (CVE-2026-96652, -96654, -96655, -96656) can be chained to steal an admin token and run code. Plex patched in 1.43.3 (the Sept 1 forum post). The researcher published details Oct 16 and a proof of concept three days later. Exploitation reports began Oct 17, first against honeypots to install a cryptominer. CISA added all four to KEV on Oct 20.
Exposed
Plex Media Server before 1.43.3.10861. Chaining the bugs can let an unauthenticated remote attacker run code with the privileges of the Plex server process. Individual flaw scores differ; a chain score is not each individual CVE's score.
Do this
Update Plex Media Server to 1.43.3.10861 or newer. NAS installs may need a manual package install. Plex says an older server reachable from the internet should be treated as potentially compromised: update and follow its incident-response steps, not only apply the patch.
Still unknown
Servers not updated since August. How many real servers are compromised is unknown.
Claims, checked
✓
ACTIVELY EXPLOITED, cryptominerssupported
CISA KEV listing is based on evidence of active exploitation; BleepingComputer reports cryptominer deployment, first against honeypots.
~
CISA KEV, deadline Oct 23partly
KEV data shows due date 2026-10-23 for CVE-2026-96656 and -96654, but 2026-11-03 for -96652 and -96655. The deadline binds US federal civilian agencies only.
?
LIVEunverified wording
No source says attacks are happening 'live' right now beyond the reported campaign since Oct 17.
Responses
Plex
Forum notice, update posted Oct 19 with CVE details and confirmation of active exploitation.
CISA
Added the four CVEs to KEV Oct 20.
When
Exploit chain weaponized within hours of disclosure (~Oct 19); CISA KEV Oct 20, 2026
A new CISA/FBI advisory describes SafePay ransomware activity and at least 600 victims across critical infrastructure sectors. The advisory is new, not the group: SafePay has operated since 2024.
Sources
When
Joint advisory published Oct 20-21, 2026; group active since Aug 2024
Note
Not a new campaign: the advisory is new this week but SafePay has operated since Aug 2024. The advisory itself states the actors impacted at least 600 separate victims across multiple critical infrastructure sectors - the 'hundreds of organizations' framing is supported.
Reporting links multiple ransomware groups to exploitation of a patched PAN-OS GlobalProtect authentication bypass. The attacks began months before this week’s reporting; this is not a newly discovered October intrusion.
Sources
When
Reported 20 Oct 2026; exploitation since May–Jun
Note
Framing fix: onset was May 2026, not this week; this month's news is expanded/continued ransomware exploitation of the same patched CVE.
Eight eMudhra intermediate certificate-authority keys were weak enough to recover from public certificates, including one with the value 4. eMudhra revoked them. Its account says none issued end-entity certificates; this is not a confirmed breach of its infrastructure.
Sources+5
What happened
In April 2025 eMudhra, an Indian certificate authority, ran a key ceremony that produced eight intermediate CA certificates with badly weak private keys. A researcher found they could be recovered from the public certificates (some keys were single or double digit numbers, one reportedly just 4). He reported it to Mozilla, Chrome, Apple and Microsoft on Oct 17, 2026. eMudhra revoked all eight on Oct 19.
Exposed
Anyone who worked out the keys could have forged a trusted certificate for any website, but only against software that does not check Certificate Transparency or revocation lists. Chrome and Google say no certificates chaining to these intermediates had been logged to CT, so CT-enforcing browsers could not have been attacked. No exploitation has been shown. The 'eight keys' were six TLS intermediates and two code-signing intermediates.
Do this
Mozilla blocked them via OneCRL on Oct 17 (done for standard Firefox users by 22:59 UTC) and shipped Firefox 158.0.1, ESR 115.43.1 and 153.5.1, plus NSS 3.131.1 removing the signing root. Chrome blocked them by CRLSet the same day, and removed the emSign ECC Root CA - G3 from its root store. The reporter also says Apple and Microsoft blocked the certificates; their exact update dates were not independently verified here. Cloudflare, Node.js and Tailscale shipped updates.
Still unknown
Software that ships its own trust store or ignores revocation needs updates. eMudhra has not confirmed a root cause; it says a wrap/unwrap step created a second weak key set. It says seven of the eight were never used and the eighth issued no certificates. It says one US customer ecosystem needs replacement certificates. Investigation ongoing; MeitY has set up a probe panel.
Claims, checked
✓
Private key was literally 4supported
The Register says one was just the number 4 and others were two or three digit numbers. Talos says several keys evaluated to single or double digit integers. Mozilla's bug (2083449) is the underlying report.
✗
8 keys forged ANY websiteoverstated
Eight intermediates had recoverable keys, so forging any site was possible in principle. No forged certificate or attack has been shown. Google says no certificates were logged to CT, so CT-enforcing browsers were not exposed. Say 'could have', not 'forged'.
~
For 17 monthsmostly right as exposure window
Intermediates created Apr 30, 2025, reported Oct 17, 2026, about 17.5 months of vulnerability. eMudhra says about 18 months. Window of weakness, not of known abuse.
✗
60M+ certs at risknot supported
60 million is how many certificates eMudhra says it has issued overall (The Register's framing). The compromised intermediates reportedly issued none, and eMudhra says the impact is one US customer ecosystem. Do not state 60M at risk.
Responses
eMudhra
Says keys were revoked, no certificates issued from them, no data breached, signing/eSign services unaffected, key ceremony flaw not yet fully explained. Offers backup CA to enterprise TLS customers.
Mozilla
Received report Oct 17 20:06 UTC, blocked within hours, shipped Firefox and NSS updates.
Google Chrome and Android
Blocked by CRLSet Oct 17, removed the signing root from Chrome Root Store, says CT-enforcing clients were not exposed.
Cloudflare
Patched WARP, cloudflared, CDN and Zero Trust; found no active exploitation on its services; lists customer actions.
Cisco Talos
Lists the eight intermediates with hashes and notes eMudhra stopped issuing under its G3 root.
When
Reported 17–18 Oct; revoked 19 Oct; public 20–21 Oct 2026
Note
The vendor describes weak-key revocation rather than an infrastructure breach. Tailscale and Node.js updates are downstream responses, not additional breaches. Detailed timing and scope are in the vendor statement and Cloudflare report.
Reporting says a Paradigm Healthcare Services breach affected more than 970,000 Medi-Cal members. The intrusion was detected in October 2025; notifications followed in September 2026. This is a contractor incident, not a confirmed breach of California’s own systems.
Sources
When
Intrusion Oct 2025; notifications Sep 2026
Note
This is a 2025 intrusion with 2026 notification and reporting. The affected contractor handled Medi-Cal claims. The underlying HHS portal entry was not independently captured here.
Foxio’s research describes QPACK header-decompression amplification that can exhaust server memory. Seven of ten tested implementations were affected, with patch status varying by implementation. This is a vulnerability report, not proof that all affected servers were attacked.
Sources
When
Research published around 20 Oct 2026
Note
The affected implementation list and patch status were captured at disclosure. This is distinct from NGINX’s separately listed HTTP/3 issue. Consult the original research for current changes.
TeamUpdraft confirmed unauthorised access over 17–18 October. It believes its customer database was accessed and says attackers abused UpdraftCentral connections to create admin accounts and install malicious plugins. The full extent is unknown. Connection keys were revoked; the plugin downloads themselves were not affected.
Sources
What happened
Over the weekend of October 17-18, 2026, an attacker used a compromised key to gain unauthorized access to teamupdraft.com, the vendor of the UpdraftPlus WordPress backup plugin. TeamUpdraft believes its customer database was accessed and says the attacker abused UpdraftCentral - the remote management service built into every copy of UpdraftPlus - to send validly signed commands to connected sites, creating admin accounts and installing malicious plugins. Security firm Nethemba, whose own sites were hit on October 19, documented that the attacker held UpdraftCentral's private dashboard keys, which are generated and kept by the service, and could therefore install arbitrary code on any connected site. Nethemba's first installed backdoor was broken and crashed the site, which is how the intrusion surfaced within hours; working variants circulated afterward. TeamUpdraft says the speed of the exploitation and the initially faulty backdoor code suggest the attackers used AI to accelerate the operation. The plugin downloads themselves were not affected.
Exposed
TeamUpdraft believes its database was accessed, including customer contact/billing information, order history, password hashes, two-factor settings and service connection keys. Keys could let attackers command sites connected to UpdraftCentral Cloud. Nethemba observed malicious plugins on connected sites; install counts and estimates of possibly connected sites are not counts of breached sites. Sites without a connection key do not accept this attack path, and the vendor says self-hosted dashboards are unaffected.
Do this
TeamUpdraft closed the access route, signed out every account, replaced affected credentials, disconnected every site from UpdraftVault and replaced all UpdraftClone client keys. It shipped emergency UpdraftPlus releases to delete old UpdraftCentral cloud keys: 1.26.12 and 2.26.12 on October 19 contained a bug that deleted nothing, fixed the same evening in 1.26.13 and 2.26.13, which WordPress.org pushed to all sites automatically. Nethemba found even 1.26.13 only deletes keys created before 12:07 UTC on October 18, so keys created between 12:07 and 21:00 UTC that day must be deleted by hand. Site owners are told to check Users and Plugins (including Must-Use) for anything unrecognized, change admin passwords, and treat sites as potentially compromised until checked. TeamUpdraft reported the incident to the ICO and police and brought in an external security firm. Wordfence released a firewall rule blocking UpdraftCentral commands.
Still unknown
The full extent of site compromise through the leaked keys is unknown. As of October 21 the attacker was still sending UpdraftCentral commands to Nethemba's sites (blocked there), meaning stolen keys keep working on any site that has not updated and deleted them. How the initial teamupdraft.com key was compromised has not been explained. TeamUpdraft's updates also note it temporarily took its support form offline because of the separate industry-wide PHP vulnerabilities.
Responses
TeamUpdraft
Confirmed the unauthorized access, listed the database contents believed accessed, detailed remediation (account sign-outs, key replacements, UpdraftPlus 1.26.13/2.26.13 disconnect update), reported to the ICO and police, and urged UpdraftPlus Premium users to check sites for unexpected plugins, activity and admins even if they never used UpdraftCentral.
Nethemba
Published a technical analysis showing the attacker signed commands with the service's own leaked keys, documented three backdoor variants (broken, working, minimal), provided a checking script and mu-plugin blocker, flagged the 1.26.12 deletion bug and the key-deletion gap in 1.26.13, and kept logging renewed attacker command attempts through October 21.
The Hacker News
Reported that attackers abused UpdraftCentral keys to compromise WordPress sites.
CSO Online
Covered the WordPress site compromises following the TeamUpdraft credential exposure.
When
Detected 17–18 Oct; disclosed 19 Oct 2026
Note
The vendor believes the customer database was accessed. It confirmed abuse of UpdraftCentral connections, but the extent of affected customer sites remained unknown. Its advisory was still being updated.
Norforge reports exposed dashboards showing threat actors abusing the open-source Cairn agent platform for intrusion attempts. Its researcher told press that one actor breached more than 100 companies. This is a research assessment, not a verified victim-by-victim count.
Sources
When
Research / reporting 17–20 Oct 2026
Note
Cairn is the tool being abused, not a breached vendor. The 100+ figure is attributed to the researcher. This entry omits victim names originating in excluded reporting. The separate Microsoft ARTEX campaign should not be assumed to be the same operation.
OVHcloud says an attacker replaced official CLI release binaries with credential-stealing malware. Versions 0.11.0–0.15.0 were affected during a roughly 94-minute window on 19 October; 0.16.0 was not.
Sources
What happened
On Oct 19, attackers used a compromised OVHcloud developer GitHub account to replace release binaries for CLI versions 0.11.0 through 0.15.0 with credential-stealing malware. Source code and the internal production build platform were not affected. OVHcloud removed the malicious assets and enabled immutable GitHub releases.
Exposed
Only users who downloaded or installed CLI versions 0.11.0 to 0.15.0 during the 94-minute window on October 19 (14:47 to 16:21 UTC+2) are affected; OVHcloud counts roughly 250 downloads. Earlier downloads of the same versions are unaffected, as are v0.10.0 and below and v0.16.0. The malicious binaries were the real CLI recompiled with embedded malicious Go code, designed to steal secrets and files. Users can check for a temp folder named envchecker-xxxx and verify their binary against the MD5 hashes of compromised builds in the advisory appendix.
Do this
Do not run a suspected binary to check it. Compare its hash with the vendor advisory, delete affected binaries, and use the clean signed 0.16.0 release or a later trusted release. If an affected binary ran, OVHcloud says to treat reachable secrets as compromised and follow its credential-rotation and host-review guidance.
Still unknown
OVHcloud now traces the stolen developer credentials to a malicious editor extension installed on a personal MacBook in 2025, with infrastructure linked to GlassWorm. It says the corporate laptop and internal production platform were not compromised. The number of downloads is about 250, not a confirmed count of infected users.
Published the full timeline, the 94-minute exposure window, the roughly 250 downloads, hash-based checking instructions, and the immutability fix applied organization-wide.
Octave Klaba, OVHcloud (X)
Public announcement of the incident on X within hours of containment.
The Hacker News
Reported the hijack of five CLI releases and the credential-stealing payload.
Dark Reading
Reported the compromise and linked it to GlassWorm threat actors.
When
Malicious binaries live Oct 19, 2026, 14:47-16:21 UTC+2
PingCAP confirms unauthorised access to internal cloud resources between 9 September and 7 October, including copied data and source code. The breach is confirmed, but claims about plaintext keys and the full customer impact are disputed or unresolved.
Sources
When
Disclosed 19 Oct 2026; intrusion 9 Sep–7 Oct
Note
Breach confirmed; scope disputed - attacker leak-site figures (10.6 TB, 115k plaintext keys) are unverified claims that conflict with PingCAP's statement that keys were encrypted and unused.
OpenCode confirmed a security breach affecting 1.4% of Console users during a large-scale attack. Reporting says stored keys for linked AI providers were exposed and some users saw unauthorised charges. The official post confirms the breach, not an audited total of financial losses.
Sources
What happened
Overnight around October 17-18, 2026, attackers broke into an older OpenCode system and reached stored API keys that some users of the hosted OpenCode Console had linked to external AI providers. OpenCode announced on October 18 that it had suffered a security breach related to a large-scale distillation attack affecting 1.4% of Console users, and said it emailed everyone affected that morning; users without an email were not impacted. Co-founder Dax Raad said attackers had been hitting the company's systems nonstop for at least 48 hours using AI agents, and that the investigation was hampered when the AI models OpenCode was using began refusing to analyze malicious code because of safety filters. The team said things stabilized after OpenAI gave it access to Daybreak, a program offering models vetted for defensive security work. The open source app and CLI were not affected; only the hosted Console stored such keys. The breach happened the same night OpenCode made GLM-5.3-Flash free for users.
Exposed
Stored keys for linked providers including OpenAI, Anthropic and Google, for the 1.4% subset of Console users who had external providers linked. The notice to impacted users says the earliest possible key exposure was October 17, 2026, 00:30 UTC, and that no other data appears to have been exposed. Users then reported unauthorized charges on Reddit and X, commonly hundreds of dollars and in some cases over 1,000 or 1,700 dollars overnight; some said Google suspended their projects for abusive activity consistent with hijacked resources. Charge figures are user reports, not an audited total.
Do this
OpenCode notified affected users by email on the morning of October 18 and told them to revoke and replace their keys directly with each provider. It said it was working with Google, OpenAI and Anthropic. Anthropic and Google blocked the API keys they believed were exposed. OpenAI said it worked with OpenCode to restore access and refund credits used in the attack, and OpenCode said refunds for unauthorized charges were underway, with its email to impacted users mentioning possible reimbursement.
Still unknown
OpenCode has not explained how attackers gained access to the older system, how the keys were stored, or the full extent of misuse, and said the incident remains ongoing. The distillation framing is OpenCode's own characterization; skeptics quoted by TechCrunch argue the use of stolen keys for distillation is unproven and that this may be a straightforward breach. No audited total of financial losses exists.
Claims, checked
~
OpenCode BREACHED. OpenAI, Anthropic, Google API keys exposed for Console users. Distillation attack. Bills run up in $$$$.mostly accurate
The breach and provider key exposure for a 1.4% subset of Console users are confirmed by OpenCode, and unauthorized charges are real user reports (hundreds to over a thousand dollars). The distillation attack framing comes from OpenCode itself and remains unproven to outside skeptics; charge totals are user-reported, not audited.
Responses
OpenCode (official X account)
Announced the breach tied to a large-scale distillation attack, scoped it to 1.4% of Console users with linked external providers, and said all impacted users were emailed.
Dax Raad, OpenCode co-founder
Described 48 hours of nonstop attacks by AI agents, safety filters refusing defensive analysis, stabilization after getting OpenAI Daybreak access, and stressed that the open source app's keys never reach OpenCode.
BleepingComputer
Reported the key exposure, user-reported charges up to about 1,700 dollars, suspended Google Cloud projects, and the reimbursement mention in OpenCode's email.
TechCrunch
Reported the older-system breach, provider responses (Anthropic and Google blocking keys, OpenAI refunds), the Daybreak defensive-access angle, and skepticism that the distillation motive is proven.
When
Exposure reported from 17 Oct 2026; press 19 Oct
Note
The official OpenCode statement is linked alongside reporting and maintainer commentary. The company described a distillation attack; user charges and wider attribution are not independently audited. Do not treat every linked comment as a confirmed technical finding.
Attackers are abusing a DLL side-loading flaw in the signed Siemens Software Center client through ClickFix lures. Siemens says its systems and update channel were not breached.
Sources
When
Advisory SSA-580366 Oct 15; Siemens validated active exploitation Oct 19; CISA KEV Oct 20, 2026
Note
Not a breach of Siemens infrastructure: attackers abuse the signed client via ClickFix lures. Siemens explicitly states no Siemens system or update channel was breached.
Ahold Delhaize took systems offline after detecting malicious activity, disrupting websites, apps and deliveries. Stores remained open. Its 19 October update reported recovery progress and no evidence then of sensitive data theft.
Sources
When
Detected 12 Oct; recovery update 19 Oct 2026
Note
The incident began on 12 October, before this week’s reporting. The company’s no-evidence-of-data-theft statement is time-bound and does not close the investigation.
Compromised ConnectWise Cloud Backup application credentials enabled unauthorized Microsoft 365 sign-ins. Huntress saw sign-in activity in almost 1,000 tenants, over 300 successful; these are sign-in counts, not proven data-theft counts. Affected tenants need application-credential and audit review.
Sources+2
What happened
Attackers used compromised ConnectWise Cloud Backup application credentials to request Microsoft Graph tokens in customer Microsoft 365 tenants on Oct 15. Huntress observed automated sign-ins and, in two reviewed tenants, privilege escalation plus added client secrets that could maintain access. ConnectWise later attributed the attack to a China state-aligned group using an agentic AI framework, citing Microsoft intelligence. That attribution is not independent proof of every claim about the wider campaign.
Exposed
Any tenant that ever consented to the ConnectWise Cloud Backup or related Cloud Management applications was reachable, since the stolen credential works everywhere the apps are consented. Huntress identified almost 1,000 Entra tenants with sign-in activity from the attacker IP, with over 300 successful; it confirmed unauthorized sign-ins in 162 tenants as of October 16. Backup app permissions are broad (mailboxes, OneDrive, SharePoint, Teams, directory data), but Huntress found no evidence of mailbox or file manipulation in the two tenants with post-compromise activity, while warning that Microsoft Graph directory reads leave no audit record, so reads cannot be ruled out. A successful sign-in is not proof of data theft. ConnectWise says existing backup archives remain encrypted, isolated and preserved, with no indication of compromise, and no other ConnectWise products are impacted.
Do this
ConnectWise shut off the Cloud Backup application connections, completed an account and credential reset in the affected environment, and began phased service restoration on October 21, with each step security-validated and expected to take several days; from October 22 it posts updates twice daily. Partners are told to keep affected connections disabled until formal reconnection instructions arrive, and to review every Microsoft 365 tenant (their own and managed customers') using ConnectWise's technical guide: Huntress and Sophos advise disabling (not deleting) the abused application IDs, auditing Entra sign-in and audit logs from October 13 onward, and reviewing credentials on all applications because disabling apps does not remove secrets the attacker already planted. Huntress enabled App Instance Property Lock across its own applications after one was backdoored.
Still unknown
How the vendor credential was obtained remains unclear. Graph directory reads may leave no audit trail, so the full use of issued tokens cannot be established. Each partner still needs to review its own tenants. Service restoration was phased; the current vendor advisory is the source for reconnection status.
Responses
ConnectWise (Trust Center advisories)
Confirmed unauthorized access to Cloud Backup application credentials, suspended access, completed credential resets, began phased restoration, and on October 21 attributed the attack to a China state-aligned group using an agentic AI framework, citing Microsoft threat intelligence.
Huntress
Published detailed telemetry: the vendor credential authenticating from 144.172.64.128, confirmed sign-ins in 162 tenants, the Global Administrator self-grant and planted secrets in two tenants, a second targeted wave against 16 policy and critical-minerals tenants, and its own application being backdoored and cleaned.
Sophos X-Ops
Described a roughly 96-minute automated cross-tenant token sweep with one app-only Graph token requested per tenant in ascending GUID order, no hands-on activity observed, and published indicators.
Microsoft Security Intelligence (X)
Shared the threat intelligence behind the Storm-0940 and ARTEX attribution that ConnectWise cited.
When
Discovered Oct 14; disclosed Oct 16; identities disabled Oct 17, 2026
Note
Microsoft attributes this incident to the broader Storm-0940 / ARTEX campaign, indexed separately as a campaign report. It is the same ConnectWise compromise, not a second supply-chain incident. Sign-ins and targeting do not prove every tenant lost data.
California’s education department notified families about files copied from testing contractor ETS. The records span three school years and include sensitive student information. The copying happened between May and September, not during this week’s reporting.
Sources
When
Disclosed 16 Oct 2026; copying May–Sep
Note
The intrusion occurred months before public disclosure. ETS was the affected contractor; California’s notification describes the student-data categories and three-school-year scope.
The official Rank Math PRO 3.0.123 download contained malware during an 11-hour window on 15–16 October. The vendor released clean version 3.0.124 and published recovery guidance. The free WordPress plugin was not affected.
Sources
What happened
Rank Math identified that the official download of Rank Math PRO version 3.0.123 contained malware for an 11-hour window, from October 15, 2026 20:02 UTC to October 16, 2026 07:12 UTC. Anyone who installed and activated that build in the window should treat their WordPress site as compromised. The free Rank Math SEO plugin on WordPress.org was not affected. Rank Math removed the affected files and released clean version 3.0.124. Reporting by BleepingComputer, SecurityWeek and The Hacker News frames this as a supply chain compromise of the vendor's download infrastructure; Rank Math's own page focuses on the recovery steps and does not detail how the files were poisoned.
Exposed
Limited to Rank Math PRO users who downloaded or updated to 3.0.123 during the affected window. Sites that installed but never activated the plugin are told to delete the files and scan as a precaution; downloads without install show no indication of compromise. The malware can recreate its hidden backdoor whenever someone visits the site, and it plants malicious entries in the wp_options table (option names _uf6qdn2hmm, t8krdk990phb, _np5pvf754c) and talks to the domain rank1cdn.com. Separately, some free users' Rank Math account details were deleted as a side effect of the vendor's system refresh, with emailed re-creation instructions.
Do this
Rank Math removed the malicious files, shipped clean PRO 3.0.124, and published a recovery guide: restore the site and database from a backup predating October 15 20:02 UTC (its recommended option), or clean manually in a strict order - delete the rank-math-pro folder entirely (deactivation is not enough), remove the malicious wp_options entries, and block outgoing connections to rank1cdn.com before removing other suspicious files, because the malware can rebuild itself. Afterward, change all site passwords, database credentials and API keys, and install 3.0.124 from the Rank Math account.
Still unknown
Rank Math has not publicly explained the intrusion vector that put malware into the official download, and has not published a count of affected sites. The full capability set of the backdoor beyond self-reinstallation is described only in third-party reporting.
Responses
Rank Math
Published the incident KB with exact affected window and versions, recovery instructions (backup restore or ordered manual cleanup), the clean 3.0.124 release, and a note that free users were not affected.
BleepingComputer
Reported that the popular WordPress SEO plugin's PRO build was compromised to backdoor websites.
SecurityWeek
Covered the incident as a supply chain attack on the Rank Math PRO WordPress plugin.
When
Malicious download window Oct 15 20:02 UTC - Oct 16 07:12 UTC, 2026; vendor advisory Oct 16
Note
Affects PRO 3.0.123 only, in an ~11 hour window; clean 3.0.124 already shipped.
Zeabur confirms attackers read 3,218,965 environment-variable records and data for 321,810 accounts, among other affected systems. It revoked credentials and urges secret rotation and migration. Some services begin shutting down Dec 1; all dedicated servers and shared clusters stop by Dec 31, 2026.
Sources+1
What happened
Over October 14 and 15, 2026, an attacker used Zeabur internal credentials stored in plaintext to walk through two paths that met inside Zeabur's internal network. On one path they used internal AWS keys and shared-cluster admin tokens (no expiry, created January 2024, admin interface open to the public internet) to read service settings, environment variables and the contents of 865 database containers across 9 regions, then about 53 production secrets from the secrets management service. On the other they used an old GCP key to read root passwords stored in plaintext in server initialization settings and signed in as root to 101 GCP Dedicated Servers. From a compromised server they added a node to Zeabur's internal network and read the platform database through an internal read-only account for about 37 minutes on October 15. Zeabur's preliminary report distinguishes confirmed, assessed and unconfirmable facts throughout, and corrects its August statement that all internal admin keys had been rotated: that statement was incomplete, which is exactly why the credentials used this time were still valid. This was Zeabur's second breach in under two months. On October 17 the founder announced Zeabur is shutting down entirely, citing the incidents and deeper maintainability problems, not only the breach.
Exposed
Confirmed read from the platform database: 3,218,965 environment variable records (names and values), 321,810 accounts (email, username, phone number), 566 plaintext zSend API keys (revoked) and 11,536 platform Access Tokens stored only as hashes (all revoked). On the shared cluster, environment variables and secrets of all services in 9 regions were read (partly confirmed), and 865 database services had commands run inside them, including n8n at scale and some PostgreSQL databases table by table. 101 GCP Dedicated Servers (92 users) had confirmed root sign-ins. Zeabur says the attacker was mainly hunting directly usable API keys, especially AI service keys, and treats everything read as leaked. Taipei and Hong Kong database backups should be treated as leaked. No use of the Zeabur GitHub App against user repositories was found.
Do this
Zeabur revoked the cluster admin tokens, AWS and GCP keys and the internal network node, blocked public SSH to admin interfaces, signed out all users and revoked all platform Access Tokens and zSend keys. Its user guidance: replace every password and key stored on Zeabur even if already rotated after August, recreate access tokens, change database-internal passwords, rotate n8n encryption keys and new-api/one-api upstream keys, audit GitHub for Zeabur App actions in the October 15 window, and check bills back to October 14 (September 1 for GCP servers). GCP Dedicated Server users are told to treat servers as compromised and rebuild. Separately, Zeabur published a wind-down plan: new purchases stopped immediately, shared cluster services pause December 1, everything shuts down by December 31, 2026, with refunds, compensation claims and a migration guide handled through support.
Still unknown
Zeabur lists plainly unresolved items: how the initial credentials were obtained (its leading hypothesis, the GitHub App key leaked in August exposing the private configuration repository, is explicitly unproven and GitHub had not replied to its records request), how much data was actually pulled from cluster databases (logs keep commands, not output), the download scope of backups and storage objects, read activity on GCP, whether Hetzner and DigitalOcean tokens were used, and anything before October 14. Unknown root sign-ins to the same GCP servers were recorded September 1 to 5 and cannot be attributed.
Responses
Zeabur (preliminary incident report)
Published an unusually detailed report with the two attack paths, a data table with certainty levels, root causes (plaintext credentials, no-expiry admin tokens, over-privileged keys, incomplete log coverage), and explicit open questions and unconfirmed hypotheses.
Yuanlin Lin, Zeabur founder
Announced Zeabur is winding down: new purchases stopped immediately, renewals disabled and shared-cluster services paused December 1, full shutdown by December 31, 2026; apologized and offered refunds, compensation claims and a migration guide including a Markdown version for coding agents.
Zeabur status page
Opened the incident October 15 and marked it resolved October 20 with a pointer to the preliminary report.
BleepingComputer
Reported that Zeabur is shutting down after its second security breach in two months.
When
Attack ran Oct 14-15, 2026 (UTC); status incident opened Oct 15; shutdown announced Oct 17; preliminary report Oct 19; full wind-down Dec 1-31, 2026
Note
The October incident followed an earlier breach. See the vendor status page and shutdown announcement for the current service position.
Google’s threat researchers found brief tampering with AOMEI Backupper update infrastructure that redirected selected users to malware. The attacks happened between April and July; the research was published in October.
Sources
When
Research published 15 Oct 2026; attacks Apr–Jul
Note
Framing fix: the hijacking happened April-July 2026; only the disclosure is new this month. Vendor had not proactively notified customers as of Oct 20.
NGINX’s October release fixed five newly published security advisories. The vendor rates all five medium, not critical. One concerns HTTP/3; this is distinct from the separate Header Accordions research.
Sources
When
Released 14 Oct 2026
Note
The circulating description of “three critical vulnerabilities” does not match this release: NGINX lists five medium-severity advisories. Its HTTP/3 issue is separate from Header Accordions.
tensorlake@0.5.144 was published to npm on Oct 8, 2026 carrying a Shai-Hulud-style credential-stealing worm with a destructive dead-man's switch ('hostage token'). The Register framed it as the Shai-Hulud worm's jump into AI infrastructure.
Sources
What happened
On October 7-8, 2026, someone pushed malicious commits directly to the main branch of the tensorlakeai/tensorlake repository under a maintainer's identity - no pull request - and the project's own release workflow published tensorlake 0.5.144 to npm on October 8 at 01:12 UTC. Because it shipped through the real pipeline, the package carries a valid npm provenance attestation; provenance records where a package was built, not whether the code is safe. The preinstall hook ran a credential-stealing worm in the style of Shai-Hulud that also tried to spread to other packages and repositories, and it installed a trap: a gh-token-monitor service that deletes the user's home directory if the stolen GitHub token is revoked. StepSecurity's automated package analyst flagged the release and reported it in GitHub issue 1014. The Register covered it as the Shai-Hulud worm's jump into AI infrastructure.
Exposed
Only npm tensorlake 0.5.144 (plus the matching tensorlake-native platform packages); it was live for about 1 hour 40 minutes (01:12 to 02:54 UTC on October 8). PyPI, crates.io and the CLI were not affected, and Tensorlake says it saw no usage of this version via user-agent monitoring. The hook skips CI, targeting developer machines: it harvested GitHub and npm tokens, cloud keys, Kubernetes and Vault secrets, SSH and GPG keys, .env files, browser-saved passwords, crypto wallets and AI tool configs (Claude, Cursor, Windsurf), exfiltrating to a public repo created in the victim's account with the description Shai-Hulud: Here We Go Again, or to iseekaigogo.com. It spread by republishing victims' npm packages and by committing .claude/settings.json and .vscode/tasks.json files into writable repos so it reruns when the project opens in Claude Code or VS Code.
Do this
The advisory marks 0.5.143 as the clean fallback for the affected npm release. If 0.5.144 ran, follow the vendor's platform-specific incident guide: remove the gh-token-monitor persistence BEFORE revoking a GitHub token, because failed token checks can trigger deletion of the home directory. Then rotate reachable secrets, check repositories and rebuild the machine if cleanliness cannot be established. This is not a general instruction to delay revocation on unaffected machines.
Still unknown
How the maintainer account was compromised is not established in the advisory. Because the worm republishes with stolen npm tokens, dependent packages could surface later; StepSecurity blocks known-bad versions at its registry proxy but the full downstream blast radius is not enumerable. No confirmed count of infected machines exists.
Confirmed 0.5.144 was published via a compromised maintainer account, disclosed the roughly 100-minute live window, said only npm was affected and no usage was observed, and documented the hostage token behavior with remove-before-revoke workarounds.
StepSecurity
Decoded the payload without running it, documented the theft set, self-spread mechanism and dead-man's switch, and published ordered remediation that removes the token monitor before any credential rotation.
The Register
Framed the compromise as the Shai-Hulud worm jumping into AI infrastructure.
GhostAction injected credential-stealing GitHub Actions workflows through compromised accounts. The October wave targeted over 30,000 repositories and attempted to extract 3,174 secrets. Those target/attempt counts are not confirmed theft totals; the earlier August-September wave had 26 confirmed stolen secrets.
Sources
What happened
GhostAction is a supply chain campaign that injects malicious GitHub Actions workflows into repositories using the victims' own compromised credentials, then harvests the secrets those workflows can reach. GitGuardian first revealed it in September 2025 (817 public repositories across 327 users, at least 3,325 secrets exfiltrated) and now says the campaign never stopped: it tracked activity through late 2025 and into 2026 with shifting exfiltration endpoints. A new wave ran from August 31 to September 30, 2026, pushing the workflow to 772 public repositories belonging to 373 users and organizations and targeting 2,577 secrets; GitHub held most runs for approval, so only 499 of 3,669 collected runs executed, exfiltrating 26 confirmed secrets from 13 repositories. Then between October 8 and 12 the campaign accelerated: more than 30,000 repositories across about 3,000 users and orgs were targeted through roughly 1,900 compromised GitHub accounts, attempting to extract 3,174 secrets. This time the workflows actually ran, and Socket confirmed successful exfiltration on October 8, before GitHub began blocking the malicious workflow from running on October 9, so the October 10 and 12 waves extracted nothing.
Exposed
Targeted secrets in the 2026 waves include SSH private keys and deployment credentials (446), Azure credentials (218, with one organization exposing an Azure PAT and SSH key across 92 repositories), container registry credentials (142), database credentials (112), AWS access keys (106), FTP credentials (92), Google Cloud and Firebase credentials (80), GitHub tokens (66), and bot tokens plus Cloudflare, npm, PyPI and AI provider keys. The October payload versions also grep the working tree and full git history, with special context capture around AWS key IDs, pointing at intent to hit private repositories too. Confirmed theft counts are much lower than target counts: 26 secrets confirmed exfiltrated in the August-September wave; the October wave's confirmed exfiltration is established by Socket's analysis but without a public total. Victims from earlier waves were hit again, suggesting reliance on unrotated secrets stolen months or years ago.
Do this
GitHub began preventing the malicious workflow from running starting October 9, which neutralized the later October waves. Cleanup is visible but incomplete: only 124 of 772 repositories in the August-September wave (16%) had removed the workflow in public history by October 5, and in 92 cases the attacker simply re-pointed old, never-removed workflows at the new endpoint. Affected users need to remove the injected workflow (names include github_actions_security.yml and security-audit.yml), rotate every secret referenced in their CI, and check for runs of the injected workflows. GitGuardian and StepSecurity published the exfiltration indicators, including the IP 193.32.204.199 and earlier endpoints.
Still unknown
Attribution is unknown. The full count of secrets stolen in the October wave has no public total. How the roughly 1,900 GitHub accounts were originally compromised is not established, though reuse of previously stolen credentials is the documented pattern. GitGuardian also found a cryptominer injected into kuafuai/DevOpsGPT by the same compromised account days before the new wave, but its analysis concludes the miner is probably a different actor exploiting the same stolen account - an illustration that stolen credentials do not have a single owner.
Responses
GitGuardian
Published the campaign history and the 2026 waves: 772 repositories and 2,577 targeted secrets in August-September, the October 8-12 burst targeting 30,000-plus repositories through about 1,900 compromised accounts, payload evolution toward git-history scanning, execution statistics, cleanup rates, and the DevOpsGPT cryptominer caveat.
GitGuardian (original disclosure, 2025)
Revealed GhostAction in September 2025: 817 repositories, 327 users, at least 3,325 secrets stolen via injected workflows.
StepSecurity
Tracked the October return and published indicators and remediation guidance.
BleepingComputer
Reported the original campaign's theft of 3,325 secrets.
When
Original wave Sept 2025; resurgence Aug 31-Sep 30, 2026; 30k+ repo burst Oct 8-12, 2026
Note
The 2025 and 2026 reports describe waves of the same campaign. Repository targeting figures do not equal successful compromises. See GitGuardian’s report for the effect of GitHub’s workflow blocking.
The @subql/common 5.8.3 npm release contained a credential-stealing payload, according to a public security report and maintainer response. It was published through the project’s release pipeline with npm provenance; provenance alone did not make it safe.
Sources
What happened
On October 5, 2026, StepSecurity's automated package analyst flagged @subql/common 5.8.3 on npm, and investigation confirmed a hidden credential-theft and backdoor payload. The release was published through the project's own npm trusted publisher (GitHub Actions OIDC) from a short-lived branch called chore/ci-audit-55: a canary publish (5.8.3-onf-rt1, no payload) at 11:24 UTC, then the payload-bearing 5.8.3 at 11:56 UTC, with the branch deleted around both operations. Because it flowed through the real pipeline, the release carries npm provenance, which records the build origin, not safety. StepSecurity opened GitHub issue 3047 in the SubQuery repository the same day. A maintainer (ianhe8x) responded on October 10 that the compromised token had been deleted and a review started.
Exposed
Version 5.8.3 adds a postinstall hook and an export so that even a plain import of @subql/common runs the payload; disabling install scripts alone is not enough. The 83 KB decoded bundle collects environment variables, gh auth token output, SSH keys, .npmrc files, cloud credentials (AWS, GCP, Azure), Kubernetes and Vault secrets, crypto wallets and AI-agent configs, sends them encrypted (RSA-OAEP plus AES-256-GCM) to ci-artifacts.dev, uses stolen GitHub tokens to push a secret-dumping workflow whose commit author is spoofed as github-advanced-security[bot], and installs a reverse-shell implant beaconing to the same host. StepSecurity's dependency review found 19 latest @subql package versions whose dependency ranges can resolve to 5.8.3, so pinning a parent package does not by itself protect downstream installs.
Do this
Treat 5.8.3 as unsafe: prevent installation and import, block ci-artifacts.dev, move back to 5.8.2, and investigate any machine or CI runner where 5.8.3 ran as compromised - rotate GitHub, npm, cloud, Kubernetes and Vault credentials and check repos for the spoofed dependabot branch and workflow. StepSecurity's suggested maintainer actions were to deprecate or unpublish 5.8.3, reset latest to 5.8.2, rotate the trusted-publisher configuration and all CI secrets, and publish an advisory; per the GitHub issue, the maintainers deleted the compromised token on October 10 and began their review. The release is catalogued as OSV MAL-2026-17571.
Still unknown
How the release pipeline or a commit feeding it was compromised is not established publicly. Whether the canary publish 5.8.3-onf-rt1 (dist-tag redteam, 32 minutes earlier, no payload) was an authorized test is unconfirmed. The number of affected downstream installs and whether SubQuery has completed its review are not public.
Responses
StepSecurity
Published the full analysis: temporary branch lifecycle, canary then payload publishes, decoded payload behavior, exfiltration endpoint, spoofed-commit secret-dumping workflow, reverse shell, dependency-path exposure across 19 packages, and remediation guidance.
SubQuery maintainer (ianhe8x) on GitHub issue 3047
Acknowledged the report on October 10, said the compromised token was deleted and a review of the security leak started.
Flatt Security research
Independent technical write-up of the @subql/common npm supply chain attack.
When
Malicious publish Oct 5, 2026 11:56 UTC; pulled within ~50 minutes
