Attackers Now Measure Time In Seconds
The security industry still publishes patch cycle statistics measured in days, while a researcher recently demonstrated that a full compromise, from exploiting a vulnerability to reaching an internal SSH bastion host, took eight seconds. This piece argues that the gap between disclosure and exploitation has collapsed past anything the current reporting conventions can describe, drawing on a Fortinet flaw used to breach a Thai broadband provider, a VMware remote code execution bug now weaponised by ransomware gangs, a mass-scanning campaign against exposed Vite development servers, and Apple's own admission that it needed to patch 200 vulnerabilities in one release cycle, to make the case that testing attack surfaces one technique at a time, and reporting defence in days, is no longer a serious response to attackers who now work in single-digit seconds.
Listen to this piece 7 min
Eight seconds. That is how long it took a human attacker, working manually rather than through automation, to exploit a remote code execution flaw in Marimo and land on an internal SSH bastion host. Not eight hours. Not eight minutes. Eight seconds from vulnerability to a foothold deep enough to pivot from. Meanwhile the trade press, the vendor advisories, and most internal security programmes still report their defensive posture in days: mean time to patch, mean time to detect, mean time to respond. Those units were never fast enough to matter and now they are not even the right units to be arguing about.
The eight-second benchmark
The Marimo case matters less for the specific tool than for what it proves about the ceiling on attacker speed. A skilled human, without the benefit of a pre-built automated exploit chain, reached a bastion host in eight seconds. That is the new floor, not the exception. Anyone still designing defences around the assumption that there is a meaningful window between "vulnerability disclosed" and "vulnerability exploited" is designing for a threat model that no longer exists.
Set that timing next to the argument BleepingComputer laid out in What Zero-Day Response Should Be in the Post-Mythos Era, and the old sequence falls apart. That sequence assumed disclosure, then patch development, then patch deployment, and only after all that, if an organisation was slow, exploitation. Marimo shows the order has flipped. Exploitation can now finish before most organisations have even opened the advisory, let alone tested and shipped a fix.
Patch windows measured in the wrong units
Look at what has actually happened in the field this cycle, not in a lab. A Thai broadband provider was breached via a Fortinet vulnerability. CISA confirmed that a critical VMware remote code execution flaw is now being actively used by ransomware gangs, not held in reserve by a handful of sophisticated actors but already folded into criminal tooling. A mass-scanning campaign is exploiting a Vite flaw specifically to extract cloud credentials from exposed development servers, an attack that does not require a targeted operator at all, just infrastructure that scans continuously and harvests whatever answers.
None of these are exotic. They are the ordinary, mechanical exploitation of known flaws in widely deployed software, happening at a pace that makes "time to patch" a nearly meaningless metric to report. A patch cycle measured in days assumes attackers are also working on a cycle measured in days. They are not. The Vite scanning campaign in particular illustrates the point: it does not wait for a specific target to be worth the effort, it scans everything, continuously, and takes whatever credentials fall out.
Apple's own release cycle underlines the scale problem sitting underneath the speed problem. iOS 27 and macOS Golden Gate 27 shipped together patching 200 vulnerabilities. Two hundred is not a number that supports a "patch quickly" strategy on its own terms; it is a number that describes an attack surface so large that speed of patching was never going to be the variable that saved anyone. Volume and velocity are now working against defenders at the same time, and most reporting still treats them as separate problems.
Chains, not surfaces
There is a methodological argument buried in this that the industry keeps avoiding. Attack Chains, Not Just Attack Surfaces: Why Testing Individual Techniques Misses the Point makes the case directly: testing whether a single technique works in isolation tells you almost nothing about whether an attacker can string several together into a working compromise in the time it takes to notice. The Marimo bastion breach was not a single technique tested and cleared. It was a chain, executed in eight seconds, and a security programme that had validated each individual step as "low risk" on its own would have missed the combined result entirely.
The supply chain is not exempt from this either. OpenAI is investigating a report linking its AI agents to an attack on RubyGems, the Ruby package repository that a large share of web development depends on. Whether or not that specific link holds up under investigation, the direction is clear: AI agents are now plausible actors inside software supply chain attacks, not just tools defenders use to detect them. China's spy chief has separately pointed at US AI models as a cyber threat concern, which is worth noting less for the geopolitical framing than for the admission it contains, that state-level threat assessment has already moved past treating AI as a defensive curiosity and started treating it as an offensive capability worth naming in public.
What "response" has to mean now
Some of the week's other stories look unrelated to this at first glance, but they belong in the same accounting. Japan's Digital Agency disclosed a breach affecting 240,000 people. The Manhattan DA took down 12 AI deepfake porn sites, a reminder that AI-enabled abuse is already being prosecuted as ordinary crime, not treated as a hypothetical future problem. Suspected leaders of the Black Axe gang now face cybercrime charges in the US. None of these require exotic zero-days; they require organisations and platforms that were slow enough, for long enough, that a chain of ordinary failures added up to a full breach or years of criminal operation. Speed of exploitation and scale of consequence are the same story told from opposite ends.
Schneier's recent pieces, on 25 years of mass surveillance and on the NSA's 1960s supercomputer, are worth reading alongside all of this for a different reason: they are a record of how long institutions can keep operating on assumptions that have quietly stopped being true. Mass surveillance infrastructure built decades ago outlived the justifications used to build it. Patch cycle metrics built for a slower internet are heading the same way, and the eight-second Marimo compromise is the clearest evidence yet that they have already arrived.
None of this argues for panic. It argues for changing what gets measured. An organisation that can report its mean time to patch in days but cannot describe how its systems would hold up against a chained exploit executed in single-digit seconds is not measuring its actual exposure, it is measuring a number that used to matter and has kept the habit going out of convenience. The attackers moved on from that number. The reporting should too.
Wyre's opinion bylines are editorial personas of Floof Digital LLC, not separate members of staff. Essays are produced with AI assistance under human editorial direction. How Wyre works.