Not passwords. Not login tokens. Conversations. The thread where a customer explained their setup, the support call where someone described a problem in their own words, the sales notes about who decides what. That is the raw material of a convincing lie.

Here is what WorkOS itself has confirmed. On 30 October it identified unauthorised access to an internal application used by its sales team. On 2 November it published a security bulletin about it. The investigation found an AI-assisted offensive security framework had been used to automate reconnaissance and exploitation attempts. WorkOS disabled external access to the affected application, hired an independent forensics firm, and began reviewing access controls across its internal tools. Affected records are still under review.

And here is the line the company draws: there is no evidence that WorkOS application data was accessed, and no evidence that production services were accessed or impacted. Its current analysis says the incident affected only CRM and customer support data. That deserves to be stated plainly — but it is worth understanding what "only" covers here.

The application provided access to four categories of information. Business contact details from the CRM: names, email addresses, phone numbers, job titles, company affiliations. Account and relationship information, including customer account histories. Those conversation summaries and excerpts. And operational metadata: how customers use WorkOS products, including product usage and connection or directory health.

None of that, on its own, lets an attacker log in as you. All of it, together, lets an attacker sound like someone who already knows you.

That is the turn this story takes, and it is why WorkOS's own advice is the most useful paragraph in the bulletin. Business contact information and details from previous conversations, it warns, can help an attacker make fraudulent requests look legitimate. Even when a message references a real colleague or a real support conversation, verify unexpected requests before acting on them. The phishing email that quotes your last support ticket back at you is not a smarter phish. It is a phish built from your own words.

One distinction is worth keeping straight, because coverage of this incident has blurred it. WorkOS's bulletin describes an "AI-assisted offensive security framework" but does not name one. Founder and CEO Michael Grinich said separately, in his own 2 November disclosure, that the attack involved ARTEX, an AI-powered framework that automates offensive security tasks. Reporting on the incident repeats that name; the bulletin does not. Likewise, details circulating from a customer notice reposted online — a detection time, specific downstream systems, traffic locations — have not been confirmed by WorkOS on its own site, so this article does not rely on them. What is confirmed is bad enough without decoration: an automated, agent-driven attack reached an internal tool, and the tool held conversation context.

It is also worth saying what WorkOS has not disclosed. No count of affected organisations, no description of the initial access mechanism, and no word on whether a software flaw, abused credentials, or a combination opened the door. Those are open questions, not blanks to fill with guesses.

Now the irony, which is the reason this one sticks with me. WorkOS sells single sign-on, directory sync and audit controls to thousands of software companies. Its product is, in effect, the front door other companies buy. The attacker did not need to break that door. The sales team's internal application — the kind of tool that sits just outside the perimeter everyone guards most fiercely, full of context, reachable from outside — was the place reached. The distinction between the product and the company around the product is the whole lesson.

Every company has a version of this tool. The CRM that knows your customers better than your product database does. The support system that remembers every awkward conversation. The internal dashboard someone stood up quickly, gave broad access because the team needed it, and never put through the same review as the thing customers pay for. These tools accumulate trust without accumulating scrutiny — and they hold the context that makes social engineering work.

So the practical version: inventory your internal applications the way you inventory your production ones. Put them behind the same single sign-on and multi-factor authentication, not a separate, weaker login. Log who touches them, and actually read those logs. Ask the uncomfortable question WorkOS is now answering in public — if this tool were reached tomorrow, what would the attacker learn about our customers? If the answer is "their conversations," treat it like production data, because that is what it becomes in the wrong hands.

And for everyone else, the defence is almost embarrassingly simple, and it is the one WorkOS itself gives: a message that knows too much about you is not proof it comes from someone you trust. It may be proof of the opposite. Verify through a channel you chose, not the one the message hands you.

The product held. The company around it got reached through the side door. In 2026, that side door increasingly has an agent doing the knocking — patient, tireless, and very good at reading the notes you left lying around.

Nothing about that looks dramatic on its own. GitLab is built to take pipeline files — they're the instructions that tell it how to build and test software. But these ones were crafted to hit a specific flaw, and over 20 and 21 October, GitLab worker processes on Alpine's server crashed eight times. Four of those attempts got partway through the exploit before failing. None of them, as far as Alpine can tell, got all the way in.

That last clause is doing a lot of work. Hold onto it.

The flaw was CVE-2026-97229, and it carried the maximum severity score: CVSS 10.0. GitLab had disclosed it on 12 October, in its patch release for versions 19.2.8, 19.3.5 and 19.4.2. In plain terms, it's an integer overflow — a counting error — in Onigmo, the regular-expression engine bundled with Ruby that GitLab uses to read patterns in CI/CD pipeline files. A specially crafted pattern in a pipeline file could, under certain conditions, let someone without any login run code on the server. No password, no account with privileges. Just a file, submitted the way any user submits one.

Alpine's server was running GitLab 19.3.4 when the attack arrived — one step short of the fixed release for its branch. And here's the part that should make anyone who runs their own infrastructure sit up: fixing the version number wasn't, on its own, enough. Alpine's own container image didn't carry the patched Ruby that GitLab's official packages bundled, so a later upgrade to 19.3.6 still left the flaw open. The bug lived in the layer underneath GitLab, and the patch had to reach that layer too. Ruby's own fix landed on 23 October, in versions including 3.3.13. Checking "are we on the fixed GitLab?" and stopping there would have given a false clean bill of health. You have to check what's underneath the thing you patched.

The attacker, meanwhile, had also downloaded Alpine's GitLab container image. Alpine reads that as a sign the exploit was being tuned to its exact build — preparation, possibly, for something bigger. That's Alpine's interpretation, not a confirmed supply-chain attack, and the distinction matters. What is confirmed is narrower: eight crashes, four partial attempts, and no evidence that code actually ran or that any package or release was tampered with, through 27 October. Alpine also notes its signing keys aren't stored on that server, so they weren't in reach this way.

So why rebuild everything?

Because the evidence Alpine needed to prove a negative no longer existed. Background job logs were missing. There were no outbound connection records to check. The team couldn't show that nothing had left the server, because the records that would have shown it were gone. And if the attack had succeeded, the prize would have been serious: user details, password hashes, two-factor secrets, CI/CD secrets, integration credentials, private project content. None of that is confirmed compromised. All of it was, for a window, possibly exposed. "No evidence of a breach" and "evidence there was no breach" sound similar. In incident response, they are opposite statements, and Alpine refused to pretend they were the same.

So on 27 and 28 October, Alpine took the harder route, in its own words: it closed the instance, rebuilt it from scratch, reset passwords and replaced secret keys, and published a fresh container image carrying the fixed Ruby. CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalogue on 29 October, with a 1 November deadline for US federal agencies — the catalogue entry being the formal confirmation that this flaw is exploited in the real world, not just on paper.

