Cyberside Chats: Cybersecurity Insights from the Experts

Poisoned on Open: The New Worm Hacking Your AI

26 min · 30. juni 2026
episode Poisoned on Open: The New Worm Hacking Your AI cover

Description

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 [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 [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 [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 [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 [https://socket.dev/blog/shai-hulud-descends-to-hades-miasma-worm-pypi-wave]

Comments

0

Be the first to comment

Sign up now and become a member of the Cyberside Chats: Cybersecurity Insights from the Experts community!

Get Started

1 month for 9 kr.

Then 99 kr. / month · Cancel anytime.

  • Podcasts kun på Podimo
  • 20 lydbogstimer pr. måned
  • Gratis podcasts

All episodes

77 episodes

episode Poisoned on Open: The New Worm Hacking Your AI artwork

Poisoned on Open: The New Worm Hacking Your AI

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 [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 [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 [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 [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 [https://socket.dev/blog/shai-hulud-descends-to-hades-miasma-worm-pypi-wave]

30. juni 202626 min
episode The Meta AI Hack: Just Ask Nicely artwork

The Meta AI Hack: Just Ask Nicely

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/ [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/ [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/ [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 [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 [https://arxiv.org/abs/2509.10540]

23. juni 202612 min
episode Washington Calls AI a Weapon: Ghosts of the Crypto Wars artwork

Washington Calls AI a Weapon: Ghosts of the Crypto Wars

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 [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 [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 [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/ [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 [https://www.eff.org/cases/bernstein-v-us-dept-justice]

16. juni 202611 min
episode Damaged Goods: When your new hire is already compromised artwork

Damaged Goods: When your new hire is already compromised

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

9. juni 202615 min
episode The CRM Goldmine: Inside the Salesforce Breach Wave artwork

The CRM Goldmine: Inside the Salesforce Breach Wave

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/ [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/ [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/ [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 [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/ [https://www.salesforce.com/blog/protecting-your-data-essential-actions-to-secure-experience-cloud-guest-user-access/]

2. juni 202616 min