Three incidents this week, and in each one the response cost something. Quest Diagnostics paused the portal that doctors’ offices use to order tests and read results, and sent clients back to paper. A school district in Jerome, Idaho cut its own network to stop ransomware, and the cameras, door locks, heating and phones went down with it. India’s largest bank, State Bank of India, had no system to pause at all: it learned from outside parties that a dataset with its customers’ details was already circulating on a criminal forum.

This week: The shared theme is what containment costs. Stopping an attack means switching something off, and the thing switched off is often the thing people depend on most. In two of these cases the defender chose to take the hit. In the third, the data was already out, and the choice was never offered.

Quest Diagnostics Pauses Its Lab Ordering Portal After Unauthorized Access to Patient Records

What happened: On October 21, 2026, Quest Diagnostics learned of unauthorized access to Quanum Lab Services Manager (LSM), a system that certain clients use to place test orders and to receive and look up results. In a Securities and Exchange Commission filing dated October 22, Quest said it believes an unauthorized party accessed certain patient records, and that the incident has not materially disrupted its business or its ability to serve patients. Quest paused access to the portal, told clients to use paper requisitions, and said it expected to have the system back by Friday, October 23. It has notified federal law enforcement and brought in outside investigators.

Technical details that matter:

• Initial access is undisclosed. Quest stated that the incident did not involve the PHP vulnerabilities that were drawing attention that week, per The Record. That rules out one widely discussed path and says nothing about what the path was.
• The affected system is a client-facing portal that combines order entry and result lookup. Quest has not said which records were accessed, how many patients are involved, or which data fields were exposed.
• Inference, not reporting: a portal used by many provider clients gives an attacker one door to many practices’ patients. Whether access came through stolen client credentials, an application flaw, or session abuse would decide whether the exposure is per client or system-wide. Quest has not said.
• No group had claimed the incident as of October 22 to 23, per The Record. A Quest spokesperson declined to describe the nature of the attack.
• Containment was a deliberate pause of the portal, plus a precautionary pause of several other systems. Quest said no other part of the company was affected.
• Persistence, dwell time, and exfiltration methods are not public.

Why critical institutions should care: Quest says it serves about half of U.S. doctors and hospitals. A portal at that scale sits between thousands of provider organizations and their patients, so a compromise there reaches institutions that never hired the attacker’s target and may not learn whose records were involved until Quest tells them. The one-day paper fallback worked, which is the useful lesson. The open question is the data: which patients, which fields, and who notifies whom.

Key sources:

• Form 8-K, Item 8.01 (Quest Diagnostics, via SEC)
• Quest Diagnostics warns of potential data theft after attack on lab service system (The Record)
• If you used Quest Diagnostics, your data may have been compromised (KTVU, citing Reuters and AP)
• Quest Diagnostics Discloses Cybersecurity Breach (MD+DI)

SBI Confirms 3,897 Customer Records in a Dark Web Dataset, Source Unknown

What happened: On October 16, 2026, State Bank of India was alerted by its threat intelligence provider, CERT-In (India’s national computer emergency response team), and the Defence Cyber Agency to a dataset of about 375,000 records on the dark web. In a stock exchange filing dated October 21, SBI said its preliminary analysis found 3,897 customer records containing personal information, that it had hired an independent auditor from CERT-In’s approved panel, and that core operations were unaffected. SBI said it does not yet know where the data came from. Secondary outlets report that the bank notified identified customers by email and WhatsApp by October 23.

Technical details that matter:

• The filing lists registered mobile numbers, dates of birth, names, gender, email addresses, residential addresses, branch and customer information file identifiers, lead IDs, and metadata tied to loan and lead records. The Hacker News notes that account numbers, balances, passwords, one-time passcodes, card details, and national ID numbers are not among the listed categories.
• The attacker claim: a handle called Siriusim listed 375,000 CSV rows and 2,722 PDF documents on BreachForums, said to include loan applications, account-opening forms, and addresses. That comes from a monitoring account on X, relayed by The Hacker News. The Free Press Journal checked four sample records and found valid phone numbers. That verifies four records, not the set.
• SBI’s filing does not tie its analysis to the listing, and it does not say whether the PDFs were examined. The 3,897 confirmed records are about 1 percent of what the bank reviewed, so either most of the dataset is not SBI customer data or the review is incomplete.
• Whose data this is remains open. The samples were mostly loan-related with identity-verification fields, and did not show whether the data belongs to SBI, a subsidiary, or a third-party provider that handles applications. Inference, not reporting: lead IDs and loan metadata point toward a sales or loan-origination system rather than core banking.
• Initial access, persistence, and exfiltration are unknown. The filing names no preliminary cause.

Why critical institutions should care: The bank learned of this from outsiders, on October 16, and filed with investors on October 21. The filing described impact on the bank’s business, not on customers, and it did not say whether customers would be told. Civil-society groups pressed the point publicly before the customer notices went out. For any financial institution, the order of disclosure is a decision to make before an incident: investors, regulators, and customers will each judge you on when they heard. The exposed fields also do not need core banking to be useful. A caller who knows your name, mobile number, branch, and loan details sounds like the bank.

