Afleveringen
-
In this episode, Sherri and Matt discuss JADEPUFFER — the first publicly documented ransomware operation executed end-to-end by an AI agent. According to Sysdig Threat Research, the AI drove the whole intrusion: reconnaissance, exploitation, lateral movement, and extortion. It fixed its own failed attacks in 31 seconds, fired off 600+ payloads, and encrypted 1,342 database records — yet it also narrated its crimes in plain English and demanded ransom to a hallucinated Bitcoin address. Fast AND flawed: an amateur hacker operating at machine speed.
Sherri and Matt trace how we got here — from PromptLock to criminal “vibe hacking” — and what machine-speed adversaries mean for your incident response, your threat model, and your Monday-morning to-do list.
Key Takeaways:
1. Inventory your AI attack surface. Ask which of your vendors' and internal AI tools are internet-facing and unpatched — JADEPUFFER walked in through a known, long-patched Langflow vulnerability.
2. Reset your incident response expectations. Adversaries can now adapt in seconds, not hours. Human-paced SLAs are no defense against a 31-second fix loop — invest in automated detection and containment.
3. Widen your threat model. The skill floor has collapsed. Adaptive, competent attacks can now come from completely unsophisticated actors armed with an AI agent and a target list.
4. Add AI-driven attack scenarios to your next tabletop exercise — and decide in advance who can authorize automated containment, because you won't have time to convene a meeting mid-attack.
References:
1. Sysdig — JADEPUFFER: Agentic Ransomware for Automated Database Extortion (https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion)
2. BleepingComputer — JADEPUFFER ransomware used AI agent to automate entire attack (https://www.bleepingcomputer.com/news/security/jadepuffer-ransomware-used-ai-agent-to-automate-entire-attack/)
3. The Hacker News — AI agent exploits Langflow RCE (https://thehackernews.com/2026/07/ai-agent-exploits-langflow-rce-to.html)
4. NVD — CVE-2025-3248 (Langflow unauthenticated RCE) (https://nvd.nist.gov/vuln/detail/CVE-2025-3248)
5. ESET — PromptLock, the first AI-powered ransomware (NYU proof-of-concept) (https://www.eset.com/us/about/newsroom/research/eset-discovers-promptlock-the-first-ai-powered-ransomware/)
6. Anthropic — Detecting and countering misuse (vibe hacking / GTG-2002) (https://www.anthropic.com/news/detecting-countering-misuse-aug-2025)
7. Anthropic — Disrupting AI espionage (GTG-1002) (https://www.anthropic.com/news/disrupting-AI-espionage)
-
The Rocky Mountain Information Security Conference just celebrated its 20th anniversary in Denver — and the anniversary edition told us exactly where the industry's head is at. In this quick-hit recap, Matt Durrin and Todd Stewart break down the biggest themes from three days at the Colorado Convention Center: agentic AI moving into the SOC (and the “circuit breaker” conversation about how to rein it in), state-level AI regulation getting real with the Colorado AI Act and updated CCPA audit rules, and deepfake extortion graduating from awareness slides to full tabletop simulations — including LMG's own hands-on deepfake extortion lab from the conference floor. Plus: post-quantum jitters, CMMC 2.0 lessons from the assessment trenches, the 31% attrition problem, and five actionable takeaways for IT and security leaders.
Key Takeaways for Leaders
1. Put a leash on your AI agents before they need one. If you're deploying agentic AI in the SOC or business workflows, define kill switches, escalation thresholds, and human-approval gates now. The circuit-breaker conversation at RMISC made clear that rollback plans are being written after incidents, not before.
2. Inventory your shadow AI. Employees are already wiring AI agents and coding assistants into production workflows without approval. Run a discovery exercise this quarter — you can't govern what you haven't found.
3. Treat AI regulation as a state-level problem, not a federal one. The Colorado AI Act and updated CCPA audit requirements were front and center. Map which state laws touch your operations and assign ownership — waiting for federal harmonization is a losing bet.
4. Exercise deepfake extortion before it happens to you. Deepfake-driven fraud and extortion have graduated from awareness-slide material to tabletop scenarios. Add one to your next IR exercise cycle — including verification protocols for voice and video requests involving executives and payments.
5. Budget for retention, not just recruitment. With cybersecurity attrition cited at 31%, the cheapest hire is the analyst you don't lose. Burnout mitigation, career pathing, and realistic on-call rotations are now security-resilience line items, not HR nice-to-haves.
Resources & Links
1. RMISC (Rocky Mountain Information Security Conference): www.rmisc.org
2. LMG Security — training, tabletop exercises, and research: www.lmgsecurity.com
3. Related episode: “Poisoned on Open: When Looking at the Code Is the Attack” — our deep dive on the Miasma supply-chain worm
Connect With Us
Enjoyed the episode? Subscribe to Cyberside Chats wherever you get your podcasts, and share it with a colleague who's wrestling with AI governance. Questions or topic suggestions? Reach out to the LMG Security team at www.lmgsecurity.com
-
Zijn er afleveringen die ontbreken?
-
Vibe coding is everywhere now and a new worm is built to exploit it. Whether it's your IT staff spinning up a handy new tool or the software vendor you rely on, the moment someone opens AI-generated or downloaded code in an assistant like Cursor or Claude Code, it strikes, no install, no "run" required. In its nastiest move, this worm, known as Miasma, talks the AI itself into running the attacker's payload. This isn't theoretical: in June 2026 it breached Microsoft's own code, compromising repositories across its Azure organizations, and GitHub scrambled to shut down 73 of them in under two minutes. One compromised machine can hand an attacker cloud keys, tokens, and a foothold into everything downstream — yours or a vendor's.
Join Sherri Davidoff and Matt Durrin for why this new "execute on open" tactic breaks years of supply-chain defense assumptions, how it turns AI coding tools into the attacker, and the questions every security leader should be asking Monday morning — plus live Q&A.
Key Takeaways
1. Recognize that simply opening code can now trigger an attack. For years the rule was "don't run untrusted code" — but this worm executes the instant a repository is opened in an editor or AI coding tool, before anyone installs or runs anything. Opening code is no longer a passive, look-only act. Make sure your teams know that browsing or opening an unfamiliar repository can itself launch malware, and that anyone reviewing outside code should do it in an isolated or sandboxed environment rather than on a machine holding live credentials.
2. Govern your AI coding tools like the privileged software they are. AI coding assistants can now be tricked into running an attacker's code on a developer's behalf. These tools have largely entered organizations without policy, review, or oversight. Set expectations for which AI coding tools are approved, what they're permitted to do automatically, and who owns that decision — the same way you'd govern any tool with access to credentials and systems.
3. Assume one compromised developer equals a foothold in your environment. A developer's machine holds cloud keys, tokens, and publishing rights — compromise one and an attacker can reach everything downstream, including your customers. Confirm that developer and build-system credentials are scoped, short-lived, and monitored, and that your incident response plan treats a single developer compromise as a potential enterprise event, not an endpoint cleanup.
4. Extend third-party risk past vendors to the code your people pull in daily. Most programs assess software vendors and ignore the open-source packages employees install — which is exactly where this attack lives. Ask whether a poisoned package would be caught before credentials walked out, or only after.
5. When credentials are exposed, demand complete rotation — and proof. This same attacker hit Microsoft twice in a month because the credentials from the first incident weren't fully cleaned up. After any exposure, the expectation should be that every credential tied to that identity is rotated and the old ones confirmed dead — not "we changed the password." Partial remediation is an open invitation to be hit again.
Resources
1. OpenSourceMalware — first report of the Microsoft compromise: https://opensourcemalware.com/blog/miasma-reaches-azure
2. StepSecurity — Miasma forensic analysis: https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-again-azure-functions-action-and-72-other-repositories-disabled-after-supply-chain-attack-targeting-ai-coding-agents
3. The Register — GitHub disables Microsoft repos; Microsoft later restored them: https://www.theregister.com/security/2026/06/08/github-nukes-70-microsoft-repos-amid-suspected-worm-attack/5252169
4. The Hacker News — Miasma worm hits 73 Microsoft repositories: https://thehackernews.com/2026/06/miasma-worm-hits-73-microsoft-github.html
5. Socket — Shai-Hulud descends to Hades (PyPI wave): https://socket.dev/blog/shai-hulud-descends-to-hades-miasma-worm-pypi-wave
-
Hackers didn’t breach Meta’s systems, they just asked. In this episode, we break down the Meta AI hack, where attackers used a VPN and a politely worded chat message to convince Meta’s AI support agent to hand over more than 20,000 Instagram accounts, including the dormant Obama White House account and the personal account of a senior Space Force leader. No malware, no phishing, no exploit code.
We flash back to the 2023 MGM Resorts attack to show how this fits one of the fastest-growing attack trends of recent years — social-engineering the help desk — now aimed at the AI agents replacing human help desks, minus the suspicion we’ve trained into people. We also connect it to the wider wave of attacks targeting AI agents, from zero-click prompt injection in Microsoft 365 Copilot to the PocketOS rogue-AI-agent disaster, and explain why the first real AI security crisis isn’t superhuman AI attackers — it’s ordinary AI agents with too much permission and no ability to be suspicious. Finally, we share five concrete steps to vet and constrain AI agents before they become your soft target.
Key Takeaways:
1. Red-team AI agents before they touch production workflows. Treat deployment like a hire: the background check is adversarial testing. If an agent can change account state — emails, passwords, payments — someone must try to talk it into doing so maliciously before launch, the same way you phish-test your staff. The Meta exploit was the first test anyone would write.
2. Stage permissions like a probation period. New agents start advisory and read-only. Write permissions come later, narrowly, after monitored performance — and account recovery is the last workflow to automate, not the first, because it is the highest-value target in your environment. Meta granted end-to-end authority on day one.
3. Enforce identity verification in deterministic code, not in the model. The agent can request a recovery-info change; it must never approve one. Step-up verification (re-authentication, hardware key, code to the verified channel on file) belongs in the API layer, where no amount of persuasion can waive it. Prompts are advisory — the PocketOS agent quoted its own rules while violating them.
4. Scope every credential and action an agent can reach. Least privilege per task: an agent that answers support questions doesn’t need email-change rights; a coding agent’s token shouldn’t reach production or backups. An agent’s blast radius is what it can ingest, what it can access, and what it can do — audit all three before attackers map them for you.
5. Keep a human escalation path that the agent can’t lock. Meta’s automation removed both the suspicious human who would have questioned the request and the human a victim could appeal to afterward. Mandate an out-of-band recovery route — one the agent has no permissions to modify — before automating any account-security workflow.
Resources:
1. 404 Media: Hackers Simply Asked Meta AI to Give Them Access to High-Profile Instagram Accounts. It Worked. https://www.404media.co/hackers-simply-asked-meta-ai-to-give-them-access-to-high-profile-instagram-accounts-it-worked/
2. MIT Technology Review: The Meta Hack Shows There’s More to AI Security Than Mythos. https://www.technologyreview.com/2026/06/05/1138437/the-meta-hack-shows-theres-more-to-ai-security-than-mythos/
3. TechCrunch: Instagram Is Alerting Users Who Were Targeted by Hackers During AI Chatbot Attacks. https://techcrunch.com/2026/06/03/instagram-is-alerting-users-who-were-targeted-by-hackers-during-ai-chatbot-attacks/
4. Silicon Republic: Hackers Stole More Than 20,000 Instagram Accounts Using Meta AI. https://www.siliconrepublic.com/enterprise/hackers-stole-more-than-20000-instagram-accounts-using-meta-ai
5. EchoLeak (CVE-2025-32711): Zero-Click Prompt Injection in Microsoft 365 Copilot — Case Study. https://arxiv.org/abs/2509.10540
-
Three days after Anthropic put its most powerful AI models in public hands, the U.S. government invoked export-control authority to bar foreign nationals from Fable 5 and Mythos 5. The result: Anthropic was forced to shut both models down for everyone, worldwide. We dig into what actually triggered the order, why the only outside expert known to have read the underlying report calls it an overreaction, and how the fight echoes the 1990s crypto wars, when Washington branded encryption software a weapon and investigated the people who shared it. For security leaders, we close on what to do about single-model dependencies, AI that can be talked into misbehaving, and a capability that's already global no matter what any export rule says.
Key takeaways for security leaders
1. Don't let a single AI model become a single point of failure. Fable 5 and Mythos 5 went from public launch to worldwide shutdown in three days — by government order, not an outage — and access dropped even for compliant US customers. If a business-critical workflow (AI code review, SOC triage, agentic automation) runs on a single model or provider, inventory it and build a fallback path now. Put model availability in your BC/DR and third-party risk register alongside any other critical vendor.
2. Assume any AI you deploy can be talked into doing something it shouldn't — and watch it accordingly. Even Anthropic says no provider can fully prevent its safeguards from being bypassed, and that new workarounds will keep being found. For most organizations the practical move isn't building better guardrails — it's logging what your AI tools and agents actually do, baselining normal behavior, and alerting on the abnormal. Treat vendor safeguards as one layer, not the whole control.
3. Leverage AI’s advanced capabilities to check for software bugs, both in code you buy and code you develop If you build software, fold AI-assisted review into your SDLC and red teaming. If you rely on third-party vendors for software, make their use of AI-assisted security testing a question in your due diligence and a clause in your contracts. Either way, the goal is to find the bugs attackers will find, first.
4. Update threat models to assume adversaries already have equivalent cyber-AI, regardless of export controls. The lesson from the crypto wars and the proliferation/distillation discussion is that a ban transfers a capability rather than eliminating it — the model, like the math before it, is already global. Don't let a US export action or one vendor's guardrails read as reduced adversary capability in your risk calculus. Plan defenses for a world where attackers have frontier bug-finding at machine speed.
Resources
1. Anthropic — Statement on the directive to suspend access to Fable 5 and Mythos 5 — the company's own account of the order and its safeguards. https://www.anthropic.com/news/fable-mythos-access
2. WSJ — Anthropic Dispatches Staff to D.C., Racing to Resolve AI Export Restrictions — the timeline, the players, and the weekend negotiations. https://www.wsj.com/tech/ai/anthropic-dispatches-staff-to-d-c-racing-to-resolve-ai-export-restrictions-71303d42
3. Luta Security — The Fable 5 Export Controls Harm US Cyber Defense — Katie Moussouris, the one outside expert known to have read the underlying report. https://www.lutasecurity.com/post/the-fable-5-export-controls-harm-us-cyber-defense
4. FreeFable.org — open letter to Commerce — 54 CISOs and security leaders calling for the controls to be lifted. https://freefable.org/
5. EFF — Bernstein v. United States — the case that established software source code as protected speech. https://www.eff.org/cases/bernstein-v-us-dept-justice
-
In this eye-opening episode of Cyberside Chats, Sherri Davidoff sits down with Tom Pohl, Director of Penetration Testing at LMG Security, to unpack a chilling new attacker technique: threat actors posing as recruiters, conducting real interviews, and delivering malicious coding challenges that infect candidates’ personal machines. What looks like a legitimate take-home coding test is actually malware that steals passwords, browser credentials, crypto wallets, SSH keys, and more, all before the candidate ever steps foot in your organization.
Tom shares how he discovered this campaign through a friend’s suspicious Bitbucket repo, walks through the malware’s behavior, and reveals real-time insights from probing the attackers’ command-and-control infrastructure.
This isn’t just a problem for job seekers, it’s a direct threat to your human supply chain. Compromised developers can bring stolen credentials, GitHub access, and persistent footholds straight into your environment.
Key Takeaways:
1. Go passwordless where possible or enforce unique passwords everywhere.
2. Require phishing-resistant MFA (and passkeys/hardware tokens) — ditch SMS.
3. Audit your passwords against known breach lists before the bad guys do.
4. Vet candidate security the same way you vet third-party vendors (antivirus/EDR, device sharing, security hygiene).
5. Bring hiring and onboarding into your security program — protect the entire human supply chain.
Whether you’re a job seeker trying to stay safe or a hiring manager responsible for your organization’s security posture, this episode will change how you think about the recruitment process.
Resources:
1. Download Tom’s full white paper with technical details on the LMG Security website (Resources section): lmgsecurity.com
-
It started with a phone call. No malware, no zero-day — just someone talking a Charter worker out of their login. Months later, 4.9 million customer records surfaced on a leak site, pulled from the company's Salesforce instance.
The CRM has become the richest target in enterprise security. Sherri and Matt break down why, and walk through three cases: Charter, where one vished login reached everything; the Salesloft Drift and Gainsight chain, where one stolen token unlocked the next breach and the next; and the Salesforce "Aura" campaign, where misconfigured guest accounts exposed hundreds of organizations — including, ironically, identity-protection company Aura. The throughline: Salesforce wasn't breached, the tenants were — and in every case, nobody was watching the data leave.
Key Takeaways
1. Govern your CRM as carefully as your email and file storage. You already wrap M365 or Google Workspace in conditional access, audit logs, and DLP. Your CRM holds data just as sensitive — give it the same controls.
2. Lock down who can log in. Enforce phishing-resistant MFA and verify identity before granting access — almost every CRM breach this year started with one compromised or socially-engineered login.
3. Least privilege limits the blast radius. One identity should never reach the entire instance, and a guest user should never touch live records. Provision for the job, not for convenience.
4. Inventory your connected apps and OAuth tokens, and revoke the ones that don't need access or can't be accounted for. Your perimeter now includes software you didn't write; a forgotten token walks straight past MFA and SSO.
5. Watch the exits, not just the entrance. Someone will always get in. Set export caps, alert on anomalous volume, and turn on the SaaS DLP you already own — almost nobody does.
Resources
1. Charter Communications data breach affects 4.9 million accounts — BleepingComputer's report on the Have I Been Pwned-verified count, including the 85,000 employee records. https://www.bleepingcomputer.com/news/security/charter-communications-data-breach-affects-49-million-accounts/
2. Charter confirms data breach after ShinyHunters extortion threat — The confirmation, the vishing-to-Entra-to-Salesforce attack path, and Charter's "no sensitive data" statement. https://www.bleepingcomputer.com/news/security/charter-confirms-data-breach-after-shinyhunters-extortion-threat/
3. ShinyHunters claims ongoing Salesforce Aura data theft attacks — The Experience Cloud guest-user campaign, the weaponized AuraInspector tool, and the 2,000-record bypass. https://www.bleepingcomputer.com/news/security/shinyhunters-claims-ongoing-salesforce-aura-data-theft-attacks/
4. Aura breach confirmed as over 900,000 customer records accessed — The identity-protection company caught in the Salesforce "Aura" campaign. https://www.techradar.com/pro/security/aura-breach-confirmed-as-over-900-000-customer-records-accessed-in-phishing-attack
5. Salesforce — Protecting Your Data: Essential Actions to Secure Experience Cloud Guest User Access — The vendor advisory with the concrete hardening steps (guest permissions, "API Enabled," org-wide defaults). https://www.salesforce.com/blog/protecting-your-data-essential-actions-to-secure-experience-cloud-guest-user-access/
-
Your organization is already running an AI workforce and almost nobody knows who they report to, what they can touch, or how to shut them down. In this episode, Sherri Davidoff and Matt Durrin break down the shadow AI agent problem: what makes an agent a "shadow" agent, how real breaches are already happening because of them, and what security leaders can do about it this week.
Using three case studies: Anthropic's Claude Dispatch as a canonical product example, the April 2026 Vercel breach (the cleanest illustration yet of the OAuth supply chain attack model), and Meta's internal Sev-1 incident (when the agent itself is the failure mode). Sherri and Matt walk through the four layers where shadow agents accumulate risk and close with five concrete, actionable takeaways for security teams at any size.
Key takeaways
1. Start with discovery, not policy. You can't govern what you can't see. The right question to ask your team isn't "are you using unauthorized AI tools?" — it's "what AI tools are you using to do your job?" Check OAuth grants in Google Workspace and Microsoft Entra, and look at expense reports. The real number of agents in your environment is typically two to five times what you initially find.
2. Audit and restrict OAuth scopes — especially "Allow All". The Vercel breach was enabled by a single broad OAuth grant an employee made during onboarding for a third-party AI productivity tool. Most enterprise Google Workspace and Microsoft 365 tenants allow users to grant full OAuth scopes to external apps with no admin review. Requiring admin approval for OAuth grants — and auditing existing ones — is a control that can be implemented today and would have prevented the Vercel incident. An OAuth token is as good as — if not better than — a username, password, and MFA combined. It gets you straight through the back door.
3. Treat AI tool agreements like vendor contracts — because they are. When an employee clicks Allow All on an AI tool's onboarding screen, they have created a vendor relationship on behalf of the organization — without a DPA, a BAA, a security review, or procurement involvement. Build a lightweight intake process specifically for AI tools, and make it faster than the OAuth click. If the approved path takes two weeks, employees will route around it. Aim for two days.
4. Get visibility at the identity layer. Machine identities already outnumber human identities by roughly 50:1 in enterprise environments. AI agents add more — fast. Look at purpose-built NHI management tools: Token Security, Astrix, Andromeda, and Entro. Microsoft Agent 365, launched May 2026, gives Microsoft ecosystem organizations a registry and map of agents in their environment — a quick starting point for visibility.
5. Build a fast lane for AI tool approvals. "Don't use shadow AI" is the wrong message. Employees will use these tools regardless — the goal is to make the sanctioned path faster than the shadow path. A lightweight checklist covering data sensitivity, OAuth scopes requested, and basic vendor security posture beats a heavyweight approval committee. Make the process visible, frame it as enablement rather than restriction, and you will get compliance.
The three flavors of shadow agent
1. The unsanctioned agent. An employee built it in Copilot Studio or ChatGPT. IT doesn't know it exists.
2. The sanctioned-but-invisible agent. The platform is approved, but nobody is tracking what each agent can access, who owns it, or what it's doing.
3. The granted-access agent. An employee authorized an outside AI tool via OAuth. An external agent is now operating inside your environment with your credentials.
References
1. Vercel breach https://vercel.com/kb/bulletin/vercel-april-2026-security-incident
2. Kiteworks 2026 Data Security and Compliance Risk Forecast https://www.kiteworks.com/cybersecurity-risk-management/meta-rogue-ai-agent-data-exposure-governance/
3. Cloud Security Alliance + Token Security survey (April 21, 2026) https://cloudsecurityalliance.org/press-releases/2026/04/21/new-cloud-security-alliance-survey-reveals-82-of-enterprises-have-unknown-ai-agents-in-their-environments
4. OpenAI — ChatGPT Workspace Agents https://openai.com/index/introducing-workspace-agents-in-chatgpt/
5. Salesforce FY26 Q4 earnings release (Feb 25, 2026) https://www.salesforce.com/news/press-releases/2026/02/25/fy26-q4-earnings/
6. Microsoft Copilot Studio — agent overview https://adoption.microsoft.com/en-us/ai-agents/copilot-studio/
7. Microsoft Agent 365 (launched May 2026) https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/unveiling-copilot-agents-built-with-microsoft-copilot-studio-to-supercharge-your-business/
-
65% of US doctors are using an AI tool their hospital never approved — on personal phones, under click-through contracts. Sherri and Matt unpack what every CISO and IT leader should learn from it about shadow AI, "free" professional tools, and the contracts nobody's reading.
The tool is OpenEvidence — 27 million clinical queries in April 2026 alone, 60% of them shaping actual treatment decisions. Doctors love it because the alternative was Googling patient symptoms on a personal browser. Their hospitals mostly don't know it's happening, and the vendor's click-through Business Associate Agreement authorizes them to use that data to train their models forever.
Healthcare is the example. The same pattern is showing up in legal, financial services, engineering, and HR right now — different tool, same structural risk. Tune in for five concrete takeaways security and IT leaders can use this week.
Key Takeaways:
Inventory shadow AI. Ask your staff what AI tools they use to do their jobs, not whether they're using unauthorized tools. The real number is likely 2–5x what you'll find.Read the actual contract before letting any AI tool touch sensitive data. Find the training-data clause, the termination clause, the audit rights, and who the "Customer" really is. Click-through BAAs don't protect the employer.Treat every AI prompt as a disclosure. Removing names doesn't make data safe. Combinations of attributes, dates, locations, roles, rare events, can re-identify people even without a name attached.Take a position on shadow AI and communicate it. Decide which tools your organization sanctions, which it blocks, and which fall in between. Silence is implicit endorsement.Push back on every "free" professional AI tool. Ask who's paying and what they're buying. If it's not you, the product is your professionals' decisions.Resources:
https://www.nbcnews.com/tech/tech-news/openevidence-ai-doctor-medical-physician-login-app-what-npi-uptodate-rcna341064https://www.healthcare.digital/single-post/clinical-intelligence-a-strategic-analysis-of-openevidence-and-the-multi-agent-medical-ai-ecosystemhttps://www.ama-assn.org/system/files/physician-ai-sentiment-report.pdf -
In this episode of Cyberside Chats, Sherri Davidoff and Matt Durrin break down what may be the largest education-sector data breach in history: the massive compromise of Canvas by Instructure. With more than 275 million records reportedly stolen and over 8,800 educational institutions impacted, the incident highlights the dangers of cloud concentration risk, where a single vendor breach can create a domino effect across an entire industry.
The discussion dives into the tactics allegedly used by the Shiny Hunters threat group, the risks of SaaS platform overreliance, and the troubling gap between vendor assurances and real-world containment. Matt and Sherri also explore lessons organizations can apply immediately, including phishing-resistant MFA, monitoring for bulk data exfiltration, data retention reduction, and why every “incident contained” statement should be treated cautiously until independently verified.
Key Takeaways:
1. Inventory every SaaS vendor that holds your identity, communications, or user data, and rank them by blast radius. You cannot manage concentration risk you have not measured. The output is a one-page list, ranked by how many users would be exposed if the vendor were breached tomorrow.
2. Enforce phishing-resistant multifactor authentication on every administrative and remote-access account. Hardware security keys or platform authenticators that meet the FIDO2 standard. SMS codes and push notifications are not sufficient against the current voice-phishing playbook. Apply this to every administrative account at every vendor in your inventory.
3. Monitor and alert on bulk data exfiltration across your critical SaaS platforms. Configure threshold-based alerts and additional controls to detect or prevent mass exports of sensitive information through APIs or administrative tools. If an account is compromised, the goal is to stop attackers before they can empty the entire database.
4. Set and enforce a data retention schedule that deletes records when their operational purpose ends. The Illuminate FTC consent order specifically requires this, which is a signal that retention is now in enforcement scope. Data you no longer need is data the next breach will steal.
5. Treat any vendor claim of "incident contained" as a hypothesis until your own monitoring confirms it. Maintain independent visibility into the data flowing in and out of critical SaaS platforms — through your identity provider logs, your CASB, or the vendor's own audit feed. The five-day gap between Instructure's containment claim and the second-wave defacement is the case study.
-
It took nine seconds for an AI coding agent to wipe the entire production database of PocketOS — a SaaS company serving hundreds of car rental operators across the US — along with every backup. Customers showed up Saturday morning to pick up their cars and there were no reservations on file.
In this episode, Sherri Davidoff and Matt Durrin dig into the cascading security failures behind the PocketOS incident, connect it to a pattern of similar AI-caused outages at Replit and Amazon AWS, and explain why the real problem isn't rogue AI — it's identity. Every one of these incidents involved an AI agent acting under an identity it shouldn't have had, or that was far too powerful. The insider risk playbook applies. We just haven't been applying it to AI.
Key Takeaways
1. Treat AI agents like privileged insiders, not trusted tools. Apply your full insider risk playbook: least privilege, separation of duties, peer review, monitoring for anomalous behavior. If a human developer needs approval to push to production, so does your AI agent. The PocketOS and Kiro incidents both trace back to AI agents that were granted more trust than any new employee would get on day one.
2. Scope every credential your AI tools can reach. AI agents will find and use any token they can read — even ones created for unrelated tasks, stored in unrelated files. Audit what credentials live in your codebases and repositories. A token created for domain management should not be able to delete databases. If you wouldn't hand that token to a contractor with no supervision, don't let your AI agent have it either.
3. Enforce controls at the infrastructure layer, not the prompt layer. System prompts are advisory. The PocketOS agent had explicit rules against destructive actions — it knew them, quoted them, and violated them anyway. Confirmation requirements for destructive operations, token scoping, and peer review must live in your API layer and infrastructure, not in a paragraph of text the model is asked to obey.
4. Make sure your backups can survive a compromised identity. If your backups are accessible with the same credentials as your production systems — or stored in the same location — they are not real backups. They are a copy in the same blast radius. Test it: could an AI agent, or an attacker, with production access also wipe your recovery options? In the PocketOS incident, the answer was yes.
5. You cannot fully audit your AI vendor's safety claims. You can't penetration-test a reward signal. You can't verify that fine-tuning data isn't quietly drifting your model's behavior. The only controls you can actually rely on are the ones you own: token scoping, access controls, peer review, and monitoring. The goblin story is a reminder that even the vendor that built the model didn't see it coming. Build your defenses accordingly.
Resources
1. PocketOS incident write-up by founder Jer Crane — https://x.com/lifeof_jer/status/2048103471019434248 Amazon Kiro / AWS outage reporting — https://kingy.ai/news/amazon-ai-aws-outage-kiro/
2. Replit AI agent database deletion (Fortune) — https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/
3. OpenAI "Where the goblins came from" post-mortem — https://openai.com/blog/where-the-goblins-came-from
4. Guardian reporting on Amazon cloud outages and AI tools — https://www.theguardian.com/technology/2026/feb/20/amazon-cloud-outages-ai-tools-amazon-web-services-aws
-
In this live episode of Cyberside Chats, we dig into security debt and why it continues to sit behind so many major incidents. This is the risk that builds quietly over time when controls are available but never turned on, systems aren’t fully decommissioned, or ownership is unclear.
Using recent examples like Stryker, along with Change Healthcare and Colonial Pipeline, we walk through how attackers don’t always need sophisticated techniques. In many cases, they just take advantage of gaps that have been sitting there for years. We also introduce a simple framework to think about security debt across identity, lifecycle, architecture, governance, and operations, and why most real-world incidents cut across more than one of these areas.
We close with a look at how things are changing. With AI accelerating exploit development, the window to fix these issues is getting smaller. What used to be a manageable delay is quickly becoming real exposure.
Audience takeaways
Require dual approval for destructive admin actions. Any system where one administrator can wipe, delete, or lock out at scale — Intune, Entra, identity providers, backup consoles, remote management tools — should require a second administrator to approve the action before it executes. Microsoft's Multi Admin Approval does this for Intune. Most identity and backup platforms have an equivalent. Turn it on. Stryker is the case study for what happens when you don't. (Addresses: Governance debt primarily; reduces Identity and Architecture debt blast radius.)Enforce phishing-resistant MFA on every administrator and every remote-access path. Not "available," not "recommended" — enforced, with no exceptions. Every admin account. Every VPN. Every Citrix or similar remote portal. Change Healthcare is the case study for what a single missing MFA checkbox costs. (Addresses: Identity debt.)Separate admin work from daily work. Admins should use dedicated, hardened devices for privileged tasks — never the same laptop they use for email and browsing. An infostealer on an admin's everyday device is how privileged credentials walk out the door; isolating admin sessions removes that path. Microsoft calls this pattern Privileged Access Workstations; other vendors have equivalents. This directly addresses how attackers likely got Stryker's admin credentials in the first place. (Addresses: Architecture debt; reduces Identity debt.)Cut your patch SLA in half and plan capacity accordingly. Whatever your current median time-to-remediate is for critical vulnerabilities, assume you need to hit half of it within the next year. The Mythos research shows attacker timelines are compressing from weeks to hours. Your patch program needs budget, automation, and process changes to keep up — not pep talks. (Addresses: Operational debt.)Put expiration dates on every security exception and review them quarterly. If your exception register contains entries with no expiration date, no owner, or a "revisit in the future" stub — those are governance debt. Every open exception should have an expiration date, a named owner, and a scheduled review. Exceptions are fine; forever-exceptions are not. This is also how you close the loop on lifecycle debt: an EOS system running past its decommission date is just an exception someone never wrote down. (Addresses: Governance debt and Lifecycle debt.)References For listeners who want to dig into the source material referenced in this episode:
CISA Alert — Endpoint Management System Hardening After Cyberattack Against US Organization (March 18, 2026). The official CISA advisory issued in the wake of the Stryker incident, including specific guidance on Multi Admin Approval for high-impact actions like device wiping. cisa.gov/news-events/alerts/2026/03/18/cisa-urges-endpoint-management-system-hardening-after-cyberattack-against-us-organization CISA Binding Operational Directive 26-02 — Mitigating Risk From End-of-Support Edge Devices (February 5, 2026). The federal directive that defines deadlines for inventorying and decommissioning unsupported edge infrastructure — a useful baseline for anyone managing lifecycle debt. cisa.gov/news-events/directives/bod-26-02-mitigating-risk-end-support-edge-devices3. Andrew Witty Written Testimony, House Energy & Commerce Subcommittee on Oversight (April 30, 2024). UnitedHealth Group CEO's congressional testimony confirming the Change Healthcare breach occurred via a Citrix portal that did not have multi-factor authentication enabled. energycommerce.house.gov/events/oversight-and-investigations-subcommittee-hearing-examining-the-change-healthcare-cyberattack -
Anthropic accidentally exposed the source code for its Claude Code CLI—and while no customer data or model weights were involved, the impacts are significant.
In this episode of Cyberside Chats, Sherri Davidoff and Matt Durrin break down what actually leaked, why the agent layer matters more than most people realize, and what happened next—including the rapid emergence of new open-source alternatives like Claw Code.
They also answer key questions from a client:
1. What risks should organizations be thinking about because of this leak?
2. Does this change how AI coding tools should be monitored?
3. What are some practical recommendations for educating end users and developers?
The conversation focuses on real-world impact: execution risk, supply chain exposure, and the growing need for governance around “vibe coding” tools.
Key Takeaways
1. Treat AI coding agents like controlled execution environments These tools can read files, execute commands, and modify code. Govern them like CI/CD or automation systems with constrained permissions and segmentation.
2. Assume attackers are studying this architecture right now The leak removes guesswork. Expect more targeted prompt injection and tool abuse as adversaries analyze how these systems behave internally.
3. Prioritize immediate risks: malicious repos and supply chain abuse Threat actors are already using this as a lure. Monitor for typosquatting, dependency confusion, and “leaked” tools distributing malware.
4. Ensure developers know what’s official—and what isn’t Make sure teams can distinguish between official tools and alternatives. If using open-source variants, vet the source, maintainers, and security model.
5.Take this as an opportunity to formalize AI governance for coding and development tools. Many organizations are still experimenting. Define policies, logging, and oversight now, especially around how these tools are approved and used.
-
Anthropic’s Project Glasswing and its unreleased Mythos model signal a potential turning point in cybersecurity: AI that can find—and potentially exploit—software vulnerabilities at unprecedented scale.
In this episode of Cyberside Chats, Sherri Davidoff and Tom Pohl break down what this means for organizations today. If AI can uncover decades-old bugs in seconds, what happens to patching cycles, vulnerability management, and the balance between attackers and defenders?
They explore the uncomfortable reality: we may be entering a period where vulnerabilities are discovered faster than organizations can fix them—and where access to powerful AI tools could determine who wins and loses in cybersecurity.
From continuous patching to network segmentation and vendor accountability, this episode focuses on what security leaders need to do right now to prepare for a rapidly shifting threat landscape.
Key Takeaways
1. Reduce your internet exposure - If a system doesn’t need to be publicly accessible, don’t put it on the internet. Move services behind firewalls, VPNs, or restricted access controls wherever possible. Attack surface matters more than ever.
2. Vet your vendors’ security practices - Don’t just trust that vendors are handling security well. Ask how they:
Secure their development lifecycle (SDLC)Detect and respond to vulnerabilitiesPatch and distribute fixesVendor risk is now a direct extension of your own risk.3. Budget for ongoing maintenance of custom code - Custom applications aren’t “done” at deployment. Plan for:
Regular security testingContinuous patchingDeveloper time to fix vulnerabilitiesSoftware is a living system and requires ongoing care and feeding.4. Segment your network to limit attacker movement - Assume attackers will get in. The goal is to stop them from moving laterally:
Separate critical systemsLimit privileged account accessControl how systems communicateContainment is just as important as prevention.5. Update your incident response plan for zero-day reality - Your IR plan should assume:
Exploits may exist before patches are availableDetection may lag behind compromisePrepare for faster response, imperfect information, and active exploitation of unknown vulnerabilities.Resources & References
1. Anthropic – Project Glasswing - https://www.anthropic.com/glasswing
2. Anthropic – Mythos Preview - https://red.anthropic.com/2026/mythos-preview/
3. Historical example discussed: Microsoft bug tracking system breach (2017)
4. Example referenced: ProxyShell (Microsoft Exchange vulnerabilities and rapid exploitation)
-
In this episode, Matt interviews Tom and Derek from our pen test team to break down why attackers often don’t need to hack their way in at all.
While most organizations invest heavily in tools like EDR and SIEM, Tom and Derek share how they regularly get inside buildings using nothing more than confidence, a good story, and sometimes even a box of donuts. From posing as copier technicians to tailgating behind employees, their experiences show that people are often the easiest way into an organization.
And once they’re in, things escalate fast. Physical access can quickly turn into network access, whether it’s plugging in a device, jumping on an unlocked workstation, or moving through the environment with far fewer restrictions than an external attacker would face.
The big takeaway is simple. Real-world testing exposes what audits miss. Doors get propped open, employees try to be helpful, and small gaps add up in ways most organizations never see on paper.
If you’re not testing your people and your physical controls, you’re only testing part of your security.
Key takeaways:
1. Attackers target people first, not systems - Social engineering consistently bypasses even mature technical controls.
2. Physical access equals full compromise - Once inside your facility, most security controls can be circumvented quickly.
3. Un-tested controls are assumed to fail - If you’re not running social engineering or physical assessments, you don’t know your real risk.
4. Culture is a security control - Employees must feel empowered to challenge, verify, and report suspicious behavior.
5. Real-world testing reveals what audits miss - Offensive social engineering exposes how attacks succeed, not just theoretical vulnerabilities.
-
A $25 billion medical device company brought to a standstill—without a zero-day exploit.
In this episode of Cyberside Chats, Sherri Davidoff is joined by cyber insurance expert Bridget Quinn Choi to unpack the Stryker cyberattack and what it reveals about modern enterprise risk. From compromised admin credentials to the abuse of Microsoft Entra and Intune, this incident highlights how attackers are increasingly using trusted tools to cause widespread disruption.
We explore what likely happened, why this wasn’t a “sophisticated” attack in the traditional sense, and how a single identity compromise can cascade into operational shutdown. Bridget brings a unique perspective from the cyber insurance world—explaining how insurers evaluate risk, why some large companies choose to go without coverage, and what organizations lose when they do.
We also dig into phishing-resistant MFA, governance of powerful admin tools, and the evolving role of insurance as both a financial backstop and a driver of better security practices.
If your organization relies on centralized identity and device management systems, this is a conversation you can’t afford to miss.
Key Takeaways for Security Leadership
1. Use Cyber Insurance as a Security Maturity Lever Don’t treat cyber insurance as a checkbox—it can actively strengthen your security program. Use underwriting requirements to benchmark your controls, ask brokers and carriers where you differ from peers, and take advantage of included services like threat intelligence and incident response support. Approach renewal as a security review, not just a policy purchase.
2. Treat Self-Insurance as a Strategic Risk Decision—Not a Cost Savings Measure If you’re considering self-insuring cyber risk, account for what you’re giving up: external validation of your controls, a built-in incident response ecosystem, and coordinated support during a crisis. This should be a board-level discussion focused on whether the organization can handle a major operational outage—not just absorb the financial loss.
3. Secure Your Device Management Systems—Because They Can Control Everything at Once Systems used to manage laptops, servers, and mobile devices can push changes across your entire organization. If attackers gain access, they can disrupt operations at scale. Treat these as central control hubs, limit administrative access, and apply strong monitoring and authentication controls.
4. Require Dual Approval for High-Impact Administrative Actions Add a second layer of human verification for actions that could impact many systems, such as device wipes or large-scale changes. This introduces intentional friction that helps prevent catastrophic mistakes or misuse.
5. Move to Phishing-Resistant MFA for Privileged Access Traditional MFA can be bypassed. For high-risk accounts, adopt phishing-resistant methods like passkeys or hardware-backed authentication and prioritize these protections for users with administrative access.
6. Make Sure You Can Actually Recover—Not Just Back Up Backups only matter if they work under pressure. Test your ability to restore critical systems, ensure backups are protected from attackers, and measure how long recovery actually takes in a real-world scenario.
Resources
1. Stryker cyberattack reporting (New York Times) https://www.nytimes.com/2026/03/12/world/middleeast/stryker-iran-cyberattack.html
2. CISA alert on endpoint management system hardening https://www.cisa.gov/news-events/alerts/2026/03/18/cisa-urges-endpoint-management-system-hardening-after-cyberattack-against-us-organization
3. SecurityWeek coverage of the Stryker incident https://www.securityweek.com/medtech-giant-stryker-crippled-by-iran-linked-hacker-attack/
4. Lumos analysis of the Stryker hack https://www.lumos.com/blog/stryker-hack
5. Microsoft Intune security best practices https://techcommunity.microsoft.com/blog/intunecustomersuccess/best-practices-for-securing-microsoft-intune/4502117
-
Mass exploitation vulnerabilities are back—and they’re evolving. In this Cyberside Chats Live episode, we break down the recently disclosed React2Shell vulnerability and the confirmed LexisNexis incident, where attackers exploited an unpatched web application to access cloud infrastructure and exfiltrate data.
But this isn’t new. From SQL Slammer to Log4Shell to ProxyShell, we’ve seen this pattern before: widely deployed, internet-facing systems + simple exploits + automation = rapid, large-scale compromise.
Most importantly, we focus on what matters for organizations today: how to reduce exposure, how to prepare for the next mass exploitation event, and why you should assume compromise the moment one of these vulnerabilities emerges.
Key Takeaways for Security Leaders
1. Inventory and monitor all internet-facing systems. Maintain a current, validated inventory of externally accessible applications and services—because you can’t secure what you don’t know is exposed.
2. Reduce unnecessary exposure at the network edge. Remove or restrict public access to administrative interfaces and systems that do not need to be internet-facing.
3. Build and rehearse a rapid-response playbook for mass-exploitation vulnerabilities. Define roles, timelines, and actions for the first 24–72 hours so your team can move immediately when the next major vulnerability drops.
4. Contact critical vendors and suppliers during major vulnerability events. Don’t wait—proactively verify whether your vendors are affected and whether your data may be at risk through third- or fourth-party exposure.
5. Assume vulnerable internet-facing systems may already be compromised. When mass exploitation begins, attackers are moving at internet speed—patching alone is not enough. Investigate, hunt for persistence, and validate that systems are clean.
Resources
1. React2Shell vulnerability coverage (BleepingComputer) https://www.bleepingcomputer.com/news/security/react2shell-flaw-exploited-to-breach-30-orgs-77k-ip-addresses-vulnerable/
2. LexisNexis breach details (BleepingComputer) https://www.bleepingcomputer.com/news/security/lexisnexis-confirms-data-breach-as-hackers-leak-stolen-files/
3. Compromised web hosting panels in cybercrime markets (BleepingComputer) https://www.bleepingcomputer.com/news/security/compromised-site-management-panels-are-a-hot-item-in-cybercrime-markets/
4. CISA Known Exploited Vulnerabilities Catalog https://www.cisa.gov/known-exploited-vulnerabilities-catalog
-
Anthropic has been labeled a “Supply-Chain Risk to National Security” after refusing two uses of its models: mass surveillance of Americans and lethal autonomous warfare without human oversight. But is Anthropic really a supply-chain risk, and how does this designation affect businesses that use Claude? In this episode, Sherri Davidoff and Matt Durrin unpack the timeline behind the Pentagon’s designation, what Anthropic claims is actually driving the conflict, and what’s known (and not known) about any underlying technical risk. They compare the situation to Kaspersky—where the supply-chain concern centered on privileged security software, foreign-state leverage, and update-channel risk—then bring it back to the enterprise questions that matter: vendor dependency, continuity planning, and what changes when an AI provider becomes politically or contractually constrained.
Key Takeaways for Security Leaders
1. Treat AI vendors as critical dependencies, not just tools.
If a frontier AI provider is embedded in coding, search, documentation, analytics, or agentic workflows, a legal or procurement shock can become an operational disruption. Track where you are dependent on a single model provider and where that dependency would hurt most.
2. For your highest-value uses, define fallback workflows ahead of time.
You may not be able to replace every provider quickly, but you should know what happens if a key AI service becomes unavailable, restricted, or no longer acceptable for regulatory or contractual reasons. For the workflows that matter most, decide in advance how the work gets done without that vendor.
3. Keep guardrails in place when AI is involved in critical changes.
AI can speed up engineering, operations, and decision-making, but that speed can create new failure modes if approvals, testing, rollback, and human review get weakened. Be especially careful in environments where AI-assisted or agentic systems can make infrastructure, code, security, or configuration changes.
4. Inventory where AI has real privilege.
The risk is much higher when AI can execute code, access sensitive data, approve actions, or trigger automations. Focus your review on those integrations first, because those are the places where vendor problems or internal AI mistakes are most likely to turn into real incidents.
5. Make your teams define the actual vendor risk they are worried about.
A vendor can create very different kinds of risk: technical compromise risk, foreign-control risk, continuity risk, or procurement/governance risk. Forcing that distinction helps teams respond more clearly and avoid treating every controversy like a hidden software compromise.
Resources
1. Statement from Dario Amodei on our discussions with the Department of War (Anthropic, Feb. 26, 2026) https://www.anthropic.com/news/statement-department-of-war
2. Where things stand with the Department of War (Anthropic, Mar. 5, 2026) https://www.anthropic.com/news/where-stand-department-war
3. Anthropic v. U.S. Department of War et al. — Complaint for Declaratory and Injunctive Relief (N.D. Cal., filed Mar. 9, 2026) (court filing PDF) https://cand.uscourts.gov/cases-e-filing/cases/326-cv-01996/anthropic-pbc-v-us-department-war-et-al
4. BOD 17-01: Removal of Kaspersky-branded Products (CISA/DHS, Sept. 13, 2017) https://www.dhs.gov/archive/news/2017/09/13/dhs-statement-issuance-binding-operational-directive-17-01
5. Amazon holds engineering meeting following AI-related outages (Financial Times, Mar. 2026) https://www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f771de
-
For years, many Google API keys were treated as “public” project identifiers embedded in client-side code and protected mainly through referrer and API restrictions. But a recent discovery suggests Gemini changes that risk model: researchers found nearly 3,000 publicly exposed Google API keys that were still “live” and could be used to interact with Gemini endpoints, creating a new path to unauthorized usage, quota exhaustion, and potentially costly API charges.
In this episode of Cyberside Chats, we unpack what “changed the rules” actually means, why this is a classic cloud governance problem (old assumptions meeting new capabilities), and what to check right now. The bottom line: AI features are quietly expanding the blast radius of credentials you never intended to treat as secrets.
Key Takeaways
1. Audit legacy API keys before and after enabling AI services - Inventory every API key across your cloud projects and confirm it is still required, properly scoped, and has a clear owner. Treat AI enablement as a formal trigger event to reassess any previously published or embedded keys in that same project.
2. Treat API keys as sensitive credentials in the AI era - Even if a vendor once described a key as “not a secret,” AI endpoints materially increase financial and potential data exposure risk. Apply rotation, monitoring, strict quotas, and real-time billing alerts accordingly.
3. Enforce least privilege at the API level - Referrer or IP restrictions alone are insufficient. Every key should be explicitly limited to only the APIs it requires. “Allow all APIs” should not exist in production.
4. Isolate AI development from production application projects - Avoid enabling AI services in long-lived projects that contain public-facing keys. Use separate projects, accounts, or subscriptions for AI experimentation and production workloads to reduce blast radius and cost exposure.
5. Update third-party risk management to include AI-driven credential and cost risk - Ask vendors how API keys are scoped, restricted, rotated, and monitored especially for AI services. Confirm that AI environments are isolated from production systems and that abnormal AI usage or billing spikes are actively monitored.
Resources:
1. Google API Keys Weren’t Secrets. But then Gemini Changed the Rules (Truffle Security)
https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules
2. Previously harmless Google API keys now expose Gemini AI data (BleepingComputer)
https://www.bleepingcomputer.com/news/security/previously-harmless-google-api-keys-now-expose-gemini-ai-data/
3. DEF CON 31 – “Private Keys in Public Places” (Tom Pohl) (YouTube) https://www.youtube.com/watch?v=7t_ntuSXniw
4. Exposed Secrets, Broken Trust: What the DOGE API Key Leak Teaches Us About Software Security (LMG Security)
https://www.lmgsecurity.com/exposed-secrets-broken-trust-what-the-doge-api-key-leak-teaches-us-about-software-security
5. Google Cloud docs: API keys overview & best practices (Google) https://docs.cloud.google.com/api-keys/docs/overview
-
Claude Opus 4.6 is generating serious buzz for one reason: it can rapidly spot zero-day vulnerabilities out of the box, suggesting that long-trusted software may no longer be as “safe by default” as security teams assume.
At the same time, Microsoft’s February patch cycle included an unusually high number of zero-days already under active exploitation — real-world evidence that the race is already accelerating, and the window between discovery and impact is shrinking.
In this Cyberside Chats Live, we’ll connect the dots on what this means for defenders in 2026: a shrinking window between discovery and exploitation, shifting assumptions about “well-tested” software, and practical ways to rethink patch prioritization, detection, and exposure management.
Key Takeaways:
1. Plan for exploitation before disclosure - The era of negative-day vulnerabilities is here, flaws that may be discovered and weaponized before the broader security community even knows they exist. Assume exploitation could precede public advisories. Build response models around mitigation speed, not just patch timelines.
2. Prioritize exposure, not just severity - In a compressed exploit cycle, CVSS alone won’t protect you. Focus first on internet-facing systems, identity infrastructure, and high-privilege assets. If you cannot quickly identify what is externally reachable, that visibility gap becomes strategic risk.
3. Assume compromise on exposed assets and monitor accordingly - If attackers can exploit vulnerabilities before the world knows they exist, you may be compromised without a CVE to point to. Increase monitoring on internet-facing systems and critical apps for signs of intrusion: unexpected processes, new admin accounts, unusual authentication patterns, suspicious outbound connections, and persistence mechanisms.
4. Treat compensating controls as first-line defense - When patches aren’t available or cannot be deployed immediately rapid mitigations matter. Restrict access, disable vulnerable features, deploy firewall and WAF protections, and tighten segmentation. Mitigation agility should be operational, tested, and pre-authorized.
5. Prepare for containment patches may not exist - If exploitation is confirmed and no fix is available, leadership decisions must happen quickly. Define in advance who can isolate systems, disable services, revoke credentials, or temporarily disrupt operations. Shorten containment decision cycles before you need them.
6. Rehearse a “negative-day” tabletop - Run a scenario where exploitation is active, no patch exists, and public disclosure hasn’t occurred. Measure how fast you can reduce exposure, hunt internally, and communicate with executives. This exercise will expose friction points that policies alone will not.
7. Integrate AI into your vendor risk model - If AI is accelerating vulnerability discovery and code generation, your third parties are likely using it too. Update vendor due diligence to assess how AI-generated code is reviewed, secured, and tested. Ask about model governance, secure development controls, and vulnerability response timelines. If you lack visibility into how vendors manage AI risk, that gap becomes part of your attack surface.
Resources:
1. Anthropic – Evaluating and Mitigating the Growing Risk of LLM-Discovered 0-Days (Feb 5, 2026) https://red.anthropic.com/2026/zero-days/
2. Zero Day Initiative – February 2026 Security Update Review https://www.zerodayinitiative.com/blog/2026/2/10/the-february-2026-security-update-review
3. SecurityWeek – 6 Actively Exploited Zero-Days Patched by Microsoft (Feb 2026) https://www.securityweek.com/6-actively-exploited-zero-days-patched-by-microsoft-with-february-2026-updates/
4. Tenable – Claude Opus and AI-Driven Vulnerability Discovery Analysis https://www.tenable.com/blog/Anthropic-Claude-Opus-AI-vulnerability-discovery-cybersecurity
5. OpenAI releases crypto security tool as Claude blamed for $2.7m Moonwell bug
https://www.dlnews.com/articles/defi/openai-releases-crypto-security-tool/
- Laat meer zien
