GreyNoise just gave the PaperCut chain (CVE-2026-82078/81578) a scale I didn't see coming when I wrote it up three weeks ago at Huntress's two confirmed environments. AI-orchestrated actors, Codex tooling running a DeepSeek model, are now at 440 instances across 395 orgs, domain admin at twelve. That's automation outpacing patching, not just detection. What's the actual patch rate on the ~1,000 exposed instances now?
Appreciate the added context. I don’t have a verified current patch rate to share, but I’d want that alongside the exposure numbers. The other piece is how many organizations have checked for prior compromise. Getting patched and establishing whether an attacker already got in are separate jobs.
Three weeks live on a stolen key is the number that matters more than the attack tooling. That's not a failure to catch the theft, it's a failure to ever check whether the key's usage pattern still matches the account it belongs to. I've been writing about the same gap at What Breaks, a valid, correctly scoped credential passes every access check by design, so the catch has to be behavioral, not authorization based. Three weeks says most environments still aren't running that check.
Good point on monitoring how valid credentials are being used, Amit. The operational piece is what happens after unusual usage gets flagged. Someone still needs to identify the owner, investigate the activity, and make the call to revoke the key. That handoff from detection to action deserves more attention.
The real bottleneck in that handoff is usually that nobody has pre-agreed whose call it is. The flag sits in a queue because revoking a key someone else provisioned feels like a decision that needs to be escalated, and escalation is where the three weeks happens. The fix isn't adding more people to the investigation step, it's a pre-authorized threshold: past a certain deviation score, the key gets revoked automatically and the investigation happens after, on a system that's already contained.
Agreed on deciding who can pull the plug before an incident. Where I’d be careful is revoking a production key purely on a deviation score. What it powers and confidence in the detection should factor into that call. Pre-authorize the response, absolutely—but define those guardrails upfront too.
Fair, a flat deviation threshold treats a read only reporting key the same as one that can move money or rotate other credentials, and that's the part that has to be pre defined rather than judged in the moment. Set the auto revoke bar per key at provisioning time based on blast radius, low reach keys revoke fast and cheap, high reach keys need a higher confidence score or a human in the loop before the plug gets pulled. The guardrail isn't one number, it's a table keyed to what each credential actually touches.
GreyNoise just gave the PaperCut chain (CVE-2026-82078/81578) a scale I didn't see coming when I wrote it up three weeks ago at Huntress's two confirmed environments. AI-orchestrated actors, Codex tooling running a DeepSeek model, are now at 440 instances across 395 orgs, domain admin at twelve. That's automation outpacing patching, not just detection. What's the actual patch rate on the ~1,000 exposed instances now?
Appreciate the added context. I don’t have a verified current patch rate to share, but I’d want that alongside the exposure numbers. The other piece is how many organizations have checked for prior compromise. Getting patched and establishing whether an attacker already got in are separate jobs.
Three weeks live on a stolen key is the number that matters more than the attack tooling. That's not a failure to catch the theft, it's a failure to ever check whether the key's usage pattern still matches the account it belongs to. I've been writing about the same gap at What Breaks, a valid, correctly scoped credential passes every access check by design, so the catch has to be behavioral, not authorization based. Three weeks says most environments still aren't running that check.
Good point on monitoring how valid credentials are being used, Amit. The operational piece is what happens after unusual usage gets flagged. Someone still needs to identify the owner, investigate the activity, and make the call to revoke the key. That handoff from detection to action deserves more attention.
The real bottleneck in that handoff is usually that nobody has pre-agreed whose call it is. The flag sits in a queue because revoking a key someone else provisioned feels like a decision that needs to be escalated, and escalation is where the three weeks happens. The fix isn't adding more people to the investigation step, it's a pre-authorized threshold: past a certain deviation score, the key gets revoked automatically and the investigation happens after, on a system that's already contained.
Agreed on deciding who can pull the plug before an incident. Where I’d be careful is revoking a production key purely on a deviation score. What it powers and confidence in the detection should factor into that call. Pre-authorize the response, absolutely—but define those guardrails upfront too.
Fair, a flat deviation threshold treats a read only reporting key the same as one that can move money or rotate other credentials, and that's the part that has to be pre defined rather than judged in the moment. Set the auto revoke bar per key at provisioning time based on blast radius, low reach keys revoke fast and cheap, high reach keys need a higher confidence score or a human in the loop before the plug gets pulled. The guardrail isn't one number, it's a table keyed to what each credential actually touches.