Key sources:

• State Bank of India Confirms Data Leak After 3,897 Customer Records Found on Dark Web (The Hacker News)
• Incident Involving Data Loss, stock exchange filing (SBI, via NSE)
• SBI told investors its data breach doesn’t matter. What about the 3,897 customers it affected? (Internet Freedom Foundation)
• SBI identifies 3,897 customer records in dark web data exposure, launches investigation (The Tribune)

Jerome School District Closes Schools After Ransomware Reaches Building Systems

What happened: On Saturday, October 17, 2026, a ransomware attack began in the pre-dawn hours against the Jerome School District in Idaho, which serves about 4,000 students across eight schools. The district shut down its network to contain the attack. That took cameras, door locks, heating and cooling, and phones offline, and schools were closed on Monday, October 19 and Tuesday, October 20. Classes resumed Wednesday, October 21. The attackers demanded a ransom and threatened to expose data. The district has not paid.

Technical details that matter:

• Two accounts of the building systems exist, and they differ. First-week local coverage and Cybernews said hackers took control of cameras, door locks, and climate controls. The superintendent later told Idaho Education News that those systems were shut down as part of isolating the network. The reporting I could verify supports the second: the building systems depend on the same network, and cutting it took them out. It does not show attackers operating the locks or the HVAC.
• Detection: the district’s security systems alerted staff, ransomware notices arrived, and technology staff worked through the weekend.
• Extortion: the superintendent said the attackers wanted data to ransom. The forensic review is ongoing. Student devices were unaffected, but data on some of the district’s roughly 500 staff devices may have been accessed.
• The actor is unnamed. The superintendent declined to name the group and said federal law enforcement knows it. CISA provided mitigation experts. The amount demanded is undisclosed. The superintendent said it was far beyond the district’s insurance coverage and that communications were broken off.
• Initial access is unknown. The district’s pre-attack safeguards were not disclosed on legal advice.
• Inference, not reporting: when locks, cameras, climate control, and phones share a network with office IT, cutting that network is the correct containment step and also becomes a safety event.

Why critical institutions should care: This is the operational technology question in a small setting. The people who had to decide whether to close schools were weighing student safety against the cost of keeping a compromised network up, and the decision was forced by how the building was wired. Any institution that runs access control, surveillance, or environmental controls on shared infrastructure has the same exposure: hospitals, utilities, offices. The insurance gap matters too. The ransom demanded was beyond the district’s coverage, so the decision not to pay was also a financial one.

Key sources:

• Jerome schools closed again Tuesday after weekend cyber attack (KMVT)
• ‘This is a terrorist crime’: Jerome superintendent shares details on ransomware attack (Idaho Education News)
• Hackers take control of school cameras, locks, and HVAC, shutting down entire Idaho school district (Cybernews)
• Jerome schools closed Monday after weekend cyber attack (KIVI)

The Pattern this Week

Quest chose to pause its portal and absorb a day of paper orders. Jerome chose to cut its network and absorb two days without school. Both paid a visible price to stop the spread, and both were able to pay it because they found the problem while it was still happening. SBI never had that option. By the time the bank heard about the dataset, there was nothing left to switch off, and the work became deciding what to say and to whom.

One more incident belongs in the same conversation, though it sits outside our four sectors. On October 21, LiteLLM’s release pipeline was used to publish a malicious version 1.107.0 of its AI gateway software to PyPI and Docker registries, live on PyPI from 11:39 to 13:23 UTC, carrying a credential stealer and a backdoor that run whenever Python starts. Its root cause was not known inside this window, and the attacker’s window was under two hours.

That is the defender’s problem. Containment decisions have to be made before anyone knows what a system holds, what else runs on it, or whether the data has already left. The systems that matter most to your operations are often the ones the decision takes down, and the incidents with no off switch arrive as a phone call from someone else.

What Your Business Can Do This Week

1. Find the outside portals you depend on (Quest). Ask which vendor portals your staff use to order or retrieve sensitive results, what the paper fallback is, and how the vendor would tell you whose records were involved if something went wrong.
2. Decide your disclosure order before you need it (SBI). Ask your leadership team who would tell customers, who would tell investors and regulators, and in what order, if a dataset with your customers’ details appeared on a forum tomorrow. Agree it in writing now.
3. Ask what shares a network with your building controls (Jerome). Have your facilities and security leads tell you whether door locks, cameras, and heating and cooling run on the same network as office computers, and who is authorized to order a shutdown if IT must cut the network.
4. Ask whether anyone used LiteLLM on October 21 (The Pattern). Ask your technology leader whether any team installed or ran version 1.107.0 of the LiteLLM AI gateway tool that day. If so, treat the passwords and keys on those machines as exposed and replace them.

See you next week!