Weekly Cybersecurity Intelligence Report: Cyber Threats and Breaches 19 Oct to 25 Oct 2026

Overview: On 21 October 2026, attackers published a malicious 1.107.0 release of LiteLLM, the open-source LLM gateway, to PyPI and Docker Hub using a publishing key that had been committed to a public repository on 27 May 2026. It is the second LiteLLM supply chain compromise in seven months.

Impact: Seven malicious PyPI wheels were published between 11:39:51 and 11:40:13 UTC and stayed live until 13:23 UTC; four Docker tags were live from 11:46:56 to 14:20 UTC. The package draws roughly 23 million downloads a week. Anyone who installed or pulled 1.107.0 in those windows should assume every credential reachable from that host is compromised. LiteLLM has not published a count of affected installs.

Details: The release added a cook.pth file, which Python executes automatically at interpreter startup, loading cook.py and writing a sitecustomize.py for persistence. The payload, tracked as privcollect, harvested cloud credentials, LLM provider API keys from environment variables and config files, SSH keys and tokens, encrypted them and sent them to an attacker-controlled litellm[.]dev endpoint. Researchers also found a second-stage remote access component, so this is a persistence problem and not only a credential-theft one. Wiz observed the stolen credentials being checked with sts:GetCallerIdentity, then bedrock:ListFoundationModels, then a ListModels call, a pattern it describes as consistent with LLMjacking. The key had been valid for 147 days between exposure and use. LiteLLM yanked the release and rolled back to 1.106.2. No threat actor has been named, and the original access vector is still being traced.

1Search build logs and image registries for litellm 1.107.0, and treat any host that ran it as compromised rather than merely exposed, given the second-stage component.

2Rotate every credential reachable from those hosts, prioritising cloud keys and LLM provider keys, and check provider billing for unexplained inference usage.

3Scan your own repositories for committed publishing tokens, and set expiry on every package registry credential, because this one stayed valid for 147 days after it was exposed.

CISO takeaway: This is the second compromise of the same package in seven months, which turns the question from how to respond into whether this dependency has earned its place in your build. An AI gateway sits where every model credential in the organisation passes through, so it is the single highest-value package in an AI stack to poison, and the attacker knew it.

Overview: The cloud platform Railway disclosed that an attacker accessed its internal systems and decrypted customer environment variables, and told customers to rotate every secret stored on the platform. Railway became aware of a sustained, targeted campaign at 19:53 UTC on 20 October 2026 and confirmed the attacker’s access was removed at 03:32 UTC on 22 October 2026.

Impact: Railway states that at most 1.85 percent of all workspaces were affected, which it puts at about 100,000 workspaces. Individual user accounts were not logged into, and running services stayed online throughout. Railway has not ruled out that the attacker accessed customer source code.

Details: The attacker obtained CI credentials and used them to decrypt artifacts holding further API access, then decrypted environment variables. Railway’s assessment is that the actor was hunting AI provider API keys, targeting workspaces with many variables or many AI keys, with the apparent goal of running distillation attacks against inference providers. Railway worked with upstream providers including GitHub, GitLab, Anthropic, OpenAI, OpenRouter and Stripe to revoke keys it had stored.

1Rotate every secret held in Railway environment variables, not only the AI keys, and do not wait for individual notification.

2Review AI provider billing and usage dashboards for inference you did not run, since that is what the keys were wanted for.

3Move long-lived provider keys out of platform environment variables into a secrets manager with short-lived credentials, so a platform compromise does not hand over everything at once.

CISO takeaway: Encryption at rest did not help here, because the attacker took the path that decrypts: CI credentials, then the keys that protect the data. The selection logic is the part worth noting, because the attacker filtered for workspaces rich in AI keys. Your model credentials are now a target category in their own right, with their own resale value, and they are usually stored with less care than a database password.

Overview: Navigate360, which operates the P3 anonymous tip platform used by Crime Stoppers programs and school safety services, disclosed that an attacker used a stolen customer login to access its systems. Nevada states the unauthorised access ran from 21 November 2025 to 5 March 2026, and Navigate360 issued its notice on 23 October 2026.