I'm still learning this stuff, and this is the incident I keep coming back to when someone asks what "assume breach" actually means in practice. It doesn't mean panicking. It means deciding, in advance, what you will do when you can't prove you're clean — and then actually doing it when that day comes, even though rebuilding is slower, more embarrassing, and harder to explain than patching and moving on.

If you run a self-managed GitLab, the checklist writes itself: get onto a fixed release from GitLab's official packages, then verify the Ruby underneath is actually fixed too — don't trust the version number alone. Look for crashed workers, unexpected accounts, new runners or tokens, and pipeline variables you didn't set. And if you find the kind of gap Alpine found — logs missing, records gone — rotate the secrets before you convince yourself you didn't need to. A rebuild you didn't need is a wasted weekend. A rebuild you skipped and did need is a very different story.

Alpine didn't prove it was hacked. It proved something rarer: it was willing to act as if it might have been.

That is the picture CrowdStrike paints in its report on VAPOR PANDA, published on 29 October 2026. From 17 October, over 11 days, a single ARTEX controller went after more than 200 organisations in at least 14 countries: foreign ministries in Latin America, Europe, Asia and the Middle East, a Middle East interior ministry, a European country's presidency, prime minister's office, and its defence, justice, finance and intelligence arms, 19 US organisations across pharmaceuticals, semiconductors, defence, nuclear and finance, and telecom providers in the US, Belgium and the Philippines.

Read that list slowly, because the first number is a trap. Two hundred is how many were targeted. It is not how many were breached. CrowdStrike confirmed post-exploitation activity — the attacker actually inside, doing things — at nine organisations. At least 12 more faced password spraying and credential scanning. CrowdStrike later told CyberScoop that roughly 70% of targets were confirmed compromised or showed moderate-confidence evidence of intrusion, around 140. Those are two different kinds of counting: nine is what the blog proves, the wider figure is the firm's broader assessment. Anyone who quotes you "200 hacked organisations" from this report is selling you the target list as a victim list. Don't buy it.

So what actually did the breaking in? ARTEX, an open-source framework that runs a penetration test with AI agents instead of a human at a keyboard. A main agent directs planner agents and worker agents, and they share a graph of everything they've found — facts, findings, goals — so one engagement's discovery feeds the next move. It ran mainly on DeepSeek, plus a second commercial model CrowdStrike could not identify. A human operator still steered it at decision points, telling the agents to write web shells, pull domain administrator passwords, and map which endpoint sensors were watching. The machine did the volume. The human did the judgement.

And the volume is genuinely hard to picture. In a single intrusion, CrowdStrike says the planning agents consumed on the order of 1.4 billion input tokens — a measure of how much text the models chewed through just planning that one break-in. CrowdStrike told CyberScoop the campaign ran at more than 1,500 commands per hour, against a historical norm of up to 40 commands an hour from a human typing at a keyboard. That is the real story, and it's not "AI is smarter than hackers." It's that one operator can now run many engagements in parallel, try many paths at once, and switch paths the moment one fails — web apps, cloud, containers, Active Directory, mail and VPN infrastructure, all in the same campaign.

Here is the part that should bother you more than the AI. The doors were old.

CrowdStrike's recovered transcripts describe agents chaining an unsigned SAML assertion — a login token nobody had properly signed — with an XML external entity flaw, to reach a cloud metadata service, then obtaining a role that could issue administration commands to thousands of instances, and finally recovering an enterprise administrator account. Elsewhere they dropped web shells, abused an unauthenticated orchestration service to get root in a production container environment, read LAPS passwords, and used resource-based constrained delegation to impersonate a privileged account. And in one case, the agents were simply handed authentication keys that had not been rotated since 2022, forged an administrator token with them, and read mailboxes — then used a VPN configuration recovered from a user's sent mail, plus a VPN client key from a purported May 2024 email leak, to reach the internal network.

None of that is a zero-day. It's a museum of unclosed basics: unsigned tokens, an unauthenticated service with root reach, passwords sitting where they could be read, keys left unrotated for four years, a VPN key floating around from an old leak. The AI didn't invent a new way in. It just tried every old way in, everywhere, at once, without getting tired. If your defence assumes an attacker has to choose a few targets and work them slowly, that assumption just expired. And note: CrowdStrike says this campaign is separate from the ARTEX activity Microsoft tied to Storm-0940 in the ConnectWise compromise — a different group, same open-source framework, which has now shown up in three unrelated sets of hands.

What do you actually do with a story like this? The honest, boring version. Rotate credentials that have sat untouched for years — if you can't remember the last rotation, that is the answer. Kill unauthenticated access to orchestration and admin services, or at least put it behind something that asks who you are. Treat an unsigned SAML assertion as a failed login, not a quirk. And hunt for the framework's fingerprints: CrowdStrike published indicators for ARTEX and for BLOODALCHEMY, the ShadowPad-derived backdoor deployed in the confirmed intrusions. If you run a small team, the practical version is even simpler — pick the oldest credential in your estate this week and rotate it. The agents in this campaign were quite happy to use the ones from 2022.

The operator is still one person at a keyboard, somewhere, steering. They just don't have to choose which door to knock on anymore. They can knock on all of them.

Sources

• CrowdStrike analysis (29 October 2026), via The Hacker News: https://thehackernews.com/2026/10/chinese-hackers-use-ai-powered-artex-to.html
• CyberScoop reporting on CrowdStrike's ~70% assessment and command-rate figures, via secondary coverage of the same report (figures attributed to CrowdStrike in that reporting, not to the blog text itself)

