What happened
At its peak, a single operator launched more than 105 attack projects in one week. The agents didn't just scan for known vulnerabilities: they handled reconnaissance, found exploitable weaknesses, escalated to admin access, deployed payment skimmers, and exfiltrated data, largely without human intervention. Most compromises took hours. Some took a single day. The human behind it all appears to have done little more than issue brief instructions between runs.
The damage adds up fast: over 600,000 stolen card records from two companies, 27-plus retailers compromised in a five-day window, and skimmers confirmed live on 19 sites, with more than 100 additional infections detected. Total attacker cost across hundreds of targets: somewhere between $12,000 and $18,000. In one case, the agent's own cleanup routine malfunctioned and deleted 180 database tables, including the victim's backups. An accident, not even a deliberate act of destruction.
How they got in
The attack chains varied target to target, which is itself the point: these weren't scripted, single-technique intrusions. Vectors included SQL injection paired with MFA bypass, arbitrary file uploads leading to remote code execution, privilege escalation through sudo misconfigurations, and credential theft from AWS Secrets Manager. Skimmers went in through at least eight different methods, including poisoned S3 buckets and modified Kubernetes deployments. The agents adapted to whatever each target's environment actually looked like.
Why this changes the math
For years, the working assumption in enterprise security has been that attacker cost is a natural filter. Sophisticated, targeted attacks are expensive to run, so most organizations could reasonably bet they weren't worth the effort unless they were a high-value target. That assumption no longer holds. When compromising a retailer costs about the same as a lunch order and takes less time than a lunch break, cost stops filtering anything. Scale becomes cheap, and patch timelines measured in weeks are now competing against exploitation measured in hours.
That's the real shift seen in this report. It's not a new vulnerability class. It's a new economics of attack, and it means resilience and rapid containment now matter as much as patch speed, maybe more.
Where virtual patching fits
This is precisely the gap virtual patching is built to close. Instead of waiting on a CVE, a vendor fix, or a signature update, virtual patching enforces a known-good baseline directly at the kernel: the specific processes, files, and configuration changes a system should ever execute. Remote code execution from an arbitrary file upload, privilege escalation through a sudo misconfiguration, an unauthorized change to a Kubernetes deployment, all of these are, at bottom, unauthorized actions on a host. Virtual patching blocks them at the point of execution, regardless of whether that exact exploit chain has ever been documented before. That matters enormously against an attacker chaining together whatever works, on whatever timeline an AI agent can operate on.
Virtual patching earns its place as the layer that holds when everything upstream of it doesn't, which is exactly the scenario this report describes: a vulnerability nobody caught yet, exploited faster than any patch cycle could respond.
For a CISO evaluating security software right now, that's the actual question worth asking any vendor: not "how fast is your patch cycle," but "what happens in the hours before there's a patch at all."
Frequently Asked Questions
What is virtual patching, and how is it different from a traditional patch?
+A traditional patch is code the vendor rewrites to close a specific vulnerability, and it only exists once the vendor has identified the flaw and shipped a fix. Virtual patching doesn't touch the vendor's code at all. It enforces a known-good baseline at the kernel so that whatever behavior the exploit depends on, an unauthorized file write, an unexpected process launch, gets blocked at the moment it's attempted, whether or not a real patch exists yet.
Does virtual patching require a CVE or a vendor fix to be effective?
+No. That's the core of what makes it useful against a campaign like the one Gambit documented. The enforcement question is simply whether an action is authorized on that system, not whether it matches a known signature or a published vulnerability. Coverage holds even for zero-days with no assigned CVE.
How is this different from EDR or a WAF?
+EDR and WAFs generally work by recognizing patterns, known bad signatures, anomalous behavior, malicious payloads, which means they're strongest against attacks that resemble something seen before. Virtual patching doesn't try to recognize an attack at all. It only asks whether a given action falls inside what that specific system is authorized to do, so it doesn't need the exploit to look like anything previously catalogued.
Does this actually hold up against adaptive, AI-driven attacks, or just known exploits?
+This is where it matters most, not least. An AI agent chaining together whatever vulnerability works on a given target is exactly the case where signature and pattern-based tools fall behind, since the exploit chain itself is often novel even if the underlying flaw isn't. Enforcement based on authorized behavior rather than known attack patterns doesn't care whether the chain in front of it has ever been seen before.
What does it take to deploy this compared to a standard patch management program?
+Patch management is a continuous, resource-heavy cycle: track CVEs, test fixes, schedule maintenance windows, hope nothing breaks. Virtual patching is closer to a one-time baseline definition per system, after which enforcement runs continuously without waiting on a testing or release cycle. It's meant to sit alongside patch management, not replace the discipline of eventually applying the real fix.