Impact: Toronto Crime Stoppers reported 176,859 affected tips, of which 12,392 potentially contained personal information, including 14,973 names. Nevada’s SafeVoice program reported that about 10 percent of its tips contained personal information. The wider scope is larger: CBC, working with data obtained through Distributed Denial of Secrets, reported more than 1.5 million Canadian tips exposed, with personal information in at least half of those it examined, and Nevada’s Department of Education FAQ cites media estimates of 8.3 million records across Navigate360 systems in the breach period. Navigate360’s notice lists names, addresses, dates of birth, Social Security numbers, phone numbers and email addresses among the data that could be involved, and says it has no evidence the information has been used for fraud or identity theft.

Details: The initial access was through a stolen login belonging to a US-based Crime Stoppers program, from which the attacker reached data belonging to other customers. Toronto’s published timeline is the part worth reading closely: Navigate360 told the program on 25 March 2026 that P3 was accessed but safe and fully operational, on 9 April that some Canadian programs’ data had been taken but not Toronto’s, and only on 9 June that Toronto’s tips from January 2022 to November 2025 were affected. Toronto has suspended accepting tips. The Privacy Commissioner of Canada has opened an investigation into Navigate360, and Nevada’s Department of Education has issued a request for information to assess alternative vendors.

1For any multi-tenant platform you run or buy, verify that one customer’s credentials cannot reach another customer’s records, and ask the vendor to show you the control rather than describe it.

2Write into vendor contracts that the supplier must provide a per-customer record count within a fixed number of days, because seven months passed here between access and a usable list.

3Where a service promises anonymity, assume free-text fields contain identifying detail anyway, and set retention and redaction accordingly.

CISO takeaway: Sean Sportun, chair of Toronto Crime Stoppers, put the core problem plainly: the program never asks for a name and does not want one, but people include details to explain what they saw, and it was those tips that were stolen. The product here was anonymity, and the breach destroyed the product rather than merely exposing data. The vendor also told its customer twice that its data was unaffected before reversing, which is the part to carry into your own supplier reviews: a vendor’s early all-clear is not a finding.

Overview: Quest Diagnostics filed an 8-K on 22 October 2026 disclosing unauthorised access to Quanum Lab Services Manager, a platform clinicians use to order tests and retrieve results, and said it believes patient health and identifiable information was part of the access.

Impact: Quest paused access to Quanum Lab Services Manager and, as a precaution, to Essential Insights and LabHQ, moving clients to Quanum eLabs or paper requisitions. By the evening of 23 October Quest said it had terminated the unauthorised access, contained the incident and restored the platform for clients. Quest has not published a count of affected patients, and no group had publicly claimed the attack as of 25 October 2026.

Details: The filing is under Item 8.01 rather than Item 1.05, meaning Quest has not determined the incident to be material for SEC purposes, which is a judgement that can change once the patient count is known. Quest has not disclosed the entry point or a threat actor. For scale, the incident is unlikely to approach the 2019 AMCA breach, which exposed data on 11.9 million Quest patients, because only a subset of clients use Lab Services Manager.

1If you are a healthcare provider using Quanum, record which staff accounts had access and over what period, since the notification will come to you to pass on to patients.

2Test the manual fallback for clinical ordering before you need it, because the containment here took three platforms offline at once.

3Decide now, with legal, what triggers an Item 1.05 filing in your own organisation, rather than deciding it during an incident.

CISO takeaway: Quest contained and restored within about 48 hours of filing, which is the part worth copying. The open question is scope, and the gap between “we believe patient information was accessed” and a number is where regulatory and patient-notification obligations live. A clinician-facing ordering platform is a quiet single point of failure in a provider’s workflow, and a precautionary pause takes the clinical process with it.

Overview: The Everest extortion group listed PwC on its leak site on 22 October 2026, claiming 590GB of data and setting a countdown to 28 October. PwC confirmed on 23 October that a third-party platform it uses was involved.

