Eight seconds. That is how long it took a human attacker, working manually rather than through some automated exploit kit, to go from a remote code execution flaw in the tool Marimo to a live session on an SSH bastion inside the target's network. Not eight hours. Not eight minutes. Eight seconds, reported by The Hacker News as a demonstration of what "attack chains, not attack surfaces" actually means in practice: one flaw opens a door, and the attacker is already through the next three before anyone would think to look.

This is the number worth sitting with, because it quietly retires an assumption a lot of marketing and creative operations still run on: that there is a gap between something going wrong and something going badly wrong, and that gap is where the review process, the monitoring dashboard, or the "we'll catch it in QA" plan is supposed to live.

The gap wasn't a design choice, it was a delay we got used to

For years, "patch quickly" was good advice precisely because there was usually a window between a vulnerability going public and someone weaponising it. Teams built entire operating models around that window: monitor first, patch on a cadence, review changes before they ship, catch anomalies in the logs after they ship. Apple's own iOS 27 and macOS Golden Gate 27 releases patched around 200 vulnerabilities in one go, which tells you plainly how much surface exists to exploit even in software built by one of the best-resourced security organisations on earth. The window used to be where you dealt with that backlog safely.

The window is what's disappearing. A Fortinet vulnerability was used to compromise a Thai broadband provider. CISA confirmed a critical VMware remote code execution flaw is now being actively used by ransomware gangs, not theoretical, not "patch when convenient." A mass-scanning campaign is currently working through exposed Vite development servers, pulling cloud credentials out of instances that teams spun up for a project and forgot were public. None of these are sophisticated, bespoke attacks aimed at one target. They're scanning campaigns and chained exploits aimed at whoever left the door open, and the time from "door found" to "credentials taken" is not measured in review cycles anymore.

Marketing runs more exposed infrastructure than it thinks it does

It is tempting to read all of this as a problem for security teams and move on. It isn't. Every campaign microsite, every custom landing page, every martech plugin, every dev or staging server spun up for a personalisation test is a piece of infrastructure with the same exposure as anything in a security team's inventory, except it usually isn't in that inventory at all. Marketing and creative teams build and deploy code constantly now, often through agencies, often through platforms nobody centrally tracks, often left running after the campaign that justified it has ended.

The AI layer makes this worse, not better. OpenAI is currently investigating a report linking its AI agents to a RubyGems supply chain attack, which is a preview of a problem that's about to be everywhere: AI agents that write, install, and run code on a team's behalf, pulling in dependencies nobody manually reviewed. If your content team, your dev partner, or your agency is using agentic tools to build things faster, you have inherited a supply chain you didn't audit, running on infrastructure you didn't inventory, with a compromise window measured in seconds rather than sprints.

"Ship and monitor" was already a bet, now it's a bad one

"Ship and monitor" always meant: we accept some risk at launch because we can catch and fix problems after the fact. That bet only pays off if the fixing happens faster than the exploiting. When Japan's Digital Agency suffered a breach affecting 240,000 people, the damage was already done by the time anyone was reviewing logs. Monitoring after the fact is a valuable practice for understanding what happened. It is not a defence against something that completes in eight seconds.

The uncomfortable part for marketing organisations specifically is that "ship and monitor" is often not even a deliberate risk decision, it's just the default that happens when nobody owns security review for marketing-built infrastructure. Nobody chose to leave a dev server exposed. Nobody signed off on the AI agent's dependency list. It shipped because shipping was the plan, and monitoring was the thing everyone assumed would catch problems later. When later doesn't exist, "we'll monitor it" stops being a plan and becomes the explanation you give after the fact for why there wasn't one.

What actually has to change

  • Treat every exposed dev, staging, or campaign server as production, because attackers already do. The Vite scanning campaign didn't distinguish between "real" infrastructure and a landing page someone forgot about.
  • Inventory what marketing and agencies have actually deployed, not what IT thinks has been deployed. Plugins, microsites, forms, chat widgets, and AI-agent-built code all count.
  • Audit dependencies introduced by AI coding agents the same way you'd audit a new vendor contract. The RubyGems incident shows this is not hypothetical.
  • Move review before deployment, not after. A patch cadence that assumes days of grace no longer matches an exploit cadence measured in seconds.
  • Reduce standing access rather than betting on detecting misuse of it. The eight-second attack succeeded partly because a path to an SSH bastion existed at all, not because monitoring failed to notice it fast enough.

None of this requires becoming a security organisation. It requires admitting that "we'll catch it later" was never a defence, it was a description of a gap that used to exist by accident. The gap is closed. The plan built around it needs to be too.