All Articles

TL;DR for CISOs: A Texas Attorney General filing puts the 2025 Oracle Health (Cerner) breach at nearly 20 million people, a ransomware attack has taken a Japanese cloud region offline for hundreds of customers, an FBI takedown exposes the tooling behind China-linked intrusions, and Cisco shipped fixes for critical Nexus flaws.

Lead story: Oracle Health breach count reaches nearly 20 million people

What happened

A state regulator listing has now put a number on an incident that began in early 2025. The reported total is far larger than counts in earlier filings and patient notices, and Oracle has not commented on it publicly. If the figure holds, it would rank among the largest U.S. healthcare breaches on record, behind only a handful such as Change Healthcare in 2024.

The affected server was an older Cerner environment still awaiting migration. According to the reporting, the attacker did not need to defeat Oracle's cloud, only to log in with customer credentials on a system that was easier to reach. The stolen data was copied to a remote server, and the extortion was aimed at the hospitals themselves.

Evidence

Verified against independently fetched sources:
1. SecurityWeek, Oracle Health data breach tally climbs to nearly 20 million
2. eSecurity Planet, Texas AG says Oracle Health's 2025 breach affected 20M individuals
3. Techzine, Oracle medical data breach affected nearly 20 million people

What this means for your team

For a healthcare provider or any company that hands regulated data to a platform vendor, the lesson is about the part of the vendor estate you rarely see. A vendor can describe its flagship cloud as secure while your records sit on an older server with a different set of controls. Contract language and security questionnaires usually cover the first and say little about the second.

The notification timeline matters too. Customers were told in 2025, while the full scale surfaced in a state filing in 2026. Your own incident plan should assume you may learn the real size of a vendor breach from a regulator, not from the vendor.

Action checklist

1. Ask each critical healthcare or data-processing vendor in writing which systems holding your data are not on its current platform, and what authentication controls protect them.
2. Require MFA and credential rotation evidence for any vendor-hosted legacy environment, not only for the primary service.
3. Add a clause or procedure that obliges vendors to share affected-record counts and regulator filings with you as they are made.
4. Brief your fraud and support teams, since breach news is often followed by impersonation messages that cite the vendor.

Ransomware attack takes IDCF Cloud's East Japan region offline for 495 customers

What happened

The provider says the attack started in the early hours of October 7 and disabled part of its cloud service in eastern Japan. By midday October 8 the region was still isolated with no restoration date, and the company said it was checking for data leakage and auditing its other regions.

Reporting links the outage to government-facing sites in Ibaraki. BleepingComputer also notes a logistics firm, Nissui Logistics, reported a separate outage from suspected unauthorized access at a third-party data center, and says it is unclear whether the two are connected.

Evidence

Verified against independently fetched sources:
1. BleepingComputer, Ransomware attack disrupts Japan's IDCF Cloud used by govt clients
2. Tech Insider, Ransomware hits Japan IDCF Cloud, 495 clients down
3. ASCII.jp, IDC Frontier incident notice (translated edition)

What this means for your team

The risk here is concentration. Hundreds of organizations lost service because they shared one provider's region, and the provider's own response, shutting management consoles in every region, restricted what customers could do to help themselves. That is a sensible containment step and also a reminder that your recovery plan cannot assume you control the console.

Treat the attacker's numbers with caution. They are screenshots of a ransom message, and the provider has not confirmed them.

Action checklist

1. Map which business services run in a single cloud region, and record the recovery time you would accept if that region and its management console were unavailable.
2. Test whether you can restore critical workloads in a second region or provider using backups that the first provider's tooling cannot reach.
3. Ask your cloud and hosting providers how they would notify you, and what they would shut down, during a ransomware event on their side.
4. Add provider-side ransomware to your tabletop exercises, including a scenario where data theft is possible but unconfirmed.

FBI seizes seven domains tied to tools used against critical infrastructure

What happened

The seizure targets the supply side of the activity: the scanning and phishing tools rather than individual victims. The Department of Justice describes them as used to find and breach critical infrastructure in the U.S. and elsewhere, and the advisory covers government, healthcare, manufacturing and education among other sectors.

The advisory pairs the takedown with defensive guidance, including indicators of compromise, patching of exposed systems, closing unneeded services and enforcing multifactor authentication.

Evidence

Verified against independently fetched sources:
1. BleepingComputer, FBI disrupts Chinese hacking tools used to breach critical infrastructure
2. The Hacker News, FBI seizes 7 domains, disrupts Flax Typhoon tools used in critical infrastructure intrusions

What this means for your team

A takedown does not remove the access attackers already gained. Seized domains stop some command and control and scanning, but a foothold set up through an unpatched Struts server or a brute-forced Microsoft 365 account remains until someone finds it. For organizations in energy, healthcare, education and manufacturing, the useful step is a retrospective look, not only a block list.

