Daily Cyber Threat Brief — October 24, 2026: Capcom confirms breach of 11.7 million CAPCOM ID accounts

The headline number is large, but the composition of the data is what sets the risk. Email addresses paired with last-login timestamps, login counts and last-login IP addresses are a ready-made targeting list: an attacker who knows when an account was last used, and from where, can craft lures that look like genuine Capcom security notices. The 196 accounts whose passwords were changed show the intruders were not just copying data — they were testing control over accounts.

What Capcom has not said matters as much as what it has. The company says it identified the intrusion method and put countermeasures in place, but it has shared no details on initial access, no dwell time, and no attacker attribution. Until that changes, treat the "passwords not exposed" line as a status report, not a final verdict: the investigation is still open, and the exposure window before October 19 is unknown.

For account holders, the practical steps are narrow and concrete: ignore unsolicited messages claiming to be Capcom, sign in only by navigating to Capcom directly, and change the password anywhere it was reused. Capcom says its online services are unaffected, so there is no service outage to wait out — the exposure is already in the wild.

On October 21, attackers used stolen GitHub CLI OAuth tokens from three LiteLLM engineers' accounts to run the project's release workflow against a lookalike repository — Berri-AI/litellm, one hyphen away from the legitimate fork — and publish version 1.107.0. One token launched the pipeline, a second approved it, a third deleted the workflow records. LiteLLM believes the tokens were lifted from logs in an internet-exposed internal deployment, possibly via a recently patched vulnerability, but has not confirmed the initial access route.

The malicious build carried compiled malware that steals credentials — cloud logins, developer secrets, AI service keys, browser passwords and LiteLLM proxy database contents — and loads remote-code execution tooling. All seven PyPI wheels were live from 11:39 to 13:23 UTC; Docker Hub and GHCR tags (v1.107.0, latest, main-latest, main-stable) served the tainted images from 11:46 UTC, with GHCR pulled by 13:51 UTC and Docker Hub repointed by 14:20 UTC. The window was short, but LiteLLM is a massively popular project — 92 million monthly PyPI downloads — and Wiz researchers report stolen AWS credentials were tested against Amazon Bedrock within hours.

The remediation is unforgiving: anyone who installed 1.107.0 or pulled those tags on October 21 should treat the host as compromised, pin the last safe version (1.106.2), rebuild from a clean image, and rotate every secret the process could read. This is LiteLLM's second supply-chain compromise of 2026; the earlier one, affecting versions 1.82.7 and 1.82.8, was linked by Datadog to TeamPCP activity, with no connection established to this incident.

Arista's October 22 advisory (0199) discloses CVE-2026-114625, a SQL injection in on-prem VeloCloud Orchestrator rated CVSS 9.9, and confirms it is being actively exploited. The bar is strikingly low: an attacker needs only network access to the orchestrator's web interface and a valid login — and the lowest built-in customer role, Enterprise Read Only, is enough. From there, the flaw escalates to operator privileges and impersonation of a local superuser account, with potential impact on the orchestrator host and the data it manages.

Arista published two IP addresses seen in attacks — 74.82.197.86 and 38.54.50.151 — and advises blocking them, hunting web, application, system and database logs, and restricting the web interface to trusted admin networks until patched. Fixed on-prem builds are 5.2.3.18, 6.1.3.10 and 6.4.2.12; hosted and dedicated deployments are already patched. Edge and gateway devices are not affected.

The pattern is the story: this is the third VeloCloud Orchestrator flaw reported as exploited in about four months, and the first of the three that requires a login rather than none at all. Patching alone does not evict an attacker who already escalated — operators should verify post-patch for lingering compromise, not just a version number.

HPE's October 23 bulletin (HPESBNW05162) patches 72 vulnerabilities across AOS-8 and AOS-10, the operating systems behind its enterprise wireless gear — mobility conductors, controllers, gateways and access points. Eight flaws carry maximum-severity ratings (CVSS 10.0, CVE-2026-79844 through CVE-2026-79851): authentication bypass, command injection, SQL injection and buffer overflows that let remote, unauthenticated attackers run code on the host, with no privileges and no user interaction required.

HPE says it has found no public exploit code and no evidence of in-the-wild exploitation as of the advisory date — but with eight unauthenticated paths to full takeover now public, that window is unlikely to stay shut. Fixed builds are AOS-10.8.1.2, 10.7.2.7 and 10.4.1.14, and AOS-8.13.3.1 and 8.10.0.24. Until patched, HPE urges restricting CLI and web management interfaces to trusted networks. Note the scope trap: this bulletin covers AOS-8 and AOS-10 only, not AOS-CX, HPE's switch operating system.

Quest Diagnostics discovered unauthorized activity on October 21 on Quanum Lab Services Manager, the platform healthcare organizations use to manage laboratory orders and results. In an SEC filing on October 22, Quest said certain patient records were believed to have been accessed, and it temporarily paused access to the affected system while investigating. No patient count and no data categories have been disclosed yet, and the intrusion's start date is unknown.

Quest says core operations have not been materially disrupted; affected healthcare customers were directed to alternative ordering and results-access methods, including paper forms and Quanum eLabs. As a precaution Quest also temporarily paused Essential Insights and LabHQ, though it says no data was accessed in those systems, and it says there is no more unauthorized access to Quanum LSM. Its patient notice confirms personal information and patient records were affected, with specific data types still under investigation. The incident is a reminder of how much patient data flows through vendor platforms rather than the provider itself — and that breach notification here will come through Quest and the affected providers, not a single announcement. Patients and clinics should watch for direct vendor communications rather than public tallies.