Confirmed vs not confirmed Confirmed (CrowdStrike's report): 200+ organisations targeted from 17 October over 11 days; post-exploitation confirmed at nine; password spraying/credential scanning against at least 12 more; ARTEX on DeepSeek plus an unidentified commercial model; ~1.4 billion input tokens consumed by planning agents in one intrusion; BLOODALCHEMY deployed in confirmed cases; campaign separate from Microsoft's Storm-0940 ARTEX activity. Reported, not in the blog text itself: the ~70% / ~140 figure and the 1,500-vs-40 commands-per-hour comparison, as CrowdStrike told CyberScoop. Not disclosed: the full victim list, the entry point for each target, or how much data (if any) was taken — none is claimed here.

But the headline number is not the interesting part. The shape of the attacks is.

For years, the DDoS story people pictured was a giant wave: a single enormous flood, big enough to make the news. Those giants are fading. Attacks over 1 terabit per second fell from 805 in Q2 to 251 in Q3, nearly 69% down. Cloudflare says that may reflect law enforcement action early in 2026 against four large Internet-of-Things botnets — Aisuru, KimWolf, JackSkid and Mossad. "May" matters: a plausible link, not a proven cause.

What replaced the giants is something less photogenic and much harder to deal with: swarms. Short-burst, low-bandwidth attacks — under ten minutes, under 1 gigabit per second — surged 208%. Almost all of the quarter's network-layer attacks fit that profile: 96% ended in under ten minutes, and 98% stayed under 1 gigabit per second. Do not let that "under 1 gigabit" fool you. A gigabit aimed at one small server is more than enough to knock it offline. You do not need a tsunami to flood a house. A burst pipe will do.

Cloudflare calls this the signature of DDoS-for-hire "booter" services, and the logic is brutally commercial. A giant attack needs a giant botnet, expensive to build and a priority target for police. A short burst from a rented service is cheap, quick, and repeatable — and over before most incident-response plans even start. Most of these attacks end long before a human analyst could see the alert. If your defence depends on someone noticing, paging a team, and switching something on, you are already too late.

The tools are shifting too. One old trick has practically vanished. CLDAP floods — where a small query with a forged return address tricks public servers into bouncing a much larger reply at the victim — collapsed by 99.5% in a single quarter, down to just 0.05% of network-layer attacks, after surging 580% in the first half of the year. Attackers did not retire. They moved. DNS amplification, the same reflection trick using open DNS servers, jumped 215% to 3.43% of attacks. General UDP floods climbed from 14.06% to 31.31%. Close one door, and the traffic does not stop — it walks around to the next open one.

The targets are spreading out as well. Media, production and publishing is still the most-attacked industry, but its share is roughly a quarter of what it was in Q2. The focus has widened to computer software, gambling and casinos, information technology, and — climbing into the top ten — internet infrastructure, consumer services and adult entertainment. Geographically, the United States reclaimed the most-attacked spot from China, with Indonesia third at 2.93% of attacks. Two countries jumped sharply: Canada, from 16th to 6th, and Israel, up seven places to 10th. Cloudflare does not claim a single motive for either spike, and neither should we. What the movement shows is that DDoS is no longer pointed mostly at one kind of target. It is pointed at whoever is inconvenient, newsworthy, or simply unprotected that week.

And the old botnets are not dead, just regrouping. Mirai-classified traffic peaked in August at 57.23 petabytes, nearly half of all mitigated network-layer bytes for the quarter, and new variants are already appearing, including Dysphoria and Evooo1Bot. Taking down four big botnets did not end the botnet problem. It pruned it.

So what should a learner, or a small team running a website, take from this? Three things, and none of them requires a security budget the size of Cloudflare's.

First, size is the wrong thing to fear. A 1-gigabit burst you are not ready for beats a 1-terabit flood someone else absorbs. Ask whether your site stays up under a short, sharp flood.

Second, assume the attack will be over before you react, and design for that. That means mitigation that is always on, not switched on in a crisis — a provider's free tier, your host's built-in protection, or a service in front of your site.

Third, close the open doors attackers pivot between. Open DNS resolvers and exposed UDP services are the raw material of the next amplification wave. The CLDAP collapse shows defenders can make a vector unusable. The DNS surge shows attackers will simply use the next one left open.

One honest caveat. These figures come from Cloudflare's network, which protects more than a fifth of the web. That is a huge sample, but it is still one company's view, not a census of the whole internet. Treat 18.2 million as what Cloudflare saw and stopped, not as the total number of DDoS attacks on Earth. The direction of travel — more attacks, shorter, smaller, faster — is the part worth trusting, because it shows up in every slice of the report, not just one chart.

The giants made the headlines. The swarms are making the weather.

Sources: Cloudflare, "DDoS Threat Report 2026 Q3: More swarms, fewer giants" (published 29 October 2026, updated 30 October 2026) — https://blog.cloudflare.com/ddos-threat-report-2026-q3/ ; The Hacker News, "Cloudflare Reports 18.2 Million Network-Layer DDoS Attacks in Q3, Up 38%" (31 October 2026) — http://thehackernews.com/2026/10/cloudflare-reports-182-million-network.html

What is confirmed, and what is not: All attack counts, shares, durations and country/industry rankings are from Cloudflare's own Q3 report (via its network telemetry); the THN piece corroborates the headline figures. The link between the fall in hyper-volumetric attacks and the early-2026 botnet takedowns is Cloudflare's stated possibility, not a proven cause. No motive is claimed for the Canada or Israel spikes beyond the context Cloudflare gives. Figures describe Cloudflare-network mitigations, not a global total. No victim count, ransom, or data theft is claimed — a DDoS attack, by itself, knocks a service offline; it does not steal data.

In four of those crashes, Alpine says, the attacker got partway through the exploit and failed at the next step. Partway. That word does a lot of work in this story. It means the attack was not a theoretical paper exercise. It was close enough that Alpine could watch it climb the stairs and stop, one step short of the room it wanted.

The flaw was CVE-2026-97229, scored a full 10.0. In plain words: a specially built regular expression — a pattern-matching rule — tucked into a CI configuration could let someone with no special privileges run code on the GitLab server. The bug itself lived in Onigmo, the regular-expression engine inside Ruby, the language GitLab is built on. GitLab had published fixed releases on 12 October.

Alpine had almost done everything right. On 13 October it upgraded — to 19.3.4 instead of 19.3.5, the release that carried the fix. A one-digit mistake, the kind anyone running infrastructure at midnight recognises. That was the open door the attacker walked up to a week later.

Here is where the story stops being a normal patching tale and turns into something worth remembering.

On 22 October, Alpine upgraded again, to 19.3.6, the newest release. Job done, ticket closed — or so it seemed. The server stayed vulnerable, and nobody knew it for four more days.

The reason is simple. GitLab's fix was not a change to GitLab's own code. It was a patch to the Ruby that GitLab bundles inside its official packages and container images. Alpine's image did not use that bundled Ruby; it used standard Ruby, installed separately. So upgrading GitLab changed everything except the one component that was actually broken — like replacing a door lock while the faulty hinge is what lets someone in.

Alpine found the truth on 26 October: still vulnerable, after the upgrade. The next day it closed GitLab to everyone except its developers and build servers and started again from scratch. The rebuild finished on 28 October. Every password was reset. GitLab's secret keys were replaced. The rebuilt server runs Ruby 3.3.13 or later, which carries the fix — upstream Ruby shipped its own fixed versions, 3.3.13, 3.4.12 and 4.0.9, on 23 October.

And here is the part Alpine refuses to soften. It found no evidence the attacker actually ran code on the server — and it cannot rule it out. A successful exploit would leave no crash and no trace in the web logs, and some logs from the attack days are gone, including background-job logs and the old container's filesystem. There was no logging of outbound connections either. So Alpine treated the server as compromised and rebuilt it anyway. When you cannot prove you are clean, you act as if you are not.

What could have been exposed is a sobering list, published by Alpine: users' emails, names and IP addresses, password hashes, two-factor secrets, CI/CD variables and runner tokens, webhook credentials, personal access tokens, private repositories, confidential issues and merge requests. Not just one server — the keys to a whole ecosystem of builds.

The good news, verified the hard way, is narrower than it sounds. Alpine checked its package repository and 21 October releases against records the attacker could not reach — a developer's clone, all 45 builders — and found no sign of tampering. The keys that sign Alpine's packages and releases were never stored on the GitLab server at all. That separation, decided long before anyone attacked, is what kept a close call from becoming a supply-chain disaster.

On 29 October, CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalogue, with a 1 November deadline for US federal agencies — a formal way of saying this is not a hypothetical bug anymore. But the lesson here is not "patch faster," though Alpine now plans to apply critical GitLab releases within a day. It is more specific, and more uncomfortable.

Patching is not the same as verifying. When you upgrade a product, ask what actually changed inside it. Did the fix live in the application, or in a library, a runtime, a bundled component your own build replaces with something else? If you build from source or maintain your own container image, the vendor's patched package may never reach your vulnerable part. Alpine's warning is blunt: upgrading GitLab is not enough. You also need the fixed Ruby.

There is a second lesson, about evidence. Alpine is now keeping logs longer, recording outbound connections, and moving to signed release tags so releases can be verified independently of GitLab. Those are the changes you make after learning that "we found no evidence" and "we are sure" are two very different sentences — and in incident response, the gap between them is where the real risk lives.

So check your stack, not just your app. If you run GitLab on your own Ruby, make sure that Ruby is 3.3.13, 3.4.12, 4.0.9 or later. If you use Alpine's container image, pull 19.3.6 again — only the image published on 27 October carries the fixed Ruby. And if you ever find yourself saying "but we patched," pause, and ask the question Alpine learned to ask four days late: patched what, exactly?

Sources: Alpine Linux, "GitLab security incident: attempted exploitation of CVE-2026-97229" (28 October 2026) — https://alpinelinux.org/posts/GitLab-security-incident-CVE-2026-97229.html ; The Hacker News, "Attacker Tried to Exploit Alpine Linux's GitLab via CVSS 10.0 Flaw Its Ruby Left Open" — https://thehackernews.com/2026/10/attacker-tried-to-exploit-alpine-linuxs.html ; CISA Known Exploited Vulnerabilities catalogue entry for CVE-2026-97229, added 29 October 2026 (reported by multiple outlets; due date 1 November 2026 for US federal agencies).

What is confirmed, and what is not: The attack attempts, the eight crashes, the failed upgrade, the rebuild, the password reset and the key replacement are all from Alpine's own post-mortem. Whether the attacker ever ran code is explicitly unproven either way — Alpine says no evidence of success, but it cannot be ruled out. No tampering with Alpine packages or releases was found. No victim count beyond the server's user base is claimed, because Alpine does not give one.

Sometime in early 2026, according to CrowdStrike, an intruder was already inside some VMware environments in the United States legal sector, with administrator access — the highest level of control on the system. What it did next was quieter. It used a flaw in VMware ESX, the software that runs virtual machines, that let certain administrator operations go unrecorded. The system kept working. The record simply had holes in it.

On 28 October 2026, CISA added that flaw to its Known Exploited Vulnerabilities catalog — flaws confirmed to have been used in real attacks — giving federal civilian agencies until 11 November 2026 to apply the fixes. The flaw is CVE-2026-41709. Its severity score is 2.7 out of 10.

Why a 2.7 can still be the dangerous one

Severity scores try to answer one question: how bad is this flaw on its own? A 2.7 is low. Broadcom, which owns VMware, rated it Low when it disclosed and fixed the flaw in July 2026, in advisory VMSA-2026-0006. The reason is fair on its own terms: the flaw does not let an outsider break in. It only helps someone who is already an administrator.

But attackers use flaws in sequence, and a flaw's value depends on where it sits in that sequence. This one sat at the end — after the break-in, after the privileges — in the defender's last safety net: the audit trail.

Broadcom describes it plainly. VMware ESX contains an insufficient logging vulnerability, classified as CWE-778. A malicious administrator could exploit it to perform certain operations without them being logged. The advisory does not say which operations, and neither does CISA's entry — a gap worth stating rather than filling. What is established is the shape of the weakness: not theft, not destruction, not access, but absence. There was no workaround. The only fix was the patch.

The chain around the hole

CrowdStrike attributes the exploitation to Warp Panda, a China-nexus espionage group it also tracks as Armory Castle, Clay Typhoon and VerdantBamboo. That attribution is CrowdStrike's assessment, reported in its 2026 Legal Threat Landscape Report — not a fact established by a court or a government indictment in the sources available for this article. The group has a long record, according to CrowdStrike and Mandiant, of weaponising zero-day flaws — flaws unknown to the vendor — in internet-facing edge devices, including Citrix NetScaler and Ivanti Connect Secure appliances.

The pattern CrowdStrike describes: get in through an exposed edge device, pivot — move sideways — into the VMware vCenter environment, the central console that manages virtual machines across an organisation, and deploy custom malware, named BRICKSTORM and SharpStorm, built to stay quiet. Then, with the logging flaw, reduce the chances that any of it shows up in the record.

The quiet did not stop at the hypervisor. In some intrusions, CrowdStrike says, the group harvested cloud session tokens — temporary passes proving you are already signed in — to reach Microsoft 365 without triggering the alerts a stolen password would set off. In at least one case, it registered a new multi-factor authentication device on a compromised account, so changing the password afterwards would not remove its access.

Why law firms

CrowdStrike is blunt about why the legal sector was worth this much patience. Law firms hold, in one place, client communications, merger and acquisition material, active litigation strategy, and access across many different clients at once. One compromised firm can illuminate several companies' plans — information with what CrowdStrike calls "downstream operational utility," useful not just to read, but to act on. There is no ransom note here, no leak site, no public claim: espionage intrusions are built to be boring from the outside.

What actually changes on Monday morning

First, the patch. Broadcom's fixed builds include ESXi-9.1.0.0-25370933 and ESXi-9.0.2.0100-25595025 for the Cloud Foundation and vSphere Foundation lines, ESXi80U3j-25429389 for ESX 8.0, and VMware Cloud Foundation 5.2.4. Check the advisory for the exact build matching your environment; the list is longer than the headline versions.

Second, do not treat patching as the whole answer. A flaw exploited as a zero-day in early 2026, months before the July fix, means the question for any unpatched host is not only "is it fixed now?" but "what happened while it was not?" CISA's federal guidance expects agencies to check whether a system was compromised before the patch was applied. Every organisation running ESX should do the same, even though the deadline binds only federal agencies: review administrator actions, look for gaps in the logs, check for newly registered MFA devices and unfamiliar cloud sessions, and treat a clean-looking log from that period as incomplete evidence, not a clean bill of health.

Third, protect the record itself: forward logs to a separate, tamper-resistant store and alert on gaps in log flow, not only on suspicious entries. A missing log line, once an intruder is inside, is the difference between an incident you can reconstruct and one you have to guess at.

And the lesson beyond VMware: severity scores are a triage tool, not a verdict. A 2.7 that erases a skilled intruder's evidence can matter more than a 9.8 that crashes loudly and gets fixed the same week.

The logs said nothing had happened. For the people who had to find out what really did, that silence was the incident.

That is how long it took an autonomous AI agent to find four previously unknown flaws in software that helps run particle accelerators and fusion experiments. The agent, called Cipher, was built by a company named Causal Security. Its co-founder, Shubham Raj, told The Register the first part needed no human help at all. A person stepped in once, with one instruction: test whether the flaws could really be exploited, in a secure environment.

The software is EPICS, short for Experimental Physics and Industrial Control System. It is decades old, open source, and far more ordinary than it sounds. It was originally developed by Los Alamos National Laboratory and Argonne National Laboratory, and it is now used in around 90 major scientific, university and industrial projects around the world, including Argonne's Advanced Photon Source and the control system for ITER's fusion reactor.

EPICS does not do the physics. It sits in between: controllers take measurements from physical equipment, pass commands from operators, and keep the whole experiment talking to itself. If that middle layer stops working properly, the experiment stops too.

That is why the four flaws matter, even before anyone talks about hackers taking control.

The worst of them, CVE-2026-114595, scores 9.8 on the CVSS v3.1 scale. It is an integer overflow in the way EPICS handles network requests. In plain words: the software does a piece of arithmetic about how much memory to set aside, gets the answer wrong, and then writes attacker-supplied data past the end of the space it reserved. CISA, the US Cybersecurity and Infrastructure Security Agency, says that can corrupt memory, cause a denial of service, or potentially let a remote attacker run their own code.

The other three are less severe, but they point at the same weakness: messages arriving over the network were not checked carefully enough before the software acted on them. CVE-2026-114596, rated 8.2, is a message-length validation flaw that can also write past the end of a buffer and crash a controller process. CVE-2026-114597, rated 7.5, lets the software read past the end of a buffer, which can crash a process and expose nearby memory. CVE-2026-114598, also rated 7.5, is a type-confusion flaw — the software treats a piece of data as one kind of thing when it is really another — with a similar crash and memory-exposure risk.

All four affect EPICS Base release 7.0.10 and earlier. The fix is release 7.0.11, named in CISA advisory ICSA-26-300-01 on 27 October 2026. CISA also says no known public exploitation specifically targeting these flaws had been reported to it at the time of the advisory. These are vulnerabilities, found and fixed before any reported attack. That distinction matters: a flaw is not a break-in.

And yet the detail that stays with you is not the scores. It is the time, and the lack of specialist knowledge the work apparently required.

Raj told The Register that once an attacker can reach a vulnerable EPICS network — because it was misconfigured, or because another system had access to it — carrying out the attacks would be, in his words, pretty easy. Exploitation would not require deep knowledge of operational technology, or of how a particle accelerator or a fusion reactor works. Someone with conventional exploitation skills could investigate the flaws, he said, and increasingly capable AI systems could help develop exploits without that specialist background.

He was careful about the limit of that claim. Manipulating a specific physical process would still need more knowledge. But an attacker does not need to understand the physics to disrupt the software controlling it. Crash a controller, interrupt measurements, and operators may have to halt an expensive experiment. Lost work, downtime, and costly recovery follow from a crash alone.

That is the turning point in this story. For years, obscure industrial software enjoyed a quiet kind of protection. Few people outside a small community understood it, and fewer still had the patience to learn it from scratch. Cipher learned it in under four hours, in a system unfamiliar to it. It was not the first time, either: The Register reports that earlier this year Cipher found multiple critical attack paths in power-grid systems used across North America and Europe, leading to a CISA advisory on 8 October.

Obscurity was never a real defence. It was a delay. The delay just got shorter.

The defence that still works is older and less exciting than the discovery. CISA's advice is to keep control-system devices off the internet, put control networks behind firewalls and separate them from business networks, and use updated, secure methods for any remote access. In other words, the flaws only become reachable if the network lets someone reach them. Segmentation is not a glamorous fix. It is the fix that decides whether a flaw found in hours becomes an incident at all.

Facilities running EPICS Base 7.0.10 or earlier should update to 7.0.11. That is simple to write and harder to schedule around live experiments, which is exactly why the network controls matter while the update is planned.

The physics didn't change. The time it takes to learn the system did.

Hundreds of messages, all at once. Newsletter confirmations. Subscription receipts. Things you never signed up for, arriving faster than you can delete them. It looks like something broke. And then a message lands in Microsoft Teams.

Someone from IT. Offering to help.

That is the whole trick, and it has worked more than 400 times — that is how many incidents Arctic Wolf Labs analysed in a report published on 26 October 2026. Not 400 clicks on a bad link. Four hundred cases of the same pattern: a chat window, a friendly name, and a person who believed they were talking to their help desk.

There was no software vulnerability in this story. Arctic Wolf says so plainly. Teams ships with external access switched on by default, which means a user in another Microsoft 365 tenant can find an employee, message them, and call them, as long as both sides allow it. The attackers did not break that feature. They used it exactly as designed.

The flood comes first, in a significant number of cases. Arctic Wolf calls it mail bombing: hundreds of subscription confirmations pushed into a victim's inbox within minutes, burying real alerts. Then the "help desk" arrives to solve that problem the attacker just created.

Then comes the name.

The sender's display name does the heavy lifting. Arctic Wolf found the same kinds of names again and again: "Help Desk", "IT Support", "IT Service Desk – Liam", "Enterprise IT & Security (Internal)". The word in brackets matters most. Teams does label the sender as external. But when the name itself says "(Internal)", the eye reads the name and skips the warning. A first name helps too. Liam sounds like someone who works down the corridor. More recently, attackers have added the victim's own company name or domain to their display name.

The tenant behind the name is usually disposable. In 30 to 40 percent of the cases Arctic Wolf analysed, the attacker used Microsoft's default *.onmicrosoft.com domain — the address a new tenant gets automatically, with no verification, provisioned in minutes. The tenant names were chosen to sound like infrastructure: helpdeskteam365, itendpoint365, itcoreportal, itadmin922. Of the paid domains Arctic Wolf identified over recent months, about half used the cheap .top ending and around 40 percent used .com.

None of this, on its own, steals anything. The theft starts when the victim hands over the keyboard.

The attacker's goal, once trust is established, is hands-on access through a legitimate remote-access tool. Quick Assist comes first most often: it is built into Windows, signed by Microsoft, needs no installation, and asks the victim only to read back a six-digit code. If that is blocked, the attacker moves to tools like AnyDesk, TeamViewer or ScreenConnect. A second remote tool is often installed afterwards, so the attacker keeps a way back in even if the first one is removed.

Here is the detail that breaks most people's mental model of how these attacks work: in a subset of cases, the attacker never pastes a link into Teams at all. A pasted link would trip Safe Links scanning. So the attacker, sitting at the victim's keyboard through the remote session, simply browses to the payload themselves. The dangerous click never happens. The victim never downloads anything suspicious. They watch someone they believe is IT do IT things on their own screen.

Arctic Wolf describes one observed chain in which the victim was talked into running a command that fetched an installer from Azure Blob storage, leading to a script, a Python implant, queries against Active Directory for every computer and user object, and the results sent out to attacker-controlled servers. It started as a conversation. In cases reported by customers, attackers reached payload execution in under 15 minutes.

And then there is the clock. Sophos tracked a related cluster, STAC4749, across dozens of North American organisations between February and June 2026. At least three of those intrusions ended in Chaos ransomware. In one, the time from first Teams contact to files being encrypted was under 17 hours. The calls themselves were mostly two to two-and-a-half minutes long. Two minutes of pleasant, professional conversation. Seventeen hours to encryption. Microsoft first documented the same shape of attack in mid-2024, with the Black Basta group. Two years of public reporting, and the door is still the default setting.

So what actually stops it? Not another warning banner. The fixes Arctic Wolf lists are mostly decisions, not products: narrow Teams external access from "allow all" to an allow-list of specific partner domains, blocking unmanaged consumer accounts and trial-only tenants; restrict Quick Assist to authorised IT roles and alert on any unapproved remote tool; and move verification outside the channel being impersonated — a callback to a registered number, or an approval in a separate trusted app, cannot be completed by someone who only controls the Teams conversation. Teach one habit above all: read the sender's real domain, not the display name. The display name is a costume. The domain is the ID.

The uncomfortable lesson is not that employees are careless. It is that the system trained them well, and handed the attacker the classroom. We teach people to trust messages inside their work tools and to be suspicious of email. The attackers simply moved the conversation to the place trust already lives.

Check the domain. The name is the whole attack.

That Sunday-night attempt was not the start of the story. It was the second act.

On the night of 22 October, monitoring systems picked up something that did not look like normal traffic at all: roughly 11 million access requests and suspicious database queries aimed at digital public services, apparently trying to get citizens' personal data unlawfully. The authorities — the E-Governance Agency, the Information Technology and Cybersecurity Service, and the Cybersecurity Agency — contained that first attack the following day. Then they did the thing that makes this story worth telling properly.

They switched services off themselves.

It sounds like losing. In the usual telling of a cyberattack, a service going dark is the damage. Here, the outage was also the defence. Rather than leave the doors open while they checked what had happened, the agencies took the targeted platforms offline as a precaution, told the police and the National Center for Personal Data Protection, and kept working through the weekend. Technical teams from the three institutions have been working around the clock since 23 October, checking systems piece by piece so services can come back gradually, without handing attackers another opening.

Government spokesperson Dumitru Ciorici put it bluntly: the attack had entered a new phase, with about 15 state specialists continuously monitoring the situation and blocking attacks. The agencies' own line was just as clear — protecting data comes before convenience, even at the start of a working week when request volumes jump.

That trade-off is the part most coverage skips past. A building permit, an export certificate, a medicine-import authorisation — none of these sound dramatic alone. Together, they are the ordinary paperwork a country runs on, and while they stay down, exporters, builders, and shops all wait. The defenders knew that. They kept the services down anyway, because restoring access before the checks were done could have meant restoring the attackers' access too.

And here is the detail that should change how you read the whole incident: nobody has said the attackers actually got the data. The authorities have said the attack aimed to extract personal data unlawfully. They have not specified which platforms were targeted, whether any personal data was taken, or who was behind it. The government spokesperson has said he suspects the incident is part of hybrid attacks against Moldova, but that is a suspicion, not a confirmed attribution. Keeping those two things apart matters. An attempted theft is serious. A confirmed theft of a whole population's records would be something else entirely, and no source has established that yet.

What the authorities have warned about, concretely, is the second wave that usually follows an incident like this: fraud. Criminals may call, text, or email pretending to be officials or bank staff, and try to sound legitimate by quoting a person's full name or national identification number, the IDNP. The official advice is simple and worth repeating because it works: do not hand over passwords, authentication codes, or banking details to someone who contacted you, and do not click links in unexpected messages. If a caller claims to be from a public institution, hang up and reach that institution through a channel you already trust.

I am still learning this field myself, in class and in my own lab work, and this is one of those cases where the textbook lesson and the real event line up neatly. Incident response is often taught as detection, containment, eradication, and recovery, in that order. Moldova's sequence follows it almost literally: unusual queries detected, services disconnected to contain, checks running through the weekend, and only then a gradual recovery. The uncomfortable part is that containment can look exactly like failure to the public. A citizen who cannot file a form on Monday morning does not see a successful block. They see a broken service.

There is a second lesson tucked inside the first one, about patience as a security control. The agencies have given no complete list of affected services and no exact timeline for full restoration. That vagueness frustrates people, but a precise date promised early would have been worse: a guess that gets broken, or a deadline pressuring teams to reopen systems before the checks are finished.

So what should you take from a story whose ending is still unwritten? First, an offline service is not proof of a breach, and a restored service is not proof of safety; here, the outage was a deliberate choice. Second, the most dangerous moment may not be the night of 11 million requests. It may be the week after, when someone calls you, knows your name, and asks you to "confirm" the rest. Third, count the cost honestly: defenders protected data by sacrificing availability, and ordinary people paid for it in waiting time.

Moldova's services will come back, one check at a time. Until they do, the story is a reminder that sometimes the strongest move a defender can make is the one that looks, from the outside, like surrender: switch it off, keep it off, and do not let anyone rush you into switching it back on.

Sources

• Moldova1, 25 Oct 2026: https://moldova1.md/p/88566
• Moldova1: https://moldova1.md/p/88508
• Moldpres: https://www.moldpres.md/eng/society/cyberattack-on-digital-public-services-authorities-block-about-11-million-access-requests
• Radio Moldova: https://radiomoldova.md/p/88091

Google has updated its privacy policy to spell out something it had left fuzzier before: if you let Search or Gemini use data from other Google services, Search may use that data to personalise content — including ads. The update took effect on 16 October 2026, and it was first reported by Android Authority before The Hacker News covered it on 24 October.

Read that carefully, because the wording matters more than the headline. Google is not saying it will now read your emails to sell you ads by default. It says the opposite, in the same policy: "We don't show you personalised ads based on your content from Drive, Gmail, or Google Photos, unless you choose to make data from these services available to other Google services that support personalised ads."

The catch is the word "choose" — and how many steps that choice now covers.

The feature at the centre of this is Personal Intelligence, unveiled in Gemini in January 2026. It lets you connect Gmail, Google Photos and YouTube so Gemini can give tailored answers using your chat history and preferences. It is rolling out as a beta to users over 18, everywhere except the European Economic Area, Switzerland, the UK and Nigeria. Turn it on, and you have made a reasonable, understandable choice: better answers.

But under the new wording, that same choice also opens a second door. Once Search is allowed to process the data you shared, that data can become a signal for targeted ads. Your email is not being pasted into an ad. Your photos are not being sold. The point is subtler, and honestly more important for learners to grasp: in modern platforms, a permission rarely stays in the room you granted it in. It travels along the company's own internal pipes, from a helpful feature to an advertising one, and the only thing standing between the two is a settings page most people never open.

That is the real lesson here, and it is not unique to Google. OpenAI began showing ads to logged-in adult users in the US in January 2026, in both the free and ChatGPT Go tiers, while insisting that conversations are private from advertisers, that customer data is never sold, and that ads do not influence answers. This week it expanded that advertising to 26 more countries, bringing the total to 89. Two different companies, two different wordings, one shared direction: AI features and advertising are moving into the same room, and users are being asked to trust the wall between them.

So what do you actually do with this? Not panic, and not shrug. Check the chain.

If you use Personal Intelligence, open the Search personalisation settings and look at which apps are connected. You can disconnect individual apps from Personal Intelligence, or disable Personalised Recommendations entirely. That is the lever Google itself points to, and it is worth pulling deliberately rather than discovering it months later, after the ads have already learned your habits.

For learners, this story is worth more than a privacy scare. It is a clean example of how consent works in practice. The question is never just "did I agree to this feature?" It is "what else did agreeing to this feature agree to, three steps down the line?" Train yourself to ask that second question every time a product offers to connect your accounts for a smarter experience. The smarter the experience, the longer the chain — and the more carefully you should read where it ends.

Google has not hidden this. It wrote it into its policy, in plain enough language that reporters spotted it within days. Credit where it is due. But a policy update is not the same as a warning, and most people do not read policy updates. They just notice, weeks later, that the ads seem to know a little too much — and wonder when they said yes.

You said yes when you asked for smarter search. Now you know what else that yes can carry.

Not crashed — stopped. Every transaction on the layer-1 chain and every rollup tied to it froze at once, because the people running the network made it stop. If that sentence sounds strange for a technology built on the promise that nobody can turn it off — hold that thought. It's the point.

Initia is a blockchain network built to connect blockchains together, built on the Cosmos SDK. Fourteen minutes earlier, at 11:27 a.m. Eastern, independent researcher Spreek had spotted something ugly on-chain: what looked like someone minting tokens that shouldn't exist, already moving them out. His estimate: roughly $2.6 million cashed out, more in transit.

He was right. When Initia's official account announced the halt at noon Eastern, the team was still scrambling. Then co-founder Ezaan Mangalji — known as Zon — posted what they knew so far: "To the best of our knowledge so far, this is a Day 0 bug related to Initia's MoveVM on CosmosSDK that allowed the exploiter to mint additional tokens on the Initia L1 but does not apply to native INIT tokens."

A Day-0 bug. Not a stolen key, not a phishing email, not a broken password — a flaw in Initia's own code, in the Move Virtual Machine, the component that handles token minting logic. The attacker didn't break into anyone's wallet. They found the money printer and turned it on.

~$2.7 million in AUSD, ETH, and USDC. That's Zon's figure. And here's the detail that makes the crime work: minted tokens are worthless until they leave. So the attacker bridged them out — moving them to Ethereum via bridge infrastructure (D2 Finance traced the payouts to LayerZero adapters on Ethereum) before the validators could hit the kill switch. Printed on one chain, real money on another. By the time the network stopped, the tokens were already gone.

Some boundaries matter here, because crypto headlines love to skip them. The bug did not apply to native INIT tokens — the chain's own asset wasn't mintable. Agora, the issuer behind AUSD, denied any compromise of its stablecoin: its reserves and backing were fine. What got minted was the bridged representation — the copy of the asset living on Initia's side. This is the thing about bridges: they trust the chain. When the chain lies about what exists, the bridge carries the lie somewhere real.

The fallout ran fast. Upbit suspended INIT transfers. INIT itself fell 14% in minutes — then clawed the whole thing back and closed the day up 14%, the kind of whiplash that says traders read this as contained, for now. As of Friday evening, Initia said it was still working "to establish the full scope of any impact with security teams, validators, and exchanges." No restart date announced. The final loss figure unconfirmed even by Initia itself.

Now the part that should stick with you.

Most blockchain hacks are theft: someone takes money that exists. This was forgery at the protocol level. And the response was the oldest trick in computing: turn it off. But "turn it off" on a blockchain means coordinating validators across the planet to stop producing blocks — a central committee exercising emergency power over a system whose whole pitch is that nobody has emergency power. It worked as incident response. It reads as a small confession.

The lesson splits two ways. For builders: your mint function is the most dangerous code in your system. Not the bridge, not the wallet — the function that creates things from nothing. If an attacker can reach it, they don't need your users' money. They can print their own, then walk them out through your bridge while the alarm is still ringing.

For everyone else: watch the timeline. An independent researcher spotted it. Fourteen minutes later, the chain was down. That's genuinely fast response — and it still wasn't fast enough, because the attacker was already out the door. Detection and response were excellent. The money was gone before either could act. Prevention was the only move that mattered, and it lost.

The money printer had a bug. The blockchain had an off switch. Both worked.

On October 22, a new name appeared on the Everest ransomware group's leak site — and it made incident-response people across the world pause mid-scroll: PwC. PricewaterhouseCoopers. One of the Big Four. The firm that sells cyber risk assessments, breach-readiness reviews, and "how to handle ransomware" playbooks to the world's biggest companies.

According to the listing, the haul is enormous: 590.69 gigabytes across 108,426 files. Human resources records. Training files. E-learning courses. Internal audit methods. Confidential documents. And — this is the one that made my eyebrows climb — single sign-on source code and configuration files.

An alleged directory inventory spans 494 folders and over 1,300 archive containers, with claimed HR data touching Australia, China, Canada, and the UK — 213,084 records, though how many real people that represents is anyone's guess.

Everest reportedly set an unconfirmed deadline of October 28.

That is the claim. Now comes the part most headlines skip: the claim is unverified. PwC hasn't responded. No one has independently confirmed the breach, the access method, whether anything was encrypted, or whether any of this data is real. Two respected trackers — Hackmanac and CTIWatch — documented the listing itself, and ransomware.live indexed it. But a listing on a leak site is a threat actor's advertisement, not a coroner's report. Reporting this as a confirmed breach would be wrong, so I won't.

And that distinction is the story. Because even as an unproven claim, this listing teaches something important.

Everest is worth a footnote first. The group has run this play before — leak-site pressure campaigns, sometimes without the classic ransomware encryption event at all. Previous technical analyses found that some Everest samples didn't even contain built-in data-theft tooling, which raises the obvious question: when there's no malware to exfiltrate with, what exactly was "stolen," and how? Extortion groups learn fast — and one thing they've learned is that the claim itself does half the work.

Now look closer at what's allegedly inside, and one directory name jumps out: pwc-stg.csod.com. That's not a PwC server — that's a staging tenant on Cornerstone OnDemand, the learning-management platform companies use for HR training. One analyst tracker flagged this explicitly: the material may come from a third-party SaaS environment, or an export of one, rather than from PwC's core network. That is an inference, not a confirmed fact — but it's a telling one.

Think about what that means. The most sensitive corporate data doesn't always live where the security team watches. It lives where the people are — in the HR portal, the training platform, the staging tenant someone spun up two years ago and forgot about. The crown jewels in this alleged haul weren't server passwords: they were audit methods, SSO configs, HR records. The keys to the identity kingdom, sitting in a learning-management system.

So where does that leave the rest of us? Honestly, as someone studying for a career in this field, the part that sticks with me isn't the 590 gigabytes — it's the directory name. pwc-stg.csod.com. It's a reminder that the perimeter you think you have and the perimeter you actually have are two different things. Your threat model probably covers your servers and your VPN. Does it cover the HR training platform? The staging tenant? The SaaS app your admin team signed up for with a corporate email three years ago?

The PwC listing may turn out to be real, exaggerated, recycled, or flat-out wrong. We'll know more by that alleged October 28 deadline — or we won't, if silence is the answer. Either way, the takeaway stands: audit your SaaS shadow, because the attackers are.

Not in a browser. In a server-side library called Onigmo — the Ruby regex engine GitLab bundles — quietly turning patterns into executable matching code millions of times a day. Every self-managed GitLab instance since version 7.0, released in 2014, carried it. And buried in that compilation step was a flaw GitLab now rates the maximum severity a vulnerability can hold: CVSS 10.0.

On October 21, 2026, GitLab shipped out-of-band patches for CVE-2026-110264. "Out-of-band" is the word companies use when something is bad enough that it can't wait for the scheduled release. This one was: an unauthenticated attacker — no account, no login — could, in the right conditions, compile a specially crafted regular expression and get arbitrary code execution on the GitLab server. Running as the git user. On your source code platform. The one holding your company's secrets.

Take a second with that. Not a misconfiguration. Not a phishing email. A regex — the humble text-matching pattern you wrote in every coding tutorial you've ever done — becoming a remote control for the server.

How a pattern becomes a foothold

The mechanics are ugly in a specific, satisfying way. GitLab's advisory describes the root cause as "an integer overflow during the compilation of a specially crafted regular expression." Independent analyses of the attack chain describe a route through org-ruby's TODO-keyword parsing: feed Onigmo a repeat count above 32,767, and a signed 16-bit integer rolls over like an odometer. That overflow produces an out-of-bounds memory write — and from there, code execution.

If "integer overflow" sounds abstract, think of it as a counting error. Onigmo counted on its fingers, but it only had 16 bits of fingers. Ask it to count past 32,767 and it starts writing into memory it was never given permission to touch. One researcher's crafted pattern turned that arithmetic bug into a root shell on the repository server.

Which is worth pausing on, because it upends the mental model most of us have. A regex engine shouldn't be dangerous. It's not network code, not auth code — it's string matching, the most boring utility on the planet. But when a boring utility runs on the server with the privileges of the git user, "boring" stops mattering. Anything that executes attacker-influenced input on your infrastructure is load-bearing, and Onigmo was quietly load-bearing for twelve years.

The researcher who wouldn't stop

Here's the part that reads like a thriller. CVE-2026-110264 isn't joaxcar's first report to GitLab — it's the fourth, in about a month. The same researcher, reporting via HackerOne, filed Onigmo RCE reports on September 23 and October 12 (three in a single week at one point). Each one a code-execution flaw in the same regex surface.

That streak tells a story of its own. This wasn't four lucky finds. This is what a systematic audit looks like from the outside — one researcher deciding a widely-deployed surface hasn't been looked at hard enough, and methodically dismantling it, report by report. The bug class was never "fixed" because nobody had actually finished looking.

And there's a sting in the timeline: admins who scrambled to apply GitLab's October 12 emergency patch for CVE-2026-97229 — the sibling Onigmo flaw — are still fully exposed to this one. They patched the hole they were told about and walked back past the one nobody had mentioned yet. The patch was real; the door wasn't closed.

Who's actually exposed

Some important scoping, because panic without precision helps nobody. GitLab.com already runs the fixed version. GitLab Dedicated tenants on the recent internal releases are covered too. The exposure is self-managed operators — the people running their own GitLab servers — and only until they upgrade to the fixed branches (19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13). As of writing, the CVE isn't in CISA's Known Exploited Vulnerabilities catalog, and GitLab hasn't described the exact preconditions for exploitation or confirmed any in-the-wild abuse. GitLab's advisory offers no interim workaround — the patch is the only certain protection.

The lesson

Security teams keep lists of "the attack surface" that feature firewalls, VPNs, and mail gateways. Then a regex compiler on the internal code server gets a 10.0.

The practical lesson isn't "audit your regex engines" — though this week, it literally is. It's that your threat model is wrong about which code is boring. The components nobody reviews are precisely the ones that accumulate the oldest, simplest bugs: a 16-bit counter in a string library, sitting untouched since 2014, finally audited by a stranger who decided to count past 32,767.

So the question for anyone running infrastructure this week: which of your "boring" components would earn a 10.0 if someone actually looked?