The tooling description also shows how cheaply broad scanning scales. Assume your internet-facing services were probed, and ask whether you would have seen it.

Action checklist

1. Pull the indicators of compromise from advisory AA26-281A and search DNS, proxy, VPN and email logs for the full period you retain.
2. Check external-facing Struts, WebLogic, Jenkins and legacy VPN systems against the advisory's CVE list and retire or patch what remains.
3. Review Microsoft 365 sign-in logs for password-spraying patterns and confirm MFA covers every account, including service and shared mailboxes.
4. Look for SoftEther VPN software on endpoints and servers where it is not an approved tool.

Cisco patches critical Nexus NX-OS flaws, with five that allow root-level code execution

What happened

The Nexus flaws are reachable through crafted HTTP requests or network packets, depending on the feature, and most do not require credentials. Because the exposed features are optional, two organizations with identical hardware can have very different exposure.

SecurityWeek counts 14 NX-OS fixes in the release, seven of them critical, which is higher than the five BleepingComputer focuses on. Both agree on the five listed here, so use Cisco's own advisories for the full set.

Evidence

Verified against independently fetched sources:
1. BleepingComputer, Cisco warns of critical flaws allowing Nexus switch takeover
2. SecurityWeek, Cisco patches a dozen critical vulnerabilities

What this means for your team

Data center switches rarely get the patch urgency given to firewalls, yet they sit at the center of your network. With no exploitation reported, you have a short window. The Chinese-linked activity described above shows how quickly mass scanning follows public details.

The License product is a different kind of risk: a flaw with maximum severity in a tool many teams forget they run, and older versions will not be fixed at all.

Action checklist

1. Find every Nexus 3000 and 9000 switch in standalone mode and check whether NX-API, NGOAM or MPLS OAM is enabled.
2. Use Cisco's Software Checker to identify fixed releases, and schedule upgrades. Where that cannot happen soon, disable unused features or apply Live Protect.
3. Locate any Cisco License (Smart Software Manager) on-premises installs and plan the migration that older releases require.
4. Confirm management interfaces for these devices are not reachable from untrusted networks.

Also notable

• ASOS: The retailer now attributes its breach to social engineering in which an attacker impersonated a trusted contact to obtain an employee's credentials, then used them on third-party platforms. ASOS says names and contact details were exposed and that card data and passwords were not accessed. The number affected is undisclosed, and Snowflake told Silicon UK it has found no compromise of its platform so far. Sources: BleepingComputer and Silicon UK.
• Tensorlake npm package: Version 0.5.144 of the tensorlake SDK carried a credential-stealing, self-propagating worm tied to the Shai-Hulud campaign and has been removed from npm. Researchers say it targets cloud, GitHub, npm and AI-tool credentials, so any machine that installed it should rotate secrets. Source: The Hacker News (single source reviewed).
• Midnight Mimosa Android firmware: Low-cost Android phones shipped with residential proxy malware used for ad fraud and proxying. Source: BleepingComputer (single source reviewed).
• FakeGit campaign: 17,610 malicious GitHub repositories distributing SmartLoader and the StealC infostealer, per BleepingComputer. Source: BleepingComputer (single source reviewed).

Frequently asked questions

How many people did the Oracle Health breach affect?

A Texas Attorney General report, cited by Bloomberg and SecurityWeek, puts the total at nearly 20 million people. Oracle has not confirmed the figure. Texas alone lists 2,992,244 residents.

How did attackers get into Oracle Health's systems?

Reporting says attackers used stolen customer credentials to access a legacy Cerner server that had not yet moved to Oracle Cloud. Oracle says its cloud infrastructure was not compromised. How the credentials were obtained has not been disclosed.

What happened at IDCF Cloud?

IDC Frontier, a SoftBank subsidiary, reported unauthorized access on October 7 that took East Japan Region 1 offline. It attributed the outage to ransomware by a third party. It reports 495 affected companies and local governments, and has not given a restoration date.

What did the FBI do about Flax Typhoon tooling?

The FBI and Department of Justice seized seven domains tied to Integrity Technology Group, which U.S. authorities say built the MicroScan scanner and FishHub phishing tool. A joint advisory, AA26-281A, accompanies the action.

Are the Cisco Nexus vulnerabilities being exploited?

Cisco says it is not aware of malicious exploitation of the five critical NX-OS flaws, which were found in internal testing. Exposure depends on NX-API, NGOAM or MPLS OAM being enabled.

What should a CISO do first this week?

Ask critical vendors about legacy systems that hold your data, test recovery from a single-region cloud outage, search logs against advisory AA26-281A, and check which Nexus switches have optional features enabled.

Corrections and takedown requests: CISO Platform is committed to accuracy and fairness. If any detail in this briefing is inaccurate, or if you represent an affected organization and would like a correction or removal, please contact us at pritha.aash@cisoplatform.com and we will review your request promptly.