Impact: PwC states that no client data, sensitive personal data or financial information was involved, and that its own network and operations were unaffected. Everest’s listing is said to contain 108,426 files, with one HR dataset reportedly holding 213,084 records, covering PwC operations in Australia, China, Canada and the UK. No count of affected employees has been published, and the volume claim is Everest’s own and unverified.

Details: PwC has not named the vendor, though the leak listing includes a directory named pwc-stg.csod.com, which points at a Cornerstone OnDemand learning platform and specifically at a staging instance. Everest has been running data-theft extortion without encryption, and no ransomware deployment or ransom note has been established in this case. The data described is employee learning and HR records rather than client engagement material.

1Inventory every SaaS platform that holds employee HR, learning or performance data, and include staging and test instances, which are often populated with production data and protected less well.

2Prepare employee communications for a vendor breach in advance, since staff learn about these from a leak site rather than from HR.

3Check what a vendor’s non-production environments contain, and require that they hold synthetic data rather than copies of the live HR database.

CISO takeaway: A firm whose business is advising others on risk had employee data taken through a platform it does not run, and the public evidence points at a staging instance rather than production. Nobody’s third-party register is better than the attention paid to the least interesting system on it, and the learning management platform is usually at the bottom of that list.

Overview: On 23 October 2026, City Manager Teresa Wilson confirmed that the City of Columbia, South Carolina is the victim of a ransomware attack, discovered on 20 October 2026.

Impact: MyColaSC, Animal Services online services, Parks and Recreation reservations, business licensing, planning and development services, and GIS were taken offline. Police, Columbia-Richland Fire, 911, Columbia Water and the Payment Center, including online payments, stayed operational. The city has not given a restoration date.

Details: The South Carolina Law Enforcement Division is leading the criminal investigation and may work with the FBI. The city says the incident involved sensitive data within its network and that it is still assessing what information, if any, was accessed. No ransomware group has claimed the attack, and no ransom demand has been disclosed.

1Map which citizen-facing or customer-facing systems can be isolated without stopping emergency or revenue-critical operations, and document it before an incident forces the choice.

2Confirm that payment and emergency systems are segmented from the general network, which is what held here.

3Agree in advance who speaks publicly and how often, since a multi-day outage with no restoration date is managed through communication as much as through recovery.

CISO takeaway: The segmentation worked where it mattered: 911, fire, police, water and payments all stayed up while the convenience layer went down. That is a design decision made years before the attack, not a response to it, and it is the difference between a public inconvenience and a public emergency.

Overview: Microsoft attributed last week’s ConnectWise Cloud Backup OAuth compromise to Storm-0940, and reported that the actor used ARTEX, an agentic AI penetration-testing framework, to drive the campaign.

Impact: Microsoft reports attempted sign-ins to more than 2,250 Microsoft 365 tenants, at rates reaching roughly 2,900 attempts a minute, with several intrusions moving from first targeting to privileged cloud access in under three hours. Attempted sign-ins are not compromises, and the count of successful accesses remains the lower figure Huntress reported last week.

Details: ARTEX is the same open-source, LLM-based penetration-testing agent that CrowdStrike tied to intrusions at South Korean financial institutions in early October 2026, when a single operator ran it against seven banks. Sophos found the sweep also reached tenants with no active ConnectWise backup subscription, because the OAuth consent outlived the subscription, and Huntress has warned that credentials planted during the campaign survive disabling the application.

1Review consented OAuth applications even for services you no longer subscribe to, since cancelling a subscription does not revoke the consent.

2After disabling a compromised application, hunt for credentials and directory roles it added, because removing the app does not remove what it created.

3Set detection thresholds for service principal sign-in volume, since human-paced baselines will not fire on 2,900 attempts a minute across thousands of tenants.

CISO takeaway: Three weeks ago ARTEX was one operator against seven Korean banks. It is now attributed by Microsoft to a state-aligned actor sweeping thousands of tenants at machine speed. The tool did not change; the scale did. Response processes built around an attacker who takes days to move laterally do not fit an adversary that reaches privileged cloud access in under three hours.