Google Just Patched Its Sixth Actively Exploited Chrome Zero-Day This Year, and a Breach at a Court Records Vendor Just Exposed Sealed Case Files Across 11 States

Start with the update you should apply today, not this week: Google shipped an emergency Chrome release fixing 12 vulnerabilities, one of which — CVE-2026-85046, a type confusion flaw in the V8 JavaScript and WebAssembly engine — is already being exploited in the wild. Google's advisory confirms an exploit for the flaw exists, and as is standard practice for actively exploited bugs, the company is withholding technical details until the patch has had time to reach most users. The mechanism itself is straightforward to understand even without those details: type confusion happens when V8 gets tricked into treating one kind of object in memory as if it were a different kind entirely, corrupting the assumptions Chrome relies on when reading and writing that memory. A specially crafted HTML page — reached through a phishing link, a malicious ad, or a legitimate site that's been compromised — can trigger that confusion and gain the ability to execute attacker-controlled code inside Chrome's sandboxed renderer process, the contained environment each tab runs in specifically so a compromised page can't immediately reach the rest of your system.

That sandbox boundary is worth understanding precisely, because it's both the good news and the reason this still matters urgently. CVE-2026-85046 alone gives an attacker code execution inside the sandbox, not automatic control of the underlying operating system — reaching further would normally require chaining this bug with a separate sandbox-escape or privilege-escalation flaw. But "contained to the sandbox" still means an attacker can potentially access whatever that browser tab can access: session cookies, saved credentials, whatever the user is logged into at the moment of compromise, and a foothold that's valuable enough on its own even without a full system takeover, and a genuine step toward one if paired with something else. The researcher who reported it, Salvatore Gulizia, was awarded a $1,000 bug bounty for responsible disclosure — a useful reminder that the people finding these flaws before wider criminal discovery are frequently working through exactly this kind of unglamorous, modestly-compensated process. The fix lands in Chrome 152.0.7977.82 and .83 across Windows, macOS, and Linux, rolling out gradually; since Chrome updates in the background but only takes effect after a restart, the practical action today is closing and reopening your browser, not just trusting that an update happened silently. This is the sixth actively exploited Chrome zero-day Google has patched so far this year, following a similar V8 flaw fixed back in June — a cadence worth internalizing if your organization treats browser updates as a routine, deprioritized patch rather than the same urgency tier as any other actively-exploited vulnerability, because at six incidents in under nine months, "the browser" has become one of the most consistently targeted pieces of software most people touch every day. This isn't a US-only concern by any measure — the Netherlands' National Cyber Security Centre has independently logged its own advisory tracking CVE-2026-85046, a reminder that a flaw in software running on billions of devices worldwide draws attention from national cybersecurity authorities well beyond wherever the vendor happens to be headquartered.

The second story of the day is a different kind of urgent — not a fresh technical exploit, but a slow-moving disclosure that surfaces months after the fact and lands somewhere most people never think to worry about: the software running behind their own court system. Thomson Reuters disclosed that its West Publishing unit detected unauthorized activity in one of its cloud environments on June 30, and a subsequent investigation determined the actual intrusion had happened months earlier, in March — meaning the exposure window ran considerably longer than the time it took to even notice it. The affected system is C-Track, a court case management platform used by judiciaries to handle filings, dockets, hearing schedules, and case workflows, with confidentiality markings specifically meant to restrict sensitive case information to authorized personnel only. The breach touched court systems in eleven U.S. states — Alabama, Pennsylvania, Kentucky, Montana, Nevada, North Dakota, South Carolina, Tennessee, Ohio, New Hampshire, and Wyoming — plus the U.S. Virgin Islands and three courts in Ontario, Canada, whose chief justices issued a joint statement alongside the company's own disclosure.

