August 11, 2026. Three stories landed in my feed this week and they cover more ground than most quarterly threat reports do. A Canadian staffing agency lost 160 GB of data to a group calling itself Dark Project. A Winnipeg hospital had ransomware disrupt its doors, elevators, and ventilation systems. And JetBrains patched a deserialization bug in TeamCity On-Premises that lets an unauthenticated attacker run code on the build server.
None of these is a new category of attack. But together they show how far ransomware and supply chain risk have moved past the old encrypt files and demand Bitcoin model.
The Brainhunter data theft
On August 5, Dark Project claimed an attack on Brainhunter Companies LLC and Brainhunter Systems Ltd, a Canadian recruiting agency. The group says it took more than 160 GB of data, roughly 320,000 files, including banking documents and personal data of employees and customers.
Recruiting firms hold a specific mix of data. Resumes, background checks, payroll records, client contracts. That makes them useful targets for extortion, but it also makes them attractive to anyone looking for credentials or personal information to reuse elsewhere. Dark Project has not published a ransom demand on the site I saw, but the pattern is familiar: steal, threaten to leak, negotiate.
The interesting detail here is the file count. 320,000 files in 160 GB works out to about 500 KB per file on average. That suggests a mix of documents and databases, not just a dump of one email archive. For the victim, the damage is not just the leak. It is the uncertainty about what was taken and what will surface over the next year.
The hospital attack goes physical
The Health Sciences Centre in Winnipeg reported a ransomware incident that disrupted more than its file servers. Doors, elevators, heating, ventilation, and air conditioning all took a hit. Patient care continued, per the hospital statement, but the building itself became harder to operate.
This is the part that worries me. Hospitals have spent a decade connecting building management systems to the same network as clinical systems. It makes sense operationally. Facilities staff can monitor HVAC and access control from a central console. But that convergence means an attacker who gets into the IT network can reach the OT layer with a short lateral movement.
The Winnipeg incident is not the first of its kind. We have seen similar reports from other hospitals in recent years. What changes is the frequency and the explicit acknowledgment from the affected facility that building systems were disrupted. That acknowledgment matters because it forces other hospitals to audit their own OT exposure instead of assuming ransomware stays in the data layer.
The threat actors behind the HSC attack have not been identified. The investigation is still running. That is normal, but it means we do not know yet whether this was a double extortion play that went sideways or an intentional attempt to disrupt physical operations.
The TeamCity flaw that should scare anyone running CI/CD
JetBrains disclosed CVE-2026-63077 on July 27. It is a deserialization vulnerability in the agent polling protocol. An unauthenticated attacker sends a crafted message, the server deserializes it, and code runs with TeamCity server privileges. CVSS 9.8.
No authentication needed. Network reachability to the server is enough. If your TeamCity server is exposed on the internet or reachable from a compromised workstation, you are in scope.
CISA added it to the Known Exploited Vulnerabilities catalog on August 5 with a federal remediation deadline of August 8. That is a three-day window, which tells you how much confidence CISA has that attackers are already using it.
Fixed releases are TeamCity 2025.11.7 and 2026.1.3. For older branches, JetBrains shipped a security patch plugin going back to 2017.1. The plugin path works, but it is a bridge, not a destination. Upgrade to a fixed mainline release when you can.
Why does a CI/CD server flaw matter more than most RCEs? Because TeamCity holds credentials for source control, cloud providers, and deployment targets. An attacker with code execution on the server can read those secrets, modify build configurations, and inject malicious steps into pipelines. That is a supply chain attack in the making. The artifacts your pipelines produce are trusted by whatever consumes them. Poison the build and you poison everything downstream.
Hunting for exploitation is straightforward in theory: look for deserialization errors in agent polling logs, new agent registrations that do not match known hosts, unexpected Java child processes spawning shells, and outbound connections from the server to unfamiliar IP space. In practice, most teams have no baseline for what normal polling traffic looks like, so they cannot tell the difference. Start capturing that baseline now, before you need it.
What these three have in common
The Brainhunter incident is a data exfiltration story. The HSC incident is a physical disruption story. The TeamCity story is a supply chain story. But they share a thread: the perimeter is gone and the assets you protect keep changing shape.
For the staffing firm, the asset was client and employee data sitting in files. For the hospital, the asset was building infrastructure controlled by networked systems. For the TeamCity operator, the asset is the pipeline itself, the code it builds, and the credentials it uses. In all three cases, the attacker did not need a novel technique. They needed reachability and a lack of segmentation.
If I had to pick one takeaway for a technical audience, it is this: inventory what your systems can reach, then cut that graph down. Hospitals should have building management on a separate VLAN with no path to clinical IT. CI/CD servers should sit behind a VPN or bastion, not on a public endpoint. Staffing firms, and honestly every company, should assume that any networked system holding personal data will eventually be reached and plan for the exfiltration, not just the intrusion.
The other takeaway is operational. CISA gave federal agencies three days to patch TeamCity. Private companies often take weeks to apply critical patches because of change windows and fear of breaking builds. I am not going to tell you to ignore change management. I am going to tell you that a 9.8 unauthenticated RCE in a system that holds your signing keys is the kind of thing that justifies an emergency change window, even on a Tuesday.
None of this is new advice. Segmentation, patch hygiene, and asset inventory have been the boring top three for a decade. The difference is that the blast radius has grown. A deserialization bug in a build server is now a supply chain incident. A ransomware hit on a hospital is now a physical safety incident. The boring advice finally has teeth.