The specific category of data exposed is what elevates this well past a routine vendor breach. West Publishing's notice states that affected court records could contain names, Social Security numbers, driver's license numbers, dates of birth, medical information, and health insurance information — and, notably, that certain confidential, redacted, or sealed information may have been affected at some courts specifically. That last detail is the one worth sitting with: sealed and redacted court records exist because a judge specifically determined that information needed protection beyond ordinary public access — cases involving minors, victims of violence, sensitive medical or psychiatric history entered into evidence, or matters a court deliberately restricted from public view for reasons a judge found compelling enough to override the default presumption of open records. A breach that reaches that category isn't just another exposed-SSN incident; it's a breach of the specific privacy protections a court system built for people it had already identified as needing extra protection. Thomson Reuters says its investigation found no evidence to date of resulting fraud or misuse, that C-Track itself experienced no operational disruption, and that independent cybersecurity experts validated the remediation measures put in place — genuinely reassuring signals, though "no evidence yet" a full investigation into exactly what was taken and how many people are affected is still ongoing, months after the original intrusion.

There's a structural point worth naming plainly, because it's a pattern that shows up across a lot of the biggest breaches this year and this one is a particularly clean example of it: the people whose Social Security numbers and sealed medical records may now be exposed never chose to give Thomson Reuters their data, never signed a privacy policy with West Publishing, and in most cases have no idea a company by that name was ever involved in their case at all. They were parties to a court proceeding, and the court's own case-management software happened to be built and hosted by a third-party vendor. This is exactly the third-party data liability risk that keeps showing up as one of the most common categories in cyber insurance claims — an organization's actual data-protection obligations extend well past the people who directly interact with it, into every vendor relationship where someone else's customers, patients, or in this case litigants end up as collateral exposure in a breach they had no way to see coming or prevent. If your organization handles sensitive data through any third-party case-management, records, or workflow platform — legal, healthcare, HR, or otherwise — this is a reasonable prompt to ask a very specific question: does that vendor's own security posture actually match the sensitivity of what you're trusting them to hold, or have you simply assumed it does because they're a large, established name.

Two stories, different scales and different mechanisms, but the same honest throughline underneath both: trust extended further than direct visibility could confirm it deserved. Chrome users trust that the browser running on three billion devices is safe to point at an ordinary webpage — mostly true, undermined six separate times this year by flaws serious enough to already be under active attack before the fix existed. Court litigants trusted a judicial system that, in turn, trusted a vendor they never chose and never audited themselves. Neither trust was unreasonable to extend in the first place. Both are worth checking on today rather than assuming they're still holding.

One more story worth closing on, since it's a genuine escalation of something this site has been tracking rather than a one-off. The pro-Russian hacktivist group Server Killers, which declared what it called "cyber war" on Norway back in August over the country's renewed defense cooperation with Ukraine, struck again this week — this time against Norway's higher education sector specifically rather than the government digitalization agency it hit the first time around. On September 2, denial-of-service attacks knocked the websites of the University of Oslo, the Norwegian University of Life Sciences, the University of Southeastern Norway, the University of Agder, and OsloMet offline or unstable. The University of Southeastern Norway's own communications director described the scale directly: within an hour and a half of the attack starting, the university's servers had logged 32 million requests to open its website, forcing the team to work on stabilizing infrastructure in real time. Server Killers claimed responsibility in a Telegram post, stating the attack would run for five hours — and by Wednesday evening, the affected sites were confirmed back online.

The detail that matters most for anyone assessing the real damage here is what didn't happen: the University of Oslo and other affected institutions were explicit that the disruption was limited to public-facing websites, with no indication that student data, staff information, or other sensitive systems were compromised or accessed. This is a useful, concrete illustration of a distinction worth holding onto whenever a DDoS attack makes headlines — a denial-of-service attack is fundamentally an availability attack, not a confidentiality or integrity breach; it's designed to make a service unreachable by overwhelming it with traffic, not to steal or alter what's behind it. That distinction doesn't make the disruption harmless — a university unable to serve its own website during business hours is a real operational cost, and Sikt, the shared technology services provider for Norway's education sector, was separately hit by a similar attack over the preceding weekend that intermittently affected Feide (the national education login system), Educloud, and Samordna opptak, the national university admissions platform — but it does mean the practical response is about resilience and capacity, not about assuming personal data has been exposed every time a .no domain goes dark. Given this is now the second distinct wave of this campaign in as many months, with a clearly stated political motivation and no sign of stopping, Norwegian public-sector and education institutions are reasonable to treat continued targeting as an ongoing operational reality to plan capacity and DDoS mitigation around, rather than a one-time event that's